ASTRON ZONE (1993? - Game revised in 1993, original date unknown but probably 1992)

Astron Zone is a buggy, Lo-Res combat strategy game I based significantly on the mainframe / Microsoft BASIC classic Super Star Trek. More accurately, it is based on what I imagined Super Star Trek to be like. Even in the early 1990s I had yet to play any version of this famous game which had been circulating on mainframes since the 1960s and personal computers since the 1970s. The real reason I never played it was that I could never to bring myself to type the thing in. The primary source of Super Star Trek was the program listing dispensed in the famous David H. Ahl book Basic Computer Games, and within that book Super Star Trek was the longest, densest listing there was. Given that I had first been exposed to it when I was 6 or 7, and that nearly all of my early programming efforts were emulations of games from the Ahl books, I had built Super Star Trek up in my mind as some kind of unattainable symbol. It was a program listing I could gaze at in awe, but certainly not something I could see myself entering into the Apple II for real.

My response to this problem over the years, the problem of wanting to play Super Star Trek and yet never having the wherewithal to type it in, was a bit silly in retrospect. What I did was try to make games which were like Super Star Trek. I'd take all the mechanics of the game that I could extrapolate from its instructions, or from the sample play transcripts included in the Ahl book, and I’d stick them wholesale into a game of my own. The typical result would be verbatim in some areas and similar in others, but also just a mess. I don't really believe in curses, but none of my efforts to emulate Super Star Trek (without ever having played it) came out as satisfactory games in their own right. In getting ready to write about Astron Zone, I even found preparatory notes I'd written for another projected take on Super Star Trek, this one in Hi-Res, on a piece of paper tucked inside the front cover of my copy of BASIC Computer Games. I have only the vaguest recollection of writing them. You can find both these mystery notes plus my actual notes for Astron Zone down in the notes section near the bottom of this page.

It wasn’t until I was in my twenties that I had the programming ability and maturity to sit down and finally type in the original Super Star Trek listing, converting it into a PRODos-based game with sounds and MouseText graphics on the fly as I did so. In the meantime, I just made occasional knockoffs which didn't really work out. Like Astron Zone.

The game kicks off with the same basic setup as in Super Star Trek. You must pilot a craft of finite resources around a map with the goal of destroying all the alien ships before they destroy you or you run out of gas. But where Trek’s play area was large and spread out, the action of Astron Zone takes place in a confined area which fits entirely on one screen. The zone is colourfully depicted in Lo-Res with faux cockpit prettiness around it:

I remember wanting to make colourful games in the wake of my family's graduation in 1990 from our old Apple II+ to the Apple IIGS, which also marked our move from having a monochrome monitor (really just a black and white TV) to a colour one. Suddenly I could see what all the Apple II games I'd been playing for almost a decade looked like in colour. I could also find out what the games I'd made myself really looked like, as in many cases I'd tried to choose appropriate colours for their graphics in spite of not being able to test the colours out. And with Lo-Res being the most broadly colourful graphics mode available on the 8-bit Apple II, I went to town with it in Astron Zone.

Unfortunately, Astron Zone's being colourful does not make up for the various design and programming problems which are still in the game in spite of me making a revision pass over it in 1993, something I'd completely forgotten I did until I dug out my notes. (I can't confirm the year I did the original programming. My guess would be 1992.) The game remains fundamentally buggy for complex reasons which I will shortly describe, but the upshot of the bugginess is that if you’re unlucky during play, you might find that the game doesn't clock that you've won when all the aliens in the zone are dead. Rather than spend any time today investigating this bug and the other problems, I'm content to preserve the game that I made. This is a case where correcting just one thing would not be enough, but to do more would change Astron Zone into a different game.

My problems in making it all stemmed from the interaction between two factors: (1) The amount of data I wanted the program to crunch each turn and (2) The way I was using the Lo-Res screen. As a fifteen-year-old, I wasn't able to come up with the programming solutions to these problems. Right now I could come up with about ten. That is the difference age, practice and experience make.

The zone is full of alien ships, some meteors, a couple of satellites and a bunch of invisible black holes (those last were a poor design choice, but more on that later). I allow all of these things to collide with each other, with results you would expect in each case. After the player performs an action on his/her turn, all of the aliens and meteors move semi-randomly. This is where the datacrunching comes in. I set up variable arrays to store the X and Y coordinates of all these objects. If I intend to iterate through this list one alien/meteor at a time in order to choose a new adjacent square for each entity to move to, what is the next logical step? It is to check what, if anything, is in the square the entity is trying to move into. How might I do that? My first approach was to iterate through the whole list of entities again; that is, to manually check the position of every alien and meteor in the game to see if it was in the target space. To do so produced a number of incredibly slow operations equal to the number of moving entities squared. This process took so long for BASIC to perform on an Apple II running at 1 Mhz that the game was rendered unplayable by it, so I had to bin it and find another approach.

Part of the solution I came up with was a step towards what I should have done in the first place: Store the contents of the whole zone as an array. Doing so would have allowed me to look immediately at any target square and see what was in it, but this particular way to use an array didn't occur to me at the time. Instead I tried to use a special function of Lo-Res programming to store some information about the zone content on the Lo-Res screen itself. That is, it's possible to read the colour of a Lo-Res pixel at any particular position. So if I checked the target pixel and it was black, that meant there was no alien or meteor in it — though there could still be a black hole there. I could also just iterate over the whole display one square at a time, checking for blue dots (aliens) and then making them move.

Programming the bulk of my movement / collision testing in this way sped the game up considerably. Not enough that you’d want to play it at 1 Mhz today; each turn takes an age. My movement / collision programming was plainly full of holes, and these are the source of the bugs which remain. The game often loses count of how many aliens have died. I'm also pretty sure that it leaves the occasional non-functional blue dot on the screen.

On a sped up emulator or accelerated hardware, the game offers a little bit of fun thanks to its colour, sound effects (again done by me using routines from Apple Mechanic) and the general sense of business it generates when all those aliens and meteors move around each turn. The black holes are a drag at any speed, though. I assume I intended players to note their positions whenever aliens stumbled into them. If I did assume that, it was a tedious and unrealistic proposition. The main effect of the black holes is just to add a random chance of you dying whenever you move your ship.

I composed the title track for the game using The Electric Duet. It's another piece in that chromatic style that my mum never liked, but I still think it's a good short piece. The alarm sound at the start of it also demonstrates my improving ability at the time to derive interesting sound textures from Electric Duet.

Astron Zone's instructions are certainly thorough, but since you have to read them all at once, they also feel interminable and overwhelming. This obviously isn't the way a game would go about telling you how to play it today, and even I feel it in this case, I who have been known to derive some kind of neurotic pleasure from writing or reading instructions. Just remember that it was much harder to program in-game help back in the days of lower screen resolution, no windows and a general absence of scrollable text. That's why game authors tended to put all the instructions outside of the game, like I did here, or in a real booklet which you could keep beside the computer while playing.

NOTES

The left scan contains my notes for Astron Zone, apparently written for a revised version in 1993. The middle scan is the first of two pages of notes I made for a would-be Hi-Res Super Star Trek game. I don't know when I wrote them (presumably sometime in the early 1990s) but I found them inside the front cover of my copy of BASIC Computer Games in 2014. The right scan is the second page of these notes.

DOWNLOADABLE DISK IMAGE

astron_zone.zip (Contains astron_zone.dsk)