Renga in Blue   Interactive fiction and the All the Adventures project

(Continued from my previous posts.)

Complexity in ZENO is reserved for the computer system it embodies. Your survival is totally dependent on your ability to program your way out of trouble.

— from the instructions for the game

I’ve “finished” the game. It feels like a “first stab” at content from the author who intended more versions (as quite explicitly mentioned in the game itself). It’s quite possible Mitchell was distracted by his new job within IBM, as he wrote Zeno in January and February of 1983, and he started work the same year on the official launch of the IBM Personal Computer in Europe; the launch gets press mention in a March 1983 issue of Practical Computing. I might follow that and say “so he was done with Zeno” except: he did do a sequel of sorts. More on that at the end!

To make one thing clear right away for visualization purposes: this is the USS Zeno, that is, we’re on a crippled starship, not a base.

Last time I had explored the area…

…and was attempting to a.) program the robot and b.) deal with the alien invasion. (In the middle you can have a power shutdown, which turns off the air pump.)

The game mentions “robots” plural and “aliens” plural at points but there’s only one alien (I’m guessing the plural part was aspirational). So you can think of this as a short story where we are on a remote outpost and get attacked by aliens (one at a time), and need to handle it by sending the robot. The alien always invades in the hangar, so you don’t have to have some kind of rotating complex setup in the code. There’s a second crisis after the alien which I’ll talk about when I get there.

The robot is on the second floor; it needs to go to the fourth floor where the action is.

The alert program on. It turns out you don’t really want the shields on — the alien can bust through anyway, and it just drains energy.

It’s easier to stay on floor 1 at first as the computer is fully capable of editing; while terminals can run programs, they can’t edit them (at least by default; the game implies there is a way to enable terminal editing, but I never figured out how). So we need, in sequence

a.) the elevator to go to floor 2
b.) the elevator door to open
c.) the robot to enter the elevator
d.) the elevator door to close
e.) the elevator to go to floor 4
f.) the elevator door to open
g.) the robot to leave the elevator

Entering the hatch seems to be optional, as the aliens will seem to arrive just inside the hatch rather than outside.

This is, straightforwardly:

LIFT_DOOR = CLOSE
LIFT_FLOOR = 2
LIFT_DOOR = OPEN
ROBOT = DOOR
LIFT_DOOR = CLOSE
LIFT_FLOOR = 4
ROBOT = WAIT
ROBOT = WAIT
LIFT_DOOR = OPEN
ROBOT = DOOR

I also made a separate program to send the lift back to the first floor so I could get back on.

LIFT_DOOR = CLOSE
LIFT_FLOOR = 1
LIFT_DOOR = OPEN

Turn 24 is when the alien(s) arrive (“MSG at 24 from Rigel IV: aliens in your sector”). There are other messages which seem to not necessarily be consistent; I’ve seen

from Beta Crucis III: USS Enterprise lost to aliens

and

from Fomalhaut IX: destroy USS Enterprise on sight

and

from USS Enterprise: surrender or die!

but not always, and I’m not sure if there’s some system to it. When the aliens appeared I applied a program where ROBOT = LASER was executed multiple times (I think only once is needed, but I wanted to be safe).

Regarding the “power surge” message, every once in a while the air pump turns off. I’ve been turning it back on manually, because I’ve done everything from the computer room, but you could implement code that automatically checks if the pump is off and turn it on again if so.

I was prepared to stop there and had a post ready last week, but I tested out waiting for more turns and found one more wrinkle to the plot which forced me to play for longer.

At 200 turns exactly a photon storm hits and kills you if you are on the ship. So the only way to survive is to … be off the ship! One way to do this is to simply fling yourself through the hangar door while wearing a space suit.

The full list of descriptions:

A klick or so away is the huge, crippled bulk of USS Zeno. While far off to your right can be seen the strange geometry of an alien battle cruiser.

You are falling slowly towards the moon. High above you is the USS ZENO.

You are falling rapidly towards the moon. It looks as though you will impact somewhere west of the Alps.

You are about to hit the lunar surface, near the crater Aristoteles.

You are standing in the centre of a small crater.

On the crater you have nothing to do now but wait for your suit to run out of oxygen. Unless you’ve planned beforehand!

Remember this game has a matter transmitter. I hadn’t noodled with it yet, but found rather than using the “desk terminal” (which you can do by setting MT_MODE = MANUAL) I had an easier time just writing programs.

MT_MODE = AUTO
MT_BEAM = 565-23 84-212

This will teleport the robot at the start of the game from the second floor to the first floor.

The numbers can come from the robot itself, with the simple program

probe = ON
say location now POSITION

although while I state that with authority now, the actual gameplay puzzling out everything above took over an hour.

Due to confusing wording in the instructions, I hit this a few times. You need to apply a number to WAIT, it does not default to 1.

I was able to get the robot to jump out of the ship but unfortunately the probe was not giving me correct locations! There seems to be an outright bug here as the robot is visible in all the “in space” locations even though based on my time it should have only been visible at the crater.

This means I had no method of figuring out the coordinates for saving myself, and I’m not sure if the game provided one (because, again, the robot seems buggy, which indicates what happened to me is unintentional). I resorted to checking the source code. Fortunately, REXX code really is easy to read.

coordinates = ’84-212 46-975 565-23 690-34 54-367 89-021 385-34′ ,
’76-421 17-400 20-615 95-461′

84-212 is the start room (I knew this from the robot probe). The later numbers are the ones in space. Unfortunately I couldn’t just activate the transmitter straight away when I needed to escape because you must be wearing the space suit, and you can’t type while wearing a space suit (fair). So my escape program came out like this:

MT_MODE = AUTO
WAIT 2
MT_BEAM = 84-212 95-461
WAIT 9
MT_BEAM = 95-461 84-212

This gives just enough time to step away from the terminal and put on the space suit before being yanked away. Then after a set time (when the storm has ended) it reverses the teleport back to the start.

Given I can then wait an unlimited number of turns from here, I call that victory.

As I already mentioned, Mitchell clearly had other plans but got yanked away by job obligations given the timing of the IBM PC launch in the UK. Fortunately, he was able to return to ZENO several years later with a book and accompanying DOS program.

Courtesy Gunther Schmidl.

I’m not going to give details right now, other than the game still has a robot to command, but you now also can use normal adventure-movement commands (it wants a verb and a noun, shock!) and there’s a full plot and so forth. So ZENO mainframe could even be considered the template for the book version of the game.

You wake.

You seem to be encased in a misty whiteness that presses in on you. For a moment you panic, then you remember Dr. Flyte telling you that this is how it would be. “Just push” he said. It seems a long time ago.

You are sitting in a hibernation pod. It’s closed. The control knob for the pod is turned off.

The book-game is also short (by necessity of it being from a book) but we’ll save looking at it in the future (copyright on the game is 1986).

Programming is very much a craft, and this original book is aimed at all those who are looking for something to broaden their programming horizons. The author uses the implementation of adventure or fantasy games as a medium for introducing the tasks of designing, programming and testing. Adventure games offer an amazingly rich vein for this purpose; there’s scarcely a corner of computer science they don’t or can’t touch. They offer a considerable challenge, even to the most skilful programmer, and provide stimulating intellectual puzzles, humour and real enjoyment.

Returning to the mainframe version of ZENO, I do think having a programming game embedded in an adventure was a marvelous idea. I did spend more than half my time struggling with non-adventure things, some of which was not the fault of the game (emulator crashes, etc.) and some which definitely was (ambiguous instructions). With the editor, I finally found that if I typed Input by itself, the game would make a big set of blank lines, and then I could mouse-click on the first line and paste from my computer’s notebook. (I’ve never used something so torturous before, and yes, I’ve used vi, and can even tell you the difference between exiting with :x and exiting with :q.) I otherwise found code-editing to be an enormous hassle and it was very easy to try to insert a line and have it in the right place, or push the wrong direction key and have the game refusing to acknowledge any input until you restore the balance (or accidentally hit a function key that’s not one of the designated one, which crashes the whole game). Still, the learning is what I call a “perfect embedding” which is rare for educational software; within the fiction of the universe created it makes sense to use the programming in its native format. Compare with the allegedly educational Microworld (1981) which required deciphering puns rather than concrete engagement with the internals of the computer.

Coming up: a return to Australia.