People associate late ‘70s/early ‘80s gaming with Space Invaders and Pac-Man, but away from the arcades, you were likely to find early home computer enthusiasts poring, and scratching their heads, over a very different sort of game. Along with its spiritual predecessor Colossal Cave Adventure, Zork and its sequels pioneered the genre of the text adventure, graphics-less parser-based games that have seen a renaissance years under the more highbrow title “interactive fiction.”
As well as being the first of a string of early- and mid-80s hits for its studio, Infocom, Zork was a real achievement from a technical point of view. The game’s popularity was at least partly due to its portability—it could run on a Commodore 64 as easily as it could run on a 8086 PC or a ZX Spectrum, which was a huge advantage in an era where consumers could choose between dozens of microcomputers, each largely incompatible with the others.
The game’s versatility was due to Infocom’s forward-thinking decision to basically run its titles in what it called the Z-Machine—essentially, a very early implementation of a virtual machine. The game and its successors were written in Infocom’s proprietary high-level Zork Implementation Language, which was then compiled into a lower-level instruction set called Z-Code, which was executed by the Z-Machine environment. This meant that instead of having to rewrite their games from scratch for every new system they wanted to support, Infocom had only to write a new Z-Code interpreter for each system. (For anyone interested, a bunch of excellent documentation about how the Z-Machine worked can be found here.)
Anyway, now, almost exactly 50 years after the release of the first Zork game, there’s a site that lifts the curtain on the Z-Machine in real time. The Visible Zorker is the work of interactive fiction maven Andrew Plotkin, and it tracks the state of a game while it’s running, letting the player see how the Z-Machine puts their commands into action. The effect is rather like running a car with the hood open so that you can see exactly what pressing the gas pedal does within the engine—except, y’know, safer.
Zorks I and II have been available on the site for a while, but 1982’s Zork III was only added on May 1. It’s widely considered the hardest of the original trilogy, and since it’s the only one I never solved first time around, I was fascinated to look into its inner workings.
So what is there to see? Well, one interesting thing to do is to look at the inner workings of the parser. Zork’s parsing of input certainly isn’t perfect, and many of us spent hours trying to get the game to understand something we want to try doing. (Speech was a particular problem for early parsers: commands like “tell thief to return gold” or “Thief, return my gold” generally met with bewilderment: “I don’t understand ‘gold’ in that context.”)
Nevertheless, the Infocom parser is both simple and elegant, especially given the game’s age. It relies on two simple lists: one of verbs and one of nouns. Most of these words have synonyms and abbreviations—“lamp” will work for “lantern,” “n” for “north,” etc—and there are also allowances made for spelling errors. Each verb has an associated function, some of which require nouns as arguments, and some which can work both ways. “Look” will return the description of the current room, while “look [at] [noun]” will check if the noun is present; if so, the function will return the description of the object in question, and if not, you’ll be told “You can’t see any [noun] here!”
There’s also support for more complexity, as we see here:
This code deals with spraying a can of Frobozz Magic Grue Repellent. (Grues, as any fan knows, are monsters that lurk in the dark and will eat fools who venture into lightless areas without a torch or lantern.) Here’s how it works:
The game first checks if the can is empty. If not, it checks to see if you’ve said “Burn can,” in which case you blow yourself up and it’s game over. Otherwise, it’s onto seeing where you’re spraying the can. If you don’t specify a location, the game assumes you’re just spraying it into the air, in which case it’s basically wasted. (Note also that the game helps you out a bit here—if you just enter “Spray can,” it asks what you want to spray the can on.)
Anyway, you spray the can on yourself, then you’re protected from grues for five turns. The game starts a timer (“I-SPRAY,” which tracks how many turns it’s been since you sprayed yourself) and sets a couple of flags: “SPRAYED?,” which tracks whether you’ve sprayed yourself and “SPRAY-USED?,” which tracks whether the can has been emptied. We also see here how easily you can get the game into an unwinnable state: if you spray the repellent on something that isn’t yourself, then you’re shit out of luck.
If there’s one thing in particular for which Zork III is remembered, it’s the notorious Royal Puzzle, a life-sized version of one of those puzzles where you have to slide tiles around a grid. Solving a puzzle like this would be difficult enough in a game with a graphical representation of the environment; solving it in a parser-based text game, even with the rudimentary aid the game gives you, requires the spatial awareness of some sort of architectural savant and/or the patience of a saint.
Having neither of these things meant that Zork III was the one Zork game I did not solve as a kid, and I was interested to see how the game kept track of the puzzle’s various components and their respective locations. It turns out that quite a large portion of the game’s code is devoted to the puzzle, referred to internally as the “Chinese puzzle.” Each position in the 6×6 grid is stored as a single number in a 36-element array, with the position of various walls being updated as the player moves them.
You might think that there would be 36 rooms within the puzzle, but no—there’s only one, presumably because adding 36 largely identical rooms to the game would be a waste of memory. (For reference, there are 60 or so rooms in the entire rest of the game.) The single puzzle room is always the room housing the player, which requires the game to keep track of things like items and swap them in and out of the room as necessary: let’s say you drop your sword in the room with co-ordinates x: 3 y:4, then move east. You don’t actually move at all—the game just updates your position to x:4 y:4 and removes the sword. If you move west again, the game remembers that this is the room in which you dropped the sword, so it updates your position again and returns the sword to the room.
Optimizations like this are important when you’re working with the sort of space constraints that the early 1980s imposed—and those constraints were pretty severe. The entirety of Zork III’s source code—which includes the verb/noun lists, the room and object descriptions, the parser, the ZIL interpreter and the actual game code—weighs in at 92 KB. In total. It’s not quite Crimson Desert.
Still, it’s also interesting to look at the many similarities between how Zork III and modern games work. Ultimately, a game is just a collection of state variables: has a player been to this room yet? Have they killed this monster? Have they talked to this NPC and been given this quest? How far along with the quest are they? What are they carrying right now? What level is their health at? How has the game world changed since the game began?
The ways in which a modern game handles such things can certainly be a lot more nuanced than in 1982—Zork has nothing like multi-stage quests, for instance—but the principles are essentially the same. Set flag [x] if important event [y] has happened. Keep track of what’s in the player’s inventory. Keep track of timers. The player just got hit by a monster? Subtract [x] from their health. Is their health now under 0? Yes? Oh dear. It’s time to run the function JIGS-UP and then restore their last savegame.
In that respect, there’s very little difference between Zork and Elden Ring. Sure, the implementations of these concepts are worlds apart, but the concepts themselves remain the same.
Oh, and finally: as any Zork fan knows, one thing you have to try in every game is typing, “Hello sailor”—it’s kinda like the Zork-ish equivalent of the Konami cheat code, insofar as it’s something you try entering in the expectation that something might happen as a result. The thing is, all throughout Zork (where the phrase is first encountered) and Zork II, the only response you ever get is “Nothing happens here.” The implication is that something will happen somewhere else, but it never does. However! In Zork III, there’s one location where that message becomes “Nothing happens yet.” And if you wait long enough, then lo and behold: cometh the hour, cometh the ancient mariner!
