IFComp 2020: Amazing Quest (Nick Montfort, C64 BASIC)

I have no business writing about IFComp. A huge number of incredibly impressive games have been entered into the competition over the years, but I’ve only ever played a tiny fraction of them, so I just don’t feel qualified to expound on the subject, which is why I haven’t. Instead, I’ve stuck to my comfort zone, which is whittering on about the BBC Micro.

But when I saw that one of the games in this year’s competition was written in BASIC for the C64, I knew I had to give it a go.

 

Yes or no?

What I discovered was that Amazing Quest by Nick Montfort (author of the ingenious wordplay game Ad Verbum) wasn’t really what I had hoped it would be.

What I’d been hoping for was a full-blown text adventure game on a retro platform. But what I actually got was a short twelve-line program that generates random responses to user-input.

That’s right: the input itself is completely irrelevant! The choices you’re invited to make when you play the game are binary yes/no ones, but they don’t affect the outcome of the game in any way whatsoever. The game simply ignores whatever you type into it. (So, to save time, you can just keep pressing Return or Enter.)

Consequently, I’m not sure how Amazing Quest should be classified. It’s not really a text adventure game. And it’s not a choice-based game either because your choices don’t matter. Perhaps it’s a sort of experimental piece of avant-garde retro computer art..? (I’m reaching, here.)

But whatever it is, it’s definitely a bit of a puzzle! And it seems that I’m not the only one who was left feeling a little nonplussed.

[Update: The author responds!]

But my confusion didn’t stop me trying to hack the game to port it to the BBC Micro, as is my wont. In the process of doing so, I think I found a bug — if this curious, aimless gamealike can in fact be said to have a bug (but if it can, then I’m almost certain the bug is real, unlike last time).

 

Source code download decode reload

If you want to see the BASIC source code for Amazing Quest, then all you have to do is complete a run-through of the game — after which you’ll simply be dropped onto the BASIC commandline, where, if you type in the command LIST, the program will scroll up the screen in all its 8-bit glory. Which is fine and dandy — but I wanted to get a copy of the listing in a form that I could tinker with, and I’m not familiar enough with the C64 to be able to tinker under emulation.*

Fortunately, on viewing the Javascript file that’s loaded by the webpage for the game, I happened to quickly find a text-string that turned out to be a Base64 encoding of the tokenised BASIC program. I decoded the text by simply using the command base64 in the Terminal app on a Mac, which spat out the “binary” of the tokenised C64 BASIC program, which I was then able to detokenise (i.e. convert to plain text) using an MS-DOS executable called bastext (which I found online somewhere, a while ago, when I was porting Nellan Is Thirsty). Phew.

I now had a copy of the BASIC listing of the program in a plain text file.

 

Port or starboard?

Porting the program to BBC BASIC was straightforward because BBC BASIC and C64 BASIC are not-so-distant cousins, it turns out, and I soon had the game running in a Beeb emulator. And that’s when I found what, for the sake of convenience, I shall continue to call a “bug”.

One of the random events in the game is that, every turn, there’s about a 20% chance that your fleet of ships will be attacked. The listing suggests that it was the author’s intention that if you were attacked then there should be a chance that you wouldn’t lose any ships. But the bug in the code meant that if you were attacked you would in fact always lose a ship!

The bug in the C64 program

My fix for the bug was simple and involved implementing a 50% chance of losing a ship whenever you’re attacked:

The bugfix in my BBC BASIC port

Why I chose 50% I couldn’t really say. Why I even bothered investigating and messing with the game to this extent I couldn’t really say either…

This has probably been one of the “nichest” blogposts in an already extremely niche corner of what I laughably still call the “blogosphere”.**   But if you’ve read this far, then perhaps the joke’s on you. Don’t worry, though: you’re not alone because I, like several other people, have actually tried to play Amazing Quest — so the joke’s on us too.

 

Quest!

Anyway, I’ve no idea why you’d want to, but you can play my BBC Micro port of Amazing Quest under emulation in your web-browser:

Play my BBC Micro port of Amazing Quest by Nick Montfort

I provide my port of the game under the licence specified by Nick Montfort, the author of the original C64 program, viz. Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).

 

Update: The author responds!

 

Update 2: Annotating the BASIC source code

I’ve decided to provide absurdly detailed annotations for every line of the original C64 BASIC program (because, I guess, life just isn’t tough enough right now…).

Oh, before I dive in, let me just mention that the code is hard to read because the author has used a very terse coding style. He has omitted spaces. He has concatenated multiple statements onto a single line. And he has inserted data-values throughout the program, wherever they would fit, instead of grouping them together at the end of the program, which would have improved its readability. (Far be it from me to suggest that the terseness was due to the author wanting to obfuscate the code for some reason.)

If you LIST the original source code after the program has ended, all the BASIC keywords (such as IF, PRINT, and DATA) appear in lowercase, but I reproduce them below in uppercase because that’s how they were output by bastext.

0 d=11:POKE53280,d:POKE53281,d:PRINT"{clear}{ct n}{light gray}"SPC(94)"AMAZING QUEST{down*2}":PRINT"The gods grant victory.

Line 0: A value of eleven is assigned to the variable d, which is then used to configure the background colour of the screen — I think. (I’m not familiar with the hardware details of the C64.) Next, the name of the game, “Amazing Quest”, plus some C64-specific control characters, is printed at the top of the screen, preceded by 94 spaces and followed by the intro message “The gods grant victory.”

1 DIMa$(99):j=-1:FORi=.TO4:READm(i):FORk=1TOm(i):READa$(j+k):NEXT:j=j+k:NEXT:PRINT"Now to home!

Line 1: Memory is allocated for an array named a$ which can store 99 strings of text. (I found that that was overkill, as the program actually only uses 45 strings.) A loop then reads the text-strings into the array. The text-strings can be found embedded in data statements scattered awkwardly throughout the program. Finally, the message “Now to home!” is printed on screen.

2 PRINT"{down}You";:j=6:FORi=1TO4:PRINT" "a$(j+RND(0)*m(i));:j=j+1+m(i):NEXT:PRINT".":PRINT"S"a$(RND(0)*5);

Line 2: The word “You” is printed on screen, and then a message is constructed which describes the player’s current status: the message consists of a random combination of the text-strings in the array a$. The first string in the status-message is a verb of motion or discovery, and will be one of the following: “alight on”, “are blown to”, “behold”, “detect”, “find”, “land on”. The second string in the message is the indefinite article “a”. The third string is an adjective describing the location at which the player has arrived, and will be one of “brutal”, “dark”, “dim”, “diverse”, “dry”, …, “uniform”, and “wet”: see lines 7 to 9 for the full list. The fourth string is a noun identifying the type of location, and will be one of “area”, “capital”, “moon”, “land”, “palace” and “settlement”: see line 11. (Therefore, an example status-message might be “You are blown to a dark moon”.) The status-message is printed and terminated by a full stop. Then, one of five actions is printed. The possible actions, which all begin with S, are “Sneak up and raid”, “Speak plainly”, “Sacrifice to the gods”, “Seek out help”, and “Send gifts”: see lines 3, 4 and 7 (where the actions appear without the initial S).

3 INPUT"-Y/n";z$:WAIT162,128:DATA5,neak up and raid,peak plainly,acrifice to the gods

Line 3: The player is presented with a choice of typing either “Y” or “N” to indicate whether or not they wish to perform the action that has just been printed on screen by line 2. “Y” is capitalised in order to suggest that it’s the default choice (and to imply that if the player doesn’t type any letters and simply presses Enter instead then the program will assume “Y”). The program waits for the player to type something and to press Enter. Whatever the player types is stored in the variable z$ — which is never referred to again by any part of the program: i.e. the player’s input is completely ignored! The program then pauses for a random length of time, up to a maximum of about two seconds, apparently to give the false impression that some sort of computation or processing is going on. (The rest of line 3 consists of a data statement containing the action strings mentioned in the notes on line 2, above.)

4 r=RND(0):IFr<.2THENPRINT"Attacked"RIGHT$(", a ship lost",-13*(r<.2))"!":GOTO2:DATAeek out help

Line 4: A random floating-point number between zero and 1 (with whatever precision the C64 offers) is generated and stored in the variable r, which is then used to determine whether or not the player’s fleet of ships will be attacked. If the value of r is less than 0.2 — which obviously has about a 20% chance of being true — then an attack is considered to have taken place, and the word “Attacked” is printed on screen. r is then tested again to determine whether the player has lost a ship in the attack. If that second test of the value of r succeeds, then the string “a ship lost” is printed after the word “Attacked”. (In the original version of the program, that second test of r on line 4 had a bug, whereby the test would always succeed (as long as the first test of r had already succeeded, of course) — which made the second test pointless, and meant that whenever an attack occurred the player would always lose a ship. The author has since changed the second test from r<.2 to r<.1 so that it succeeds just 50% of the time, with the result that now only half of the attacks will end in the loss of a ship.) An exclamation mark is printed to terminate the message about the attack. The program then jumps back to line 2. (The rest of line 4 consists of a data statement containing one of the action strings mentioned in the notes on line 2, above.)

5 IFr<.4THENPRINT"Well-you see an amazing "MID$("sea.sky.sun.",1+INT(RND(0)*3)*4,4):GOTO2

Line 5: Line 5 will be executed (or, strictly speaking, interpreted) if and only if the r-test at the beginning of line 4 failed. That will happen 80% of the time, which means that line 5 has an 80% chance of being executed. If line 5 is indeed executed, then we now know that the value of r must be greater than (or equal to) 0.2. The first thing that line 5 does is test the value of r again, this time to see if it’s less than 0.4. If it is, then we now know that r must have a value between 0.2 and 0.4, which will occur 20% of the time, which means that there’s a 20% chance that the remainder of line 5 will be executed. What the remainder of line 5 does is print the message “Well — you see an amazing”, followed by a random selection of one of three words: “sea”, “sky”, or “sun”. The program then jumps back to line 2.

6 d=d-1:PRINT"Yes! You win "MID$("jewels.cattle.bread.",1+INT(RND(0)*3)*7,7):IFd>.GOTO2

Line 6: Line 6 will be executed if and only if the first r-tests on lines 4 and 5 both failed. That will happen 60% of the time, so line 6 has a 60% chance of being executed. The first thing that line 6 does is decrement the value of the variable d by 1. Then it prints the message “Yes! You win” followed by a random selection of one of three words: “jewels”, “cattle”, or “bread”. The value of d is then tested to see if it’s greater than zero. If it is, then the program jumps back to line 2. But if d is equal to zero, then line 10 will be the next line to be executed (see below).

7 DATAend gifts,6,alight on,are blown to,behold,detect,find,land on,2,a,a,18,brutal
8 DATAdark,dim,diverse,dry,dusty,fine,fortified,hexagonal,huge,luminous,pious,proud
9 DATAretrograde,spare,tiny,uniform,wet,11,area,capital,moon,land,palace,settlement

Lines 7-9: Data statements containing some of the numerical and textual data that drives the program. See previous notes for explanations of how the program uses these data-values.

10 PRINT"{down}At last, the battered shuttle brings youalone home to family, hearth, rest.

Line 10: Line 10 will be executed if and only if the test of the variable d on line 6 failed. That will happen when line 6 has been executed a total of eleven times and the “You win” message has therefore been printed on screen eleven times also. Thus, the player needs eleven “wins” to complete the game. Line 10 simply prints the “victory” message on screen (“At last, the battered shuttle…”). The program then ends because line 11 contains no executable code.

11 DATAport,city,outpost,planet,stronghold:REMix! (c) 2020 nick montfort, nickm.com

Line 11: A data statement containing some of the textual data that drives the program. See previous notes for explanations of how the program uses these data-values. The last BASIC statement on line 11 is a comment (indicated by the BASIC keyword “rem”, which the author has cunningly disguised by immediately following it with the characters “ix!” to create the word “remix!”). The comment includes a copyright notice.

The original C64 BASIC source code, obtained by typing LIST after the program had ended

 

Update 4: More people comment on Amazing Quest

Mooney’s review of Amazing Quest is a little unclear. He asks, “what is it that the irony is hiding behind?”, “what is it that [Amazing Quest] purports to represent?” His answer: “an experiment in minimalism”. (The above-linked episode of the Verb Your Enthusiasm podcast makes a similar point.) But it’s the so-called experiment in minimalism that is itself hiding behind a gamelike facade. And the supplementary material is working hard to build that facade and to give the impression that the player’s choices can influence the course of the gameplay. But they can’t.

Nick Montfort has deliberately written the “Introduction” and the “Strategy Guide” to convey the false notion that the player’s choices might affect the outcome of the game — e.g. “To raid or not is an important decision”. But he has equivocated just enough, perhaps, to be able to reject accusations of outright deception.

Still, the result is that some people who played the game were led to believe, at least initially, that their choices mattered and that there might be a discoverable non-random strategy that would increase their chances of winning. For example, dgtziea said, “I know Nick Montfort […] wrote a book about IF, so I feel like I could be missing something […] There’s a separate introduction that is very nicely presented, but taken at face value, I’m not getting from these choices what it says I should be”, and “I chose all ‘good’ choices, so no raids if that matters.” See also Datalexic’s review and the thread on intfiction.org.

And it’s hard not to suspect that that was the author’s intention all along — to make players think that the game wasn’t entirely random and to get them to spend time trying to figure out how to “beat” it by conventional means.

In other words, the game is a sort of prank. And its entry into what is, as far as I’m aware, the largest interactive fiction competition in the world — in which judges would expect to see substantial, content-rich games rather than twelve-liners in BASIC — makes it a particularly audacious prank. Another way to put it might be to say, as Dan Fabulich did in his review, that “this game, this prank, treats its players disrespectfully.”

Mooney suggests that “what the program most resembles is the short ‘how to program’ demo programs that were common in magazines and books in the C64 era”. I don’t entirely agree. Firstly, I’m not sure how many C64 books or magazines looked as though they’d been written on a typewriter and photocopied. And secondly, the programming style that Montfort has employed is very terse, and makes his program hard to read: it’s an exercise in compression or compaction, where spaces have been omitted and multiple statements have been joined together, with no real benefit (unless the aim was to obfuscate), and the source code has been presented as a screenshot of the abbreviated form of C64 BASIC, which, though almost unreadable, is apparently the only form in which this particular listing can be typed into a real C64 without infringing the limit on the number of characters that can be squeezed onto a single line… This isn’t how you’d teach anyone to write their first program.

When I think about the books and periodicals that came out of the home-computing boom in the 1980s, I have to say that what Amazing Quest most reminds me of are the occasions when one of the 8-bit magazines would pull off an elaborate (if laboured) hoax. Personally, I’m only familiar with the magazines for the BBC Micro, so I can only link to a rather good summary of the various tricks that were played on unsuspecting readers in the pages of Acorn User or The Micro User. But I’m sure that the C64 would have had its own contingent of smugly chortling writers and editors too. I wonder if any of their mischievous articles ever caught the attention of a young Nick Montfort…

 

 


* The author has provided a screenshot of the program source, but the code is in a compressed form, probably tokenised C64 BASIC. Not very readable. Certainly not editable. [Update 3: The author informs me that it’s not tokenised BASIC in the screenshot. I now believe that the screenshot shows the program as it would appear on screen if you typed it into a real C64 in uppercase/PETSCII mode, using the abbreviated form of C64 BASIC.]

† Yes, I said “niche corner”. Deal with it.

** Yes, I’m now implying that a sphere can have corners. Deal with it.

Posted in Uncategorized | Tagged , , , , , , , , | 14 Comments

Digging up Adventureland (Scott Adams, 1980)

TL/DR: My BBC BASIC port of Scott Adams’s classic TRS-80 text adventure game Adventureland, as published in SoftSide magazine in 1980, is now complete and available to download or to play in your web-browser: Play Adventureland

Page 36, issue 22, SoftSide magazine, July 1980

Previously, I resurrected the original* version of Scott Adams’s second text adventure game, Pirate Adventure, and I ported it from TRS-80 BASIC to BBC BASIC — mostly for the heck of it but also because my port can be played in a web browser quite easily and the game is therefore more accessible now than it was before.

So I thought I might as well go back to the game with which Adams’s career as a digital dungeonmaster began: the TRS-80 BASIC version of Adventureland. I assumed that because I’d already ported Pirate Adventure to the Beeb, porting Adventureland would be a walk in the park.

Instead, I unexpectedly found myself puzzling over what appeared to be a forty-year-old bug. (Spoiler: it wasn’t.)

 

Dotty matrix

But first I had to get the program-listing into digital form, ready for converting. Like its successor Pirate Adventure, Adventureland had been published as a type-in listing, in the July 1980 issue of SoftSide magazine in this case, five months before Pirate Adventure appeared in BYTE.

Now, typing listings in by hand was bad enough in the 1980s, but today the twin problems of ageing and impatience have made it all but insufferable. Anyway, in the 80s most people had no choice but to type in a listing manually if they wanted to play the game. Today, though, in the internet age, there had to be another way to get hold of a digital copy of the listing, right? Even if the scan of the magazine at Archive.org wasn’t good enough to yield an accurate OCR of the text, surely someone, somewhere, had already found a way around the problem. Right..?

Front cover of the July 1980 issue of SoftSide magazine

Well, if there was a digital copy of the SoftSide listing out there, I sure as heck couldn’t find it. What I did manage to find was the source code for several ports and variants of Adventureland, but they all seemed to derive from a later version of the game (which is widely available in “.DAT” format), and not from the SoftSide listing. But it was the SoftSide listing that I was specifically interested in.

What I ended up having to do was configure MAME to emulate an 8-bit TRS-80 Model I Level II microcomputer — which isn’t a job for the fainthearted, especially if you’re trying to set up the emulation on a Mac. I then downloaded a copy of Scott Adams’s adventure interpreter on a TRS-80 disk-image: the disk-image has kindly been made available by the Data Driven Gamer, who has also supplied the game-data for Adventureland as a .WAV audio file, which takes a full twenty minutes to load into the interpreter!

Once the TRS-80 was up and running in MAME, I set about hacking the BASIC interpreter program so that it would not only read in the Adventureland game-datafile but also print out all the data values (the lists of numbers and text-strings that make up the content and logic of the game). I hacked the program using only the line-editing facilities provided by the emulated TRS-80, none of which I’d ever encountered before, and all of which I intend never to encounter again if I can possibly help it. (Retrocomputing nostalgia can be extremely overrated.) The hacked program was able to print out the data values to a “virtual printer”, which was actually just a plain text file on my Mac.

I had finally managed to acquire a digital copy of the game-data for the original* BASIC version of Adventureland, without having had to spend hours painstakingly typing in the listing myself — I had just had to spend hours figuring out how to drive a TRS-80 in MAME instead. Which was at least a new variety of frustration.

 

Separation of concerns

Anyway, I massaged the data into a form that could be pasted into the “adventure builder” program from SoftSide, which, luckily, was the same version (1.3) of the program that had been used in Pirate Adventure — and I had already ported that! So I had saved myself yet more typing (and swearing).

The adventure-builder program reads the lists of numbers and messages in the game-data and spits out a datafile. The adventure-interpreter program will then load the datafile and turn it into a playable game. Here again I managed to save myself a lot of work: last time, when porting Pirate Adventure, I had stumbled over the subtle differences between TRS-80 BASIC and BBC BASIC, which had made the task of porting the interpreter a little torturous, but now, thanks to Scott Adams’s forethought and software-design prowess, I found that I didn’t have to type in or otherwise digitise the interpreter program for Adventureland at all — instead, I was simply able to use the later version of the interpreter, from Pirate Adventure, which I had already sweated over and converted! And it seemed to work fine with Adventureland. Huzzah!

Page 44, issue 22, SoftSide magazine, July 1980

I was on the home straight. I could see the finish line and I was charging ahead, full tilt. All I had to do was tidy up the BBC BASIC programs and package them up in a disc-image, and, hey presto, they’d be playable online. So I did. And they were. And then I found the bug.

 

The alleged bug

WARNING! Spoilers ahead.

Early on in the game, you come across an axe that has the magic word BUNYON on it. If you take the axe to the quicksand bog — which happens to contain a treasure, a statue of an OX — you’ll find that you can’t SWIM out of the bog unless you either drop the axe into the bog (where it’s of no use to you) or say BUNYON, which magically transports the axe to the grove.

In my BBC BASIC port of the game, which was using the interpreter from Pirate Adventure, that was all that happened: only the axe was sent to the grove. The OX wasn’t affected by your use of the word BUNYON at all — it simply remained in the bog, and there was apparently no way to get it out! If you carried it, you couldn’t leave the bog because the OX was too heavy to swim with. The OX statue seemed to be stuck where you found it, never to be moved and never to be deposited in the treasury — which is where you have to put all the treasures if you want to win the game. So the game seemed to be unwinnable.

But if it really was impossible to complete the game with a full score, then how come nobody had noticed the bug when the game was first published in SoftSide? Where were all the errata and the corrections? Was it simply that no one had bothered to type in the original listing? Surely not — we were gluttons for punishment in the 80s, as I’ve already said…

So, what on earth was going on? Hmm. Well, perhaps the reason that none of the avid players of SoftSide’s edition of Adventureland had reported the bug, back in the day, is that they had found an alternative route to success. Because, you see, the BUNYON/OX problem has a workaround.

But the workaround requires the use of another object, which is hidden deep in the underground maze, and you’d probably only find this object much later on in the game, after you’d been playing for a good long while. So it seemed unlikely that Scott Adams had intended this workaround to be the official solution to the puzzle of the OX in the bog. If he had, he wouldn’t have bothered setting up and clueing the BUNYON solution, especially when memory was at a premium in a TRS-80 with just 16 kilobytes of RAM! There wasn’t the space to waste on red herrings — or at least not on red herrings as perfunctory as this. If BUNYON wasn’t meant to be the solution to the OX puzzle, then there was no point in including BUNYON in the game at all!

My suspicion that the BUNYON-fail was a bug was soon strengthened when I came across a copy of the game that actually seemed to have had the bug fixed. On his website, the redoubtable Jimmy Maher provides a link to the savestate that he used when he played through the TRS-80 BASIC version of Adventureland for his Digital Antiquarian blog. So here was another copy of the TRS-80 BASIC version of Adventureland that I could compare and contrast with the copy that I had just cobbled together myself.

The trouble was that Jimmy had created the savestate with an old piece of software called “MESS”, which is a long-dead ancestor of the MAME emulator, and Jimmy’s savestate was incompatible with the latest version of MAME, which, naturally enough, is what I had installed on my Mac. Aargh.

After a lot of false starts I eventually hit paydirt with a particular historical version of MESS for Windows (which I ran in a virtual machine on my Mac). That version of MESS did seem to be capable of loading Jimmy’s savestate — once I had fiddled around, configuring it to emulate a TRS-80 Model I Level II, of course. (Déjà vu, anyone?)

Wonder of wonders, the BUNYON/OX bug didn’t manifest in Jimmy’s copy of the game. Instead, BUNYON transported both the axe and the OX to the grove, as the creator had doubtless intended:

Bog-standard magic: no bugs in Jimmy Maher’s copy of Adventureland

At this point it would have been nice to inspect the data that Jimmy’s copy of the game was using, so that I could see how the putative bug had apparently been fixed. But, try as I might, I just couldn’t find a way to escape from the running BASIC program to inspect its variables, even after I’d worked out what the TRS-80 “Break” key mapped to on my Mac keyboard (Function + right-arrow, would you believe?) — because pressing Break just caused the emulated TRS-80 to hang. Nothing I did could then persuade it to respond to keyboard input!

I was at a dead end. I would just have to fix the so-called bug myself.

 

Fixing” the “bug(or vandalizing the game)

The game-data for Adventureland, as presented in the BASIC listing in SoftSide magazine, is just a comma-separated list of numbers, which doesn’t exactly trip off the tongue:

Light bedtime reading: the v4.2 game-data for Adventureland, as published in SoftSide

I could have tried to split the numbers (the “actions”) into groups of eight and to parse them all manually, with the help of Allan Moluf’s excellent guide to the Scott Adams database format (h/t pdxiv) — but even I’m not that much of a masochist! Instead, I turned to ScottKit, a very handy utility that can take the “raw” game-data and turn it into something that’s human-readable.

Of course, I first had to wrestle the game-data into a form that ScottKit could understand, which mainly involved padding the data out with a lot of empty strings and making sure that empty and non-empty strings alike had been properly enquoted. In due course I found myself looking at the “decompiled” Adventureland game-data, and there did indeed seem to be a bug in it. (In fact, ScottKit refused to proceed with the decompilation until I’d forced it to ignore bugs by specifying the “-b” flag.):

ScottKit’s decompilation of the v4.2 Adventureland game-data from SoftSide magazine

When the player said BUNYON in the quicksand, what seemed to be happening was that the game was moving the wrong object to a non-existent room! When I compared the decompiled SoftSide code with a decompilation of a widely available later version of Adventureland, the error seemed to be staring me in the face.

Surely, then, all I had to do was tweak the game-data and replace the embedded command-code 68 (“clear flag zero”) with command-code 60 (“clear the flag specified by the relevant parameter”) — and suddenly everything would fall into place: when the player said BUNYON, flag 7 would be cleared and object 47 (the OX) would be moved to room 25 (the grove), just as Scott intended.

So that’s what I did. And everything seemed to be working. Problem solved!

 

Hubris

I appeared to have fixed a forty-year-old bug in a Scott Adams game! Wow. I was about to start writing this blogpost to crow about it when I was suddenly seized by doubt: what if the bug wasn’t actually, well, you know, real..?! I mean, of course it was. It had to be. The bug was right there in my BBC BASIC port, and that port was using the original game-data, so surely that was all the proof that anyone needed..?

But, then again, there was the fact that I was using a later version of the interpreter to play the game, rather than the interpreter that was actually published together with the game-data in SoftSide. Hmm. Perhaps I’d better just check that I was, in fact, able to reproduce the bug. I would use Data Driven Gamer’s copy of the TRS-80 BASIC version of the game — that would provide independent verification that the bug was real. I was sure I’d already done this at the start of my tanglings with Adventureland, but it couldn’t hurt to quickly check again…

So I spun up the latest version of MAME again. I booted the emulated TRS-80 and waited twenty minutes for Data Driven Gamer’s tape-image to load. Then, painfully slowly,**   I made my way to the bog with the axe, and said BUNYON.

The axe vanished… but so did the OX!

The game was working fine..!?

OMFG.

The bug wasn’t real.

 

Solution

After I had come to, I began to reason thus: Data Driven Gamer’s copy of Adventureland was reading the game-data that had been published in SoftSide. And it was using the interpreter from SoftSide too. And everything was working without error.

In contrast, my port of the game was using that same SoftSide game-data but feeding it into the later version of the interpreter, from Pirate Adventure. So there had to be a key difference between version 4.2 of the interpreter (for Adventureland) and version 4.6 of the interpreter (for Pirate Adventure). And that difference must have been the cause of the BUNYON/OX bug in my initial port of Adventureland.

I had rashly assumed that the v4.6 interpreter would be backwardly compatible with the v4.2 Adventureland game-data. And, when I came across the BUNYON/OX bug, I had foolishly amended the v4.2 game-data to bring it into compliance with the v4.6 interpreter, naively thinking there was a bug in the SoftSide listing. But there wasn’t!

What I should have done instead was port the earlier version (4.2) of the interpreter — you know, the one that had actually been written with Adventureland in mind! And I should have used the v4.2 port to read the original Adventureland game-data from SoftSide, as Scott Adams had obviously intended.

I had also allowed myself to be misled by the output of ScottKit’s decompilation of the SoftSide game-data, which seemed to suggest that there was indeed a bug in the game logic. The problem was that ScottKit had been designed to work with a later version of the Scott Adams game-data format — it’s not clear exactly which version, but this linked document suggests that versions of the data format (and hence of the interpreter) up to at least v8.5 may exist. So ScottKit may have been expecting to see a much later iteration of the format than what I had been giving it.

To put it mildly: doh!

Okay. I would clearly have to bite the bullet and start porting the v4.2 interpreter to BBC BASIC — a task I’d been hoping to avoid, given how painful it had been to port v4.6 last time. Fortunately, the design of version 4.2 of the interpreter program was similar enough to version 4.6 that I found that I was able to complete the new port in record time.

Having ported version 4.2 of the interpreter (as published in SoftSide) to BBC BASIC, I now needed to test the port to see if it was working correctly with the v4.2 game-data (also as published in SoftSide). And I found that it was! I permitted myself a relieved but tentative huzzah!

Then, just as a sanity-check, I combed through the BASIC sources for the two versions of the interpreter to see if I could pin down exactly where and how they differed. This proved to be surprisingly tricky. The two programs (v4.2 and v4.6) were similar enough in structure and functionality that they induced a sort of code-blindness in me, which made it hard to spot the difference.

In the end, though, the location (if not the detail) of the difference turned out to be somewhat obvious and unsurprising: whenever a specified flag had to be cleared, the Adventureland game-data would trigger some code in the v4.2 interpreter, and that code was effectively the “handler” for “command 68”, and what that handler did was simply redirect to the handler for command 60 — and it was the handler for command 60 that finally did the work that needed doing.

The handler for command 68 in version 4.2 of the interpreter

In the later v4.6 interpreter, however, command 68 and command 60 perform two different functions. And the v4.2 Adventureland game-data had been triggering the wrong one! Hence the apparent bug whereby the OX never left the bog. Double-doh!

 

Conclusion

What did we learn?

1. I was foolish to think I had found a bug in a well-known and seminal forty-year-old game — I should have just assumed that I had somehow messed up, which was always going to be more likely. I wasted so much time chasing phantom bugs!

2. Scott Adams seems to have added new features to his interpreter at short intervals, and sometimes in surprising ways. For example, I’m still not exactly sure why command 68 simply redirects to command 60 in v4.2. It’s almost as if command 68 was being used as a placeholder for new functionality that Adams wasn’t ready to implement yet..?

3. The differences between the various versions of the Scott Adams game interpreter (and hence of the game database format) aren’t fully documented. Even the generally excellent guide by Moluf doesn’t cover all the wrinkles, variations, and updates.

4. Scott Adams’s creation of an abstract adventure interpreter was highly ingenious in the 1970s and is still impressive today.

My BBC BASIC port of the version of Adventureland that was published in SoftSide magazine in 1980 is now complete and available to download or to play in your web-browser. A map and a solution are also available. See Github for links:

https://github.com/ahope1/Beeb-Adventureland

My BBC Micro port of version 4.2 of Adventureland by Scott Adams (running in Windows BeebEm under WineBottler (a WINE wrapper) on macOS Mojave)

* My use of the word “original” is extremely context-dependent (and probably wrong).

** Perhaps I’ve been spoilt by the relative speed of BBC BASIC, but I’m always struck by the sheer sluggishness of the TRS-80 BASIC version of Adventureland: even in the latest version of MAME it takes an age to respond to almost any command. Worse, in a historical version of MESS in a Windows VM — “double emulation”, as it were — not only is the game just as slow, but also the fan in my (admittedly ageing) MacBook Pro just spins faster and faster till it sounds like it’s about to explode.

Posted in Uncategorized | Tagged , , , , , , , | 7 Comments

Scott Adams’s type-in game Pirate Adventure (BYTE, 1980)

Does anyone know of a working, playable version of Scott Adams’s text adventure game Pirate Adventure as published in the December 1980 issue of BYTE magazine?

I couldn’t find one, which was a shame because I was trying to learn about Scott Adams’s adventure game interpreter and its associated database format, and I thought that going back to the source might be interesting.

Page 192, BYTE magazine, December 1980

The BASIC program-listing in BYTE was intended to be manually typed into a TRS-80 computer, but I’m not very adept at wrangling TRS-80s, so I decided instead to convert the listing to BBC BASIC for the BBC Micro, which is very much in my wheelhouse. A quick look through the program suggested that the conversion would be straightforward: TRS-80 BASIC seemed, at a glance, very similar to its British cousin.

I was nearly right. One significant difference between the two BASICs lies in their tolerance of FOR-loops that are unterminated. On the TRS-80 you can leave a FOR-loop dangling (i.e. you can omit the matching NEXT statement) — for example by simply RETURNing early from the subroutine the loop is in — and there won’t be any problems when you try to RUN the program, no matter how many times the loop is reinitialised. Not so with BBC BASIC, which is a stickler for terminating every FOR with an explicit NEXT, and will eventually complain about “Too many FORs” if a broken loop is kicked off once too often. The biggest headache in converting Pirate Adventure to BBC BASIC was caused by tracing and tracking down the exact locations of all those missing NEXTs. It was surprisingly fiddly. I think I’ve got them all now, but there’s always that nagging doubt…

Anyway, with the possible exception of the FOR/NEXT amendments, the rest of the program didn’t really need any major alterations to run on a BBC Micro, and the converted program is still recognisable as substantially the same listing that was published in BYTE all those years ago.

The original TRS-80 code and my BBC BASIC port both use an early version of Scott Adams’s adventure interpreter program — version 4.6 according to the published listing. My conversion is the only working version of a v4.6 Scott Adams game that I know of. There are seemingly plenty of later versions of Pirate Adventure out there, online, and you can recognise them because they include the SACK and CRACKERS objects which are missing from BYTE’s version of the game, and they all seem to use a later version of the interpreter. So I think my conversion might be the only working, playable version of the BYTE listing of Pirate Adventure. But please let me know if you’re aware of any others.

The BBC BASIC port of the game seems to be stable now, and it can be played through, from start to finish, without error. (I’ve kept all the original spelling mistakes, for authenticity.)

A link to play the game online, plus a full walkthrough/solution, is available on Github:

https://github.com/ahope1/Beeb-Pirate-Adventure

(Thanks to pdxiv for giving me a head-start by typing in and correcting the original TRS-80 BASIC interpreter program, version 4.6.)

Posted in Uncategorized | Tagged , , , , , , , | 4 Comments

LAND (1989) — a lost MUD recreated

DEClogin

I’ll admit it: I don’t know very much about MUDs. (Nor am I familiar with the various spinoffs — the MUCKs, MOOs and MUSHes — that proliferated in the early days of the Net.) Many years ago, I would occasionally peek over the shoulder of someone who was engaged in playing one of those new-fangled online multiplayer games, only to shake my head in bewilderment at the strangeness of what was essentially a bunch of people who’d never met in real life, chattering away on the internet by laboriously typing and sending messages to each other in plain text. It seemed boring and weird and I was convinced it would never catch on.

Today, of course, MUDs are practically ancient history, if you’re reckoning in tech years. They were the precursors to a multiplayer online gaming industry which is worth billions of dollars, but which has apparently left the world of pure text far behind.

So, it’s quite possible that I would never have had any reason to even think about MUDs again — if it hadn’t been for an improbable set of circumstances that brought them crashing into my orbit and into contact with what has become the mainstay of this irregular blog of mine: text adventure games on the 8-bit BBC Micro computer.

You see, a wide-eyed dreamer called Darren Higgs recently got it into his head that it might be a good idea to recreate one of the earliest MUDs as a single-player text adventure game on the BBC Micro — and he actually did it, too. It’s called LAND, and you can play it online right now:

Disc999-LAND

The opening text of the BBC Micro port of LAND

History

LAND was originally a MUD that ran on the DEC mainframe computer at the University of Essex in the 1980s and 90s. The mainframe version of LAND was written by Darren Higgs (alias Toodleoo), Jonathan Cornell (Arnie), Bret(t) Giddings (Bret), and Richard Thombs (Zarf) — and it was Darren Higgs who, in 2020, ported the game to the BBC Micro.

Before LAND, the legendary Essex University mainframe had hosted the original MUD, known as MUD1, which was created by Roy Trubshaw and Richard Bartle in 1978. Professor Bartle, now a popular writer and speaker on gaming and virtual worlds, licensed MUD1 to Compuserve in 1987, which meant that the only MUD that was left running on the Essex mainframe was MIST, a “derivative” of MUD1 with “similar gameplay”.

It was around this time that Darren Higgs enrolled at Essex and, already a long-time fan of text adventuring on the BBC Micro, eventually found his way to the computer lab to see if he could have a go at this much-fabled MUD thingy that even the Beeb magazines couldn’t help talking about. Darren himself takes up the story on the Stardot forum:

Conversion

The experience of playing MIST at Essex — and then of creating his own MUD on the same machine, using Trubshaw and Bartle’s MUDDL programming language — obviously had a lasting impact on Darren because, decades later, he decided to recreate LAND for the retro scene on what was presumably one of his favourite home computers, the venerable Beeb.

On the mainframe at Essex, LAND had featured over 200 rooms, lots of puzzles, and various “mobiles” or NPCs that players could fight in order to level up in their quest for the prized status of wizardhood. Also, like any MUD, LAND was, at heart, a multiplayer game — but the multiplayer feature would clearly have to be the first thing to ditch in the re-engineering of LAND if it was to run on a standalone 8-bit machine (or an emulator thereof) which boasted a whopping 32 kilobytes of user memory and a 2MHz processor.

But even if you accept that the multiplayer experience has to go, squeezing the game into the Beeb is still a lot to ask. But Darren had an answer. Working from his original maps and notes, he wrote some bespoke text-compression routines in BBC BASIC; developed a custom “adventure engine” — a hand-written program in assembly language, targeting 6502 machine-code; and made use of seven banks of Sideways RAM.

Sideways RAM (SWRAM) is an ingenious bit of vintage machine architecture — or, as Wikipedia more prosaically puts it, it was “Acorn’s bank-switching implementation” — and it allowed the humble Beeb to “page in” one of a number of different memory banks, each containing 16 kilobytes’ worth of RAM, as and when a program needed it — and to page it out again after use.

LAND requires seven banks of SWRAM to be available — expanding the memory in the Beeb to a mind-boggling 140K or thereabouts — and that’s a quantity that was never found in actual BBC Micros back in the day, but in our current era of powerful and ubiquitous computing, one thinks nothing of configuring an emulator with the requisite mnemonic heptad. Certainly, Matt Godbolt’s BBC Micro emulator in JavaScript, JSBeeb, can provide you with seven banks of SWRAM without even breaking sweat, and it allows you to play LAND in most browsers wherever and whenever you want:

Posted in Uncategorized | Tagged , , , , , , , , , | 2 Comments

The Inform 7 website is [no longer] down

For the last few days inform7.com has been unavailable. The site is the official host of the Inform 7 IDE.

UPDATE: I’ve been informed that the outage is due to an unexpected error that affected the CMS for the Inform 7 website and that work is underway to try to bring the site back online as soon as possible.

 

I tweeted Emily Short and the IFTF Foundation to ask if they knew about the outage, and I got these replies:




I assume that the outage is due to Graham Nelson preparing the site for the upcoming changes to Inform that he announced at the recent NarraScope conference, but as far as I’m aware there hasn’t been any official warning about the outage, nor a full explanation of the reason for it, beyond the tweets I’ve quoted above.

The upshot is that if you want to download and use the current version of Inform 7 right now, you can’t. Which seems a bit of a shame.

Posted in Uncategorized | 3 Comments

One Room (1983) — the first one-room game?

One Room is a text adventure game written by Jorge Mir for the TRS-80 Color Computer. It was published as a program-listing in the first Rainbow Book of Adventures in 1983.

One Room is set in a single room (duh), in which the player-character is trapped. The object of the game is to escape from the room. One Room is therefore a contender for the title of First Ever Room-Escape Game. (Or maybe not.) It might even be the first text adventure game to be set in a single room. (But possibly not.)*

Although the published program-listing contains several bugs — which are documented at the Gaming After 40 blog (for which I’m extremely thankful) — the game is nevertheless intriguing and full of quirky ideas. It’s constructed around an innovative plot device. It comes with a built-in HELP system. It includes a surprising miscellany of objects that you can manipulate. And it’s of historical interest not only because it might be the first game of its kind but also because of the way that certain objects in the game tie in to the Tandy / Radio Shack retail empire as it was in the 1980s.

• You can play One Room online in your browser at bbcmicro.co.uk: I’ve ported the original program to BBC BASIC and fixed a few bugs to boot. (More details about the port can be found at the Stardot forum.)

• One Room also has entries at CASA (solutionarchive.com) and at the Interactive Fiction Database.

• My YouTube video features a quick playthrough of the first part of the game.

• A disk-image of the original TRS-80 version of the game is also available. It can be played in JS Mocha, the online TRS-80 CoCo emulator.


* There are people who argue that One Room isn’t actually a one-room game. Those people are wrong. Nevertheless, in the manner of the BBC (clinging white-knuckled to the dogma of “balance” while giving airtime to people whose opinions would make even Sauron blanch), I’ve decided to entertain the dissenters. Their argument seems to be that if the source code of One Room implements six distinct “locations” then it shouldn’t really be considered a one-room game at all. But what they fail to appreciate is that describing One Room as a single-room game and as a game that implements multiple locations isn’t a contradiction. A game can be both of those things at the same time. Note that in One Room you can stand in one “location” while you pick up an object in another location — which isn’t exactly normal for a game that’s not about Elastigirl. Clearly, the “locations” in One Room aren’t so much separate places as different parts of the same place, and that’s how they’re described to the player: “I am facing the north wall” or “I am looking at the floor” for example. Plus, there’s the almost too-obvious-to-mention fact that the program is referred to as a one-room game several times in the Rainbow Book of Adventures itself, including in the actual source code. What more do you need, for crying out loud? I mean, the game’s literally called One Room! If you’re going to reclassify it as No Longer A Single-Room Game, then you’ll have to check all 189 games tagged “single room” on IFDB too. And make sure you triage every entry in the L’avventura è l’avventura (One Room Game Competition) as well…

†  I was trying to exaggerate for comic effect. (Yes, the best jokes are the ones that need explanatory footnotes.)

Posted in Uncategorized | Tagged , , , , , , , , , | Leave a comment

Maze of Madness (2018) — a torment

Untitled.png

Maze of Madness is a modern game for an ancient computer (namely the 8-bit BBC Micro, which this blog seems to endlessly bang on about).

Well, I say “game”, but it’s more of a demo – a demo of a rather cruel puzzle. But it is actually solvable, if you spot the trick.

Untitled2.png

Mathbrush, the Official Unofficial Historian of IF, said that he’d never come across any other game that uses the gimmick that’s used in MoM. Whether that’s a good thing or a bad thing is not for me to say. Because unfortunately I’m the author.

You can play the game online.

More details about the game can be found at Stardot, at CASA, and at IFDB.

Posted in Uncategorized | Tagged , , , , , , , , , , | 6 Comments

Xanadu Adventure (1982) — shop till you drop

Xanadu Adventure is a text adventure game that was written for the BBC Micro by Paul Shave in 1982. Typically for the time, Shave was strongly influenced by Crowther and Woods’s Colossal Cave, and Xanadu therefore featured the requisite stream, grating, and forest-maze… But there was little chance that any jaded adventurers would be bored by these all-too-familiar surroundings because before they could start exploring the game they were forced to go shopping.

The game opens with a list of miscellaneous items including weapons, torches, food, and, um, postcards. And each item is given a price. You’re then told that you have “125 shillings to spend”, and it’s up to you to decide exactly how to spend it — although initially you have no idea which of the items are going to be of any use.

The adventure shop and the player’s limited spending power were just a couple of ways in which Xanadu Adventure distinguished itself from the average ADVENT clone. Another was that it had a two-player mode. This didn’t involve the use of RS-423 cables or multiple BBC Micros as in Graham Nelson’s Escape From Solaris, which I wrote about previously. Xanadu‘s two-player mode required players to make a fixed number of moves, alternately, on the same computer. Players could ally and combine their weapon-count to fight monsters, or they could turn around and beat the hell out of each other instead. (The latter was the more popular choice with the playtesters of the game, who happened to be the author’s sons.)

But Paul Shave had more tricks up his sleeve. He decided to introduce randomness into Xanadu and, in the process, created what might well be the first CRPG on the BBC Micro. This, I now realise, is a wonderful thing. But it caused me no end of stress when I first started playing the game. Perhaps a list of some of the key features of Xanadu Adventure will help to explain why:

  • Random object-placement! Many of the objects in the game, including some of the treasures you have to collect, are placed in random locations when you start a new game. One of the most important objects is the spare cash, which in some new games doesn’t seem to be anywhere at all (though it actually is)! The problem of having to slog around the map because of random treasure-placement is compounded by…
  • Random dwarves and dragons! They pop up when you least expect it, and you have to kill them (the dragons, at least) to move forward. And sometimes when you kill a dragon, you experience…
  • Random sword-breakage! After fighting a dragon, your sword may (or may not) get broken, so you have to trek all the way back to the blacksmith to get it re-forged. And all this trekking about, finding treasures and/or repairing swords, is particularly bothersome because of…
  • Limited light! The batteries in your torch eventually run out, so you need to go back to the shop, which is right at the beginning of the game, in order to buy some more — and no, you can’t buy them at the start of a new game because there’s a…
  • Limited inventory! There’s only a certain number of objects you can carry at one time. You can buy a bag to increase the inventory limit, but then you run into the problem of there being…
  • Limited cash! You get 125 shillings at the start of the game, most of which you have to spend straight away on weaponry and light. There is some extra cash you might come across later, but you can never be sure where or when that will be because of…
  • Random object-placement! (REPEAT UNTIL FALSE…)

If for some reason you want a deeper understanding of how Xanadu Adventure can not only amaze and impress but also drive a player to the brink of despair, then see my walkthrough video, above.

I have to admit that it might be slightly unfair of me to harp on about the relentless, exhausting unpredictability of Xanadu — because the randomness did actually lead to some interesting emergent behaviour, which I was able to exploit to make my adventuring a little easier: see the “To Catch A Dragon” section of the video, for example, which surprised even the original author.

See also the entry for Xanadu at CASA (solutionarchive.com), which links to my written walkthrough (which I now know to be flawed — because Xanadu).

There are further details about the game at Stardot.

And you can play Xanadu Adventure online at bbcmicro.co.uk.

Posted in Uncategorized | Tagged , , , , , , , , , | Leave a comment

Escape From Solaris (1984) by Graham Nelson

Previously I wrote about The Discovery, which is the first of two works of interactive fiction (known together as Galaxy’s Edge) that were written for the 8-bit BBC Micro in 1984 by Graham Nelson.

The Discovery is, more or less, a conventional single-player text adventure game. But the second game, Escape From Solaris, is for two players. It can be played either in split-screen mode on a single BBC Micro, with players taking alternate turns at the keyboard, or, unusually, on two BBC Micros connected together with a serial communications cable (RS-423).

This early form of “networked gaming” was an innovation. In fact, Escape From Solaris is the only Beeb game I know of that works in quite this way. (I did manage to find a BBC Micro version of Battleships that also used RS-423 comms between two Beebs, but Solaris is probably the only text adventure to do so.)

I’d been wanting to try to get the game running on two machines for quite a while, and last year I finally got around to it (after taking ages to realise that the way the comms lead had to be wired up was actually rather obvious). See the YouTube video above. Thanks to Lee for letting me borrow his setup and for helping me demo the game.

If you want to try Escape From Solaris yourself, you can play the game in an emulator in your browser, but only in split-screen mode in a single window (because networked Beebs are not included):

Play Escape From Solaris online

Posted in Uncategorized | Tagged , , , , , , , , , | 4 Comments

Skill, Stamina and Luck

p03k3mlq

In February 2016, the BBC broadcast a radio documentary about interactive fiction called Skill, Stamina and Luck. It focused largely on gamebooks like Fighting Fantasy, Choose Your Own Adventure, and some interesting historical examples — but it also took in parser fiction (text adventure games) and Twine.

To accompany the programme, the BBC created an interesting “interactive audio history of interactive fiction” in the form of a Twine web app, which included a simulation of a play-by-telephone adaptation of a Fighting Fantasy book and many audio clips of interviews, some new and some from the archive, with people like Steve Jackson, Ian Livingstone, Andrea Phillips and Emily Short.

(The Twine also included the audio from this episode of Micro Live, in which the BBC visited the offices of Infocom.)

The Twine app had been taken down from the BBC website, but it’s now been made available again by Steve Alderton, Content Producer for the BBC Taster pilots.

Try it here: http://www.bbc.co.uk/taster/projects/skill-stamina-and-luck

Posted in Uncategorized | Tagged , , , , , , | Leave a comment