Galactic Hitchhiker (1980): inspo a-go-go

TL/DR: Play Galactic Hitchhiker online

Drawn by Twitter user @NoxHorror, the picture above has nothing to do with the subject of this blogpost

Fit the First

I’ve always said that if this blog had a slogan it would probably be something like “Retroactive Fiction: Very tentatively recommended.” So imagine my surprise when I read Jason Dyer’s blogpost about the 1980 text adventure game Galactic Hitchhiker: Jason played through the game and concluded that it was “far better than it ought to be” and that he would “very tentatively recommend it” — whereupon I thought to myself, “Aha! This game and my blog were clearly meant for each other!”

A. Knight’s tale

Galactic Hitchhiker (GH), by A. Knight, is an early text adventure game — possibly the very first British text adventure game, in fact — and consequently it has a few quirks that set it apart from its later, more user-friendly successors. For example, there’s no INVENTORY command in GH — instead, you have to OPEN RUCKSACK every time you want to remind yourself of what you’re carrying. There’s no LOOK command either. And you can’t just say N to go north — you have to literally say GO NORTH, including the GO.

But, despite those gotchas, Jason found that the game wasn’t without interest. He made special mention of the interplay between two of the characters in the game: (1) the player avatar, Maurice Marina, and (2) a sort of intermediary or commentator — or Guide, if you will — called Spike, whose purpose seems to be either to encourage the player or to take the mickey out of Maurice, depending on the prevailing whim.

If it wasn’t already obvious, Galactic Hitchhiker is, er, an homage (shall we say) to Douglas Adams’s The Hitchhiker’s Guide To The Galaxy (HHGTTG), which by 1980 had already become a multimedia blockbuster, having transitioned from groundbreaking radio comedy to bestselling first novel. The name of the player avatar in GH, “Maurice Marina”, is a punny reference to a popular British car of the late 1970s, just as “Ford Prefect” in HHGTTG recalls another vintage British automobile.

The “gerbil” references, which are littered throughout GH, may have been inspired by the actual gerbils that were kept as pets by Adams’s then girlfriend. (The hyper-intelligent pan-dimensional beings in HHGTTG were originally going to be gerbils but were replaced with mice for reasons that aren’t quite clear to me at this time.) The “Rattius Corporation” in GH may be another oblique reference to the rodents of HHGTTG, as well as being a tortured play on the name of the Sirius Cybernetics corporation.

And then, of course, there’s the hitchhiking that you have to do in GH to save yourself when you are ejected into space with only a few seconds left to live — which is uncannily similar to the situation in which Arthur and Ford find themselves, in HHGTTG, just before the Heart Of Gold improbably rescues them after they too have been ejected into the vacuum of space…

Great artists steal

So it’s clear that A. Knight took inspiration from HHGTTG (the radio series and the book), while subtly and not-so-subtly tweaking names and scenarios just enough to avoid being sued for copyright infringement (a fate which nearly befell a later game that was written by Bob Chappell and released by Supersoft in 1981).

But what if inspiration had also flowed in the opposite direction? Could Galactic Hitchhiker possibly have had an influence on any part of the Hitchhiker’s Guide franchise?

Well, Douglas Adams was a notorious gadget freak and had started buying and using electronic word processors and personal computers long before most of the rest of the British public had caught the computer bug. It’s often claimed that Adams was the first person in Europe to buy an Apple Macintosh. Isn’t it at least possible, then, that he might have owned, or at least used, a Compukit UK101 (the only computer for which GH was released) — and mightn’t he even have played Galactic Hitchhiker himself? If GH had ever been brought to Adams’s attention, he was bound to have been curious about this intriguing new type of entertainment which, er, paid tribute to his own creative output.

But let’s not get carried away. Even if you grant that the wildly improbable set of circumstances that would have led to Adams actually playing GH really did fall into place, is there any part of Adams’s writing that has echoes of GH? Are there clues in Adams’s oeuvre that suggest that GH might have made a lasting impression on him?

Arguably, yes. Yes, there are.

This is the story…

The whole aim of Galactic Hitchhiker is to go through a series of picaresque adventures and then, via time travel, to return to the place where-and-when you began the game, in order to relive the events of that time-and-place from a different perspective — one of those events being your own escape from a doomed planet just before it explodes. Which also happens to be a fairly good description of the plot of Douglas Adams’s Hitchhiker’s Guide To The Galaxy game, which was written with Steve Meretzky and published by Infocom in 1984, four years after A. Knight released GH.

In GH, you eventually have to go back in time to the start of the game and realise that the person you saw picking up a ticket to ride off the planet in a starliner was in fact yourself in the future. So you pick up the ticket, board the starliner, and leave the planet before it blows up.

The plot of Adams’s HHGTTG game is more mindboggling and convoluted than that of GH, but at one point you similarly have to return to Earth and replay the events that unfolded at the start of the game, but this time you’re playing as Ford Prefect rather than Arthur Dent, so you see things from a different angle, but you still have to make sure that you and Arthur leave the planet before its violent demise.

Look, Douglas Adams was obviously clever enough to have come up with the plot for the HHGTTG game all by himself. I don’t think it’s hyperbole to say that Adams was a genius, stylistically and creatively. He packed his books and games with more ideas than any single human being could reasonably be expected to have in a lifetime. And yet nothing comes from nothing. HHGTTG wasn’t created in a vacuum. Adams’s genius was, in part, that he had a restless and curious mind that roamed far and wide, gathering vast quantities of new information from the fields of art, science, world history and popular culture, which he would twist, pummel, and polish into glittering baubles of literary and ludic delight… So he might have nicked the plot from GH. I think it’s possible, at least.

Of course, you may wish to disagree. But before you do, why not try playing Galactic Hitchhiker yourself? Because you can, fairly easily. Just click here:

>> Play Galactic Hitchhiker online <<

Babel fishery

You see, after reading Jason’s blogpost I was sufficiently intrigued to play through Galactic Hitchhiker myself. Moreover, I was then compelled to break the habit of a lifetime and dive into the strange and forbidding world of machine-code programming. My aim was to convert the game so that it would be accessible to more players — ideally, to make it playable in your web browser — because the slight problem with the original game is that it was written for the Compukit UK101, a sadly forgotten early British clone of an 8-bit Ohio Scientific computer with a 6502 CPU, and if you want to play the original today you have to go through the rather fiddly process of installing a UK101 emulator and loading the program off a “virtual tape”.

But, seeing that Galactic Hitchhiker was distributed as machine code for the 6502 CPU — the same CPU that’s in my favourite 8-bit machine (and stalwart of this blog), the BBC Micro — I thought that this might be the ideal opportunity for me to finally face my fear of coding-close-to-the-metal and to get down and dirty with assembly language: I reasoned that if the Compukit UK101 and the Beeb were both 6502-based computers, then it ought to be the work of a moment to translate the game from one to the other.

It wasn’t quite that easy, but, to my surprise, it wasn’t completely impossible either. I’ve now converted Galactic Hitchhiker for the BBC Micro, and, as a result, it can be readily played in your web browser (through the magic of JSBeeb, the in-browser BBC Micro emulator). So I hope that I’ve now fulfilled Jason’s implicit request for “a port [of GH] to something easier to work with [which] would bump it up to … well, still only tentatively recommended”:

>> Play Galactic Hitchhiker online <<

If you want all the gory details of the conversion process, then my Github repo has lots and lots of assembly code, plus some rather inadequate notes. Suffice it to say that I didn’t really have to change very much of the original code at all. Crucially, the on-screen text and the gameplay-logic are completely unaltered. The room descriptions, the vocab, the parser, the map, the puzzles — and pretty much the whole gameplay experience — are exactly as they were in the original UK101 version of the game. For better or worse.

My BBC Micro conversion of A. Knight’s game Galactic Hitchhiker

Anyway, so long, thanks for reading, and for Zark’s sake don’t panic.


Posted in Uncategorized | Tagged , , , , , , , , , , | 5 Comments

BeebScott: the Scott Adams interpreter nobody asked for

TL/DR: See my Github repo.

What is BeebScott?

It’s an umbrella term for (1) an interpreter program that runs on the 8-bit BBC Micro computer and lets you play Scott Adams text adventure games on said Beeb; and (2) a Perl script that converts TRS-80 Scott Adams v8.x .DAT files (or ScottKit .sao files) for use with said interpreter (or “terp”). But when I use the word “BeebScott” I usually mean the terp specifically.

Here’s a video demoing the process of converting the Adventureland .DAT file for use with BeebScott:

What the..?

I know, right?!


Why not?

Seriously. Why?

Largely because of Jason Compton’s game Ghost King: I was tickled by the idea of Scott Adams colliding with Shakespeare, and I thought it would be amusing to port the game to another retro platform — viz. the Beeb — but there was no way to do it. I couldn’t get my head round tautology’s existing toolchain, so that was a non-starter, and in any case I knew that his interpreter still needed work.

So I decided to embark upon the madcap scheme of writing my own interpreter and conversion utility. After all, I had form when it came to porting Scott Adams games and terps to the Beeb. And lessons had been learnt. (Yeah, right.) How hard could it be? (Answer: quite hard.)

Is BeebScott any good?

Not really, no. It’s all a bit ramshackle, to be honest. The terp, being an evolution of my v4.x Scott Adams terp for Pirate Adventure, is written in BBC BASIC, so it runs a tad slow. But it more or less works. And the inconvenience can be reduced if you use a BBC Micro emulator and just bump up the emulation speed. Plus, at time of writing, BeebScott is the only tool that can port Scott Adams or ScottKit games to the Beeb — or at least it’s the only such tool that I know how to use.

(One positive side-effect of creating BeebScott was that I ended up writing a “test game” — a game data file that can be loaded into any Scott Adams interpreter to test its ability to handle various edge cases that may appear in Scott-Adams-format games. The development of the test game was informed by a long but fruitful discussion on the forum.)

Why didn’t you just write the terp in machine code, which is fast?

Because I don’t know machine code, and I’m not enough of a masochist to start learning it now. (Also, see the video, below, of BeebScott running on a real BBC Micro with a 32MHz co-processor. Snappy!)

Sigh. Okay, fine, where can I find out more and/or play some games in this slug-slow interpreter of yours?

Thought you’d never ask. Go to my Github. And don’t come back. Thanks.


Video of BeebScott running on a BBC Micro connected to a 32MHz co-processor. (Thanks, Lee!)

Ghost King, converted with BeebScott and running in the BBC Micro emulator BeebEm
Posted in Uncategorized | Tagged , , , , , , , , , | Leave a comment

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 it turns out that BBC BASIC and C64 BASIC are not-so-distant cousins, 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.



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 but instead simply presses Enter then the program will assume “Y”). The program waits for the player to type something and 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 to 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 to line 2, above.)

5 IFr<.4THENPRINT"Well-you see an amazing "MID$("",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,

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 in fact it’s the so-called experiment in minimalism that is itself hiding behind a gamelike facade. And the supplementary material works 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

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

In other words, the game is a sort of prank. And because it’s an entry in the largest interactive fiction competition in the world (as far as I’m aware) — in which judges would expect to see substantial, content-rich games rather than twelve-liners in BASIC — it’s a particularly audacious prank. To put it another way, as Dan Fabulich did in his review, “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. Secondly, the programming style that Montfort has used is very terse and makes his program hard to read: it’s an exercise in compression or compaction. Spaces have been omitted, and multiple statements have been joined together with no real benefit — unless obfuscation was the aim — 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 is hardly the best way to teach someone how to write their first program!



When I think back to the books and magazines that I read during the home computer boom of the 1980s, what Amazing Quest most reminds me of are the times when one of the computing monthlies would pull off an elaborate (and rather juvenile) hoax. The machine I know best is the BBC Micro, so I’ll link to a very good summary of the various tricks that were played on the hapless readers of Acorn User and The Micro User. But I’m sure that the C64 would have had its own contingent of magazine writers and editors, cackling away to themselves as they sprang their latest fiendish prank on an unsuspecting readership. I wonder if any of those articles ever caught the eye 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 , , , , , , , , | 15 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: I’m an idiot.)


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 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 mavenry, 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. They don’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!



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..!?


The bug wasn’t real.



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: D’oh!

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 d’oh!



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 is available to download or to play in your web-browser. A map and a solution are also available. See Github for links:

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 BASIC on the BBC Micro, but the TRS-80 BASIC version of Adventureland always feels very sluggish to me. It takes an age to respond to almost any command, even in the latest version of MAME. Worse still, in a historical version of MESS in a Windows VM (“double emulation” as it were), not only does the game seem just as slow but also the fan in my MacBook Pro spins faster and faster till it sounds like it’s gained enough angular momentum to break free of its housing, slice through the outer case of the machine, and embed itself in my stomach.

Posted in Uncategorized | Tagged , , , , , , , | 13 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:

(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 , , , , , , , | 8 Comments

LAND (1989) — a lost MUD recreated


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:


The opening text of the BBC Micro port of LAND


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 hosting 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. Already a long-time fan of text-adventuring on the BBC Micro, he 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:


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 two hundred 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 a multiplayer game at heart — but the multiplayer feature would clearly have to be the first thing to be thrown out in the re-engineering of LAND if it was to run on a standalone 8-bit machine (or an emulator thereof) with a whopping 32 kilobytes of user memory and a blink-and-you’ll-miss-it 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 a plan. 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”. It allowed the humble Beeb to “page in” one of a number of different memory banks, as and when a program needed it, and to page it out again after use. Each memory bank contained 16 kilobytes’ worth of RAM.

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 the 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 breaking sweat, and it allows you to play LAND in most web-browsers wherever and whenever you want:

Posted in Uncategorized | Tagged , , , , , , , , , | 5 Comments

The Inform 7 website is [no longer] down

For the last few days 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 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 ( 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 British Broadcasting Corporation (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 , , , , , , , , , | 1 Comment

Maze of Madness (2018) — a torment


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.


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 (, 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

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