While exploring the remote planet Zol 1X you hear rumours of a fabulous treasure. It was buried in a tomb by Zolan, once emperor of the whole cluster, before the Terran conquest many centuries ago. Although many people have searched for it, the missing treasure has never been found. You decide to find it.
Despite the above sounding like we’re about to reach another sci-fi planet (like Forbidden City perhaps) this is really just a very abbreviated version of Adventure.
The 1982 August 5 edition of the British publication Popular Computing Weekly includes two classified ads posted by Kevin Porter for a SPECTRUM GAMESTAPE 1.
You’ll see an “adventure” marked on there. We do not possess Gamestape 1 so we are not clear what adventure that might be, but it easily could be The Zolan Adventure as published later that year by the new company Softek.
From World of Spectrum. A cave entrance, I guess? The title screen of the actual game says The Zolan Adventure.
The tape case above advertises itself as “Possibly the only truely playable adventure for the 16K Spectrum” and to be fair this is a very early game for the ZX Spectrum, so maybe if you exclude games ported from other platforms it wins by default. Perhaps the copy-editor couldn’t think of anything else to write other than “this is a game you can play from the beginning to the end”, although it turns out that’s not fully true in that the game has no end condition.
There’s an “instructions” file that seems to be broken (and what manages to pad the tape to be 16K) so I just had to wing it. What I discovered is a brand new way to be bizarrely minimalist.
This shows me moving around the outdoors, with six different moves. So not only are room descriptions reduced to almost short lines, but they get stacked right on top of each other as you move around. The general effect is odd in a way that’s hard to pin down; I got used to it, but at first it felt like moving a piece on a board game rather than an avatar through space. After enough lines the game simply clears to display the next line, but that doesn’t make the effect any less weird.
(This is different than just the overall gimmick of having scrolling text with input on the bottom; Amnesia and My Angel both play with the idea, the latter calling it “novel mode”. However, both have enough text to establish the output as readable prose.)
Part of my mapping the outdoors in progress.
As already mentioned, this is an Adventure derivative, so it starts with a building hut to go in with four items: keys, a bottle of water, a “torch” (referred to elsewhere as a lamp), and a wand. Normally you’d get to scoop all four items up, but this game rather unusually has an inventory limit of three.
Normally that’d be the sign of a lot of suffering to come but the game is so short it works out.
All of outdoors. Making this took more time than playing the rest of the game, and the only thing of interest other than the hut is a “cracked mirror” in the forest.
Going the usual valley to stream to grate route, you can take the keys from the hut and unlock them and go down to find the first of what turns out to be four treasures.
The rest of the game.
Being underground requires having the lamp (torch) on. I fortunately was experienced enough to just try ON on its own since LIGHT doesn’t work. The only items on the verb list other than directions, get/drop, and on/off are OPEN and UNLOCK. For some reason KILL magically works in one location even though it is not understood elsewhere.
I get the strong impression of an author who wanted to do a lot more but just stopped working and called it done. The honeycomb room suggests multiple exits but you can’t actually take any of them; the sole reason to go in the room is to pick up the gold key (which doesn’t unlock anything, it just is a treasure).
To the far west there’s a ledge with a silver dagger, and if you take more than one turn hanging out you’ll fall and die. Making a typo counts as a turn, so one time I typed GET DAGER (dropped the G by accident) but that was already too much; when I tried to GET DAGGER and go UP I died.
In fact, you need to avoid typos altogether while underground, because the time limit is set to be exactly the number of moves it takes to do everything. We’ve had light ultra-optimization be interesting (see the games of Paul Shave) but that’s been in cases when the game forces the player to do optimizations they might normally not bother with, throwing an item between locations to avoid an extra trip, for example. This is more like “do the steps you normally would do, just don’t make a typo”.
The result of running out of light.
With dagger in hand you can go in a pit with a snake and KILL SNAKE, then go south into a treasure room and the only sci-fi element of the game.
If you try to take the chest the “optical sensor” will trigger and you will die. This presents essentially the only puzzle in the game, and you have enough information you can solve it yourself if you like (otherwise, read on).
The cracked mirror from the aboveground gets dropped here. This is enough to confuse the sensor and get out with the chest. Once the chest is out the cave will start collapsing, so you also have a bonus time limit to travel to the surface.
The chest does not unlock or open. The only thing you can do is take it (and the other treasures) back to the hut and … wait for nothing to happen. I made the executive decision to quit and check my score.
According to this walkthrough I did the correct action; the BASIC source has no end message, and you can consider getting the chest to the hut to be a win.
I’ve always held the standpoint that short does not equal bad (… if nothing else it knocks another entry off my 1982 list quicker …) but that also doesn’t equate to good, either. Eno is a pretty good contrast; that game was set all in one room and centered around one unified puzzle, and there were enough interesting parts (and a sense of humor in the writing) that I enjoyed my short time with it. Here, my time was imbalanced for making a meaningless map (other than it looks pretty for the blog) and my puzzle-solving time was essentially 3%. The strict inventory limit and torch timer seemed to be just trying to cover for a lack of much interest. The wand that doesn’t work and honeycomb cave with no extra exits strongly suggest the author here really did plan a more proper Adventure derivative but didn’t have the chops to pull it off.
Renga in Blue 
I downloaded the TAP file and was able to run the first one with the instructions. It’s true I had to substitute line 15 for “15 goto 7000” in order to bypass a very slow intro and a subsequent undefined variable error.
So the complete instructions therefore would be:
merge “”
15 goto 7000
run
It says that the maximum score is 133, and summarizes the available commands.
I think that it’s always an achievement to include a whole adventure in 16k, but you had to make a lot of concessions for that. I’m not surprised of room descriptions being just a line or two.
Indeed, if you interrupt the adventure program, then it complains about “no more memory” continuously.
Good to hear confirmation on the score!
Scott Adams has said in an interview the way he wrote Adventureland was simply to stop when he ran out of memory.
Here I did vaguely suspect we might have an Irvin Kaputz situation where the author just couldn’t optimize themselves out of where they landed. This does feel even more inefficient than usual though. Is there anything in particular with the coding style that might have caused an issue?
Not especially. For instance, at the beginning of the program we find:
What’s the purpose of n0, n1, n2,… n8? Well, its purpose is to avoid repeating those numbers everywhere. Why? Because Sinclair BASIC stores each number in a listing both as a 40 bit wide floating number (or a 40 bit integer of 16 bits, wasting a lot of space), and its string representation, to be able to answer quickly to a “list” command. It is indeed typical to see val$(“0”) and similar in a game loader. This is a sign of being on the need to scrap as more bytes as possible.
As far as I can reckon, nt is the line number to write an answer. The variables rooms, obj, carry and lamp are more or less straightforward: they are, respectively, the maximum number of rooms, maximum number of objects, the inventory limit and the number of turns before the lamp turns off.
The rest of the code is more or less typical: rooms and objects descriptions are stored in DATAs and read from there (though the first room is hardcoded). This raises my “personal” concern of doubling the needed memory (this seems to be addressed in Atari BASIC, but I don’t think it is in Sinclair BASIC; I’m not sure, though).
One possibility to avoid that duplicity is to first load the data and then the game’s code, in a way similar to:
Then the Zalon code would carefully number its lines as 10, 20, … as well, and so the adventure code would be written over the data loader with merge, saving that space.
Another, simpler possibility would be to create a totally separated program for the data (not distributed), and inside it, save the data with save “zalon.d” data t$(), which would store the contents of the rooms array, and could be loaded later by the game code with its corresponding load… data.
Both previous possibilities are a lot more tedious, though, since any change in the data would mean to reload the data creation program, modify it, save it again, and then carry on with the adventure code. Remember we are talking about fiddling with tapes, here. Actually, I haven’t seen this merge/load… data technique used in any program.
So, no, it is not wasting memory for me, or at least not more than other adventures in BASIC.