ILLUMINATE (c. 1986-1987)

Illuminate is a very incomplete adventure game with graphics and randomised combat. I have vivid memories of making it, which will be best illuminated by me telling its story in plain old chronological order.

The main boardgame haunt of my youth was a shop called The Games House. Situated in Chatswood Chase, a big local shopping centre in suburban Sydney, this was the place where my dad bought me the Dungeons & Dragons Basic Set for Christmas in 1982 or 1983, when I was seven or eight. The shop was crammed full of role-playing games, modules for role-playing games, polyhedral dice in transparent multi-compartment plastic containers, novelty items and board games of all shapes and sizes. Gamers of this era will recall the minigames put out by TSR and Steve Jackson Games. These were complete boardgames issued in a plastic box as wide as an adult's hand and only a bit longer. TSR's Vampyre was the first of these I ever played, and it's still my favourite. The Steve Jackson pocket game which most often beckoned to me, based on its captivating cover artwork alone, was a thing called Illuminati.

I didn't know what Illuminati was called at the time because I was way too young to know that "Illuminati" was a real word. What my eyes saw was a word I did know, Illuminate, but written in a strange way or with a spelling mistake. The imagery on the cover was beyond me, and being a kid, I took it literally. I saw a fantasy world involving a pyramid with an eyeball on top of it, not a metaphor for an all-controlling secret society symbolised by the same image.

I was so fascinated by this picture that I decided to start making my own game out of it. I programmed it in BASIC using one of the most elementary Hi-Res graphic techniques available to Apple II programmers: the HPLOT. With this command, you can specify two pairs of coordinates on the screen and ask the Apple to draw a line between them in a colour you also choose. By stringing HPLOTs together, you can draw whole line-based pictures. This technique is great for producing graphics automatically from a mathematical function, but It’s a slow and incredibly memory-intensive way to produce illustrations.

In retrospect, lluminate was the most overly ambitious game I ever briefly started to make. I was too young (11-12 I'd say) to know that it was ambitious. I was trying to make a game that had a parser, a graphic screen above the parser ala Wizard and the Princess or other famous early Apple II graphic adventures — and which would also have randomised combat. When the game begins, you get to choose one of five weapons, and when you get into a fight, the game draws a side-on perspective picture of you and your enemy. My understanding of random odds was pretty much non-existent at this point. Looking at the code today, I can see that I programmed it so that all of the combat was 50/50. In other words, your chance to hit anyone is 50%. Anyone else's chance to hit you is 50%.

The game was going along really well. I had programmed the introduction, combat, several enemies and the first two rooms, including one with a picture of the pyramid with the eyeball. And then weird stuff started to happen. I would run the game and find glitchy horizontal lines appearing randomly amongst the graphics. Eventually the program would crash, complaining that lines of code I had typed into it weren't there. Also, the combat sequence started to fail. Combat would begin, but you'd face no enemy, the name of your foe simply replaced by a blank space, its stats zeroed. Trying to LIST the program after a crash would sometimes produce gobbledygook.

I'd never seen anything like this happen before, and it freaked me out. The graphical glitching in particular made me wonder if something in the machine was busted. But the worst thing was that I didn't know of any way to make the game work. Any attempts to add more to it were corrupted or erased as soon as I tested them. I particularly remember a sunny day I spent with my parents at the Sydney Botanical Gardens around this time, and how for the duration of the whole day my mind was elsewhere, doing cartwheels trying to work out what had gone wrong with this game. My dad didn't understand what had happened either. We all gave up on the problem, and I gave up on the game.

I randomly encountered the explanation in an issue of Australian Personal Computer magazine, but not until at least a year later, and possibly as many as three. In the magazine's programming column, I came across a small piece of code which, if you ran it, would move your BASIC program above the Apple II's Hi-Res screen memory. Accompanying text explained that this gesture would solve a common Apple II programming problem. I didn't understand the import of all this, but out of curiosity I tried running the code. And I found that if I did run it after turning the computer on, I could then run Illuminate, and that all the glitching and crashing was gone.

So what had happened? What I had neither known nor understood prior to this experience was that the memory which holds the pixel values for the Apple II's Hi-Res display sits, inconveniently, right in the path of user-written Applesoft BASIC code. Once your program and some of its variables occupy more than 5-7 kB of RAM, they will start walking through the Hi-Res video memory. The result is bad for both parties. Code entering the screen area manifests as graphic glitching, and in turn, activating and drawing on the Hi-Res screen will corrupt and obliterate chunks of your program, effectively capping its maximum size to what can fit in memory beneath the Hi-Res screen area, a far smaller RAM space than is available to the computer as a whole. So if you want to use both BASIC and the Hi-Res screen, the solution, as demonstrated in the magazine article, is to tell the computer that you want BASIC code to start building up from a memory address just above the Hi-Res screen. A little bit of RAM beneath the screen area gets wasted in the process, but the net effect is that you regain full functionality and lots of RAM for a program which would otherwise have crashed both itself and the Hi-Res display. These issues don’t come up in assembly language programming because assembly code can be loaded into RAM wherever you like.

In the case of BASIC Hi-Res games I made after Illuminate, but before I came across the solution in the magazine, games like Questor II: Terror of Vonrak and Sam Snake: Jobseeker, my workaround was to split them up into several programs, none of which would be long enough in its own right to extend into the Hi-Res video memory. I didn't even know that this was the reason I was splitting them up, only that Hi-Res graphic games of mine which got beyond a certain length mysteriously started to suffer all of the aforementioned weird behaviour. The workaround was tedious to program and tedious for the player to experience, because it involved unnecessarily frequent disk access. The sub-programs had to keep being reloaded, and they also had to pass variables between each other by temporarily writing them to disk. I didn't yet know that Applesoft has a CHAIN command which lets you run a new program while keeping the variables from the old one in memory.

Recalling my experience with Illuminate is one of the easiest ways that I can recall the nature of the information environment in the period which was post-computer but pre-internet, a period of roughly fifteen years. I have to preface this with a reminder that I was only eleven or twelve, but the idea of having to wait 1-3 years for the solution to a single programming problem seems unfathomable in the world of 2013. Now you can get the solution for almost any programming problem from a web forum in 0-2 days. Sometimes you can't even stand to wait fifteen minutes; I'm guilty of that impatience, too.

Of course, I wasn't aggressively seeking the answer to my problem. Someone older might have had more access to programming peers, books, user groups or other resources. In theory I was very well resourced at home for a twelve-year-old programmer, what with my dad's library of Creative Computing, Australian Apple Review and Australian Personal Computer magazines, but most of the technical content in these magazines was still over my head. The difference between a kid in fifth or sixth grade and one in seventh or eighth grade is enormous, and I was only a year or two away from being old enough to understand and make use of all this printed information which was around me.

Later, in high school, I acquired the real Illuminati, the Steve Jackson pocket game, and finally discovered what it was: a card-based game in which each player controls a different secret society seeking to amass money, take over other societies and ultimately rule the world. It wasn't about an adventurer fighting his way through a surrealistic landscape featuring a giant pyramid with an eyeball on top of it. I still like my idea too, though.

DOWNLOADABLE DISK IMAGE

illuminate.zip (Contains illuminate.dsk)

GAME CONTROLS

When asked to choose a weapon, you should press a number from 1-5, where 1-3 correspond to the top row of weapons and 4-5 correspond to the bottom row. Otherwise, this game's pretty self-explanatory, and so incomplete that in parser terms, the only commands that work are the directions N, S, W, E. – and only if they don't lead to unprogrammed areas of the game, which will cause it to beep out with an error. Also, you can use the command GET. All of this stuff is shown in the video earlier on this page.