People associate late \u201870s\/early \u201880s gaming with Space Invaders<\/em> and Pac-Man<\/em>, 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<\/em>, Zork<\/em> 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 \u201cinteractive fiction.\u201d<\/p>\n As well as being the first of a string of early- and mid-80s hits for its studio, Infocom, Zork<\/em> was a real achievement from a technical point of view. The game\u2019s popularity was at least partly due to its portability\u2014it 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.<\/p>\n The game\u2019s versatility was due to Infocom\u2019s forward-thinking decision to basically run its titles in what it called the Z-Machine\u2014essentially, a very early implementation of a virtual machine. The game and its successors were written in Infocom\u2019s 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.)<\/p>\n Anyway, now, almost exactly 50 years after the release of the first Zork<\/em> game, there\u2019s 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\u2019s 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\u2014except, y\u2019know, safer.<\/p>\n Zorks I <\/em>and II<\/em> have been available on the site for a while, but 1982\u2019s Zork III<\/em> was only added on May 1. It\u2019s widely considered the hardest of the original trilogy, and since it\u2019s the only one I never solved first time around, I was fascinated to look into its inner workings.<\/p>\n So what is there to see? Well, one interesting thing to do is to look at the inner workings of the parser. Zork<\/em>\u2019s parsing of input certainly isn\u2019t 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 \u201ctell thief to return gold\u201d or \u201cThief, return my gold\u201d generally met with bewilderment: \u201cI don\u2019t understand \u2018gold\u2019 in that context.\u201d)<\/p>\n Nevertheless, the Infocom parser is both simple and elegant, especially given the game\u2019s age. It relies on two simple lists: one of verbs and one of nouns. Most of these words have synonyms and abbreviations\u2014\u201clamp\u201d will work for \u201clantern,\u201d \u201cn\u201d for \u201cnorth,\u201d etc\u2014and 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. \u201cLook\u201d will return the description of the current room, while \u201clook [at] [noun]\u201d will check if the noun is present; if so, the function will return the description of the object in question, and if not, you\u2019ll be told \u201cYou can\u2019t see any [noun] here!\u201d<\/p>\n There\u2019s also support for more complexity, as we see here:<\/p>\n 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\u2019s how it works:<\/p>\n The game first checks if the can is empty. If not, it checks to see if you\u2019ve said \u201cBurn can,\u201d in which case you blow yourself up and it\u2019s game over. Otherwise, it\u2019s onto seeing where\u00a0<\/em>you\u2019re spraying the can. If you don\u2019t specify a location, the game assumes you\u2019re just spraying it into the air, in which case it\u2019s basically wasted. (Note also that the game helps you out a bit here\u2014if you just enter \u201cSpray can,\u201d it asks what you want to spray the can on.)<\/p>\n Anyway, you spray the can on yourself, then you\u2019re protected from grues for five turns. The game starts a timer (\u201cI-SPRAY,\u201d which tracks how many turns it\u2019s been since you sprayed yourself) and sets a couple of flags: \u201cSPRAYED?,\u201d which tracks whether you\u2019ve sprayed yourself and \u201cSPRAY-USED?,\u201d 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\u2019t yourself, then you\u2019re shit out of luck.<\/p>\n If there\u2019s one thing in particular for which Zork III is remembered, it\u2019s 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.<\/p>\n 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\u2019s various components and their respective locations. It turns out that quite a large portion of the game\u2019s code is devoted to the puzzle, referred to internally as the \u201cChinese puzzle.\u201d Each position in the 6\u00d76 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.<\/p>\n You might think that there would be 36 rooms within the puzzle, but no\u2014there\u2019s 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\u2019s say you drop your sword in the room with co-ordinates x: 3 y:4, then move east. You don\u2019t actually move at all\u2014the 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.<\/p>\n Optimizations like this are important when you\u2019re working with the sort of space constraints that the early 1980s imposed\u2014and those constraints were pretty severe. The entirety of Zork III\u2019<\/em>s source code\u2014which includes the verb\/noun lists, the room and object descriptions, the parser, the ZIL interpreter and the actual game code\u2014weighs in at 92 KB. In total. It\u2019s not quite Crimson Desert.<\/em><\/p>\n Still, it\u2019s also interesting to look at the many similarities between how Zork III<\/em> 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?<\/p>\n The ways in which a modern game handles such things can certainly be a lot more nuanced than in 1982\u2014Zork<\/em> has nothing like multi-stage quests, for instance\u2014but the principles are essentially the same. Set flag [x] if important event [y] has happened. Keep track of what\u2019s in the player\u2019s 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\u2019s time to run the function JIGS-UP and then restore their last savegame.<\/p>\n In that respect, there\u2019s very little difference between Zork<\/em> and Elden Ring<\/em>. Sure, the implementations of these concepts are worlds apart, but the concepts themselves remain the same.<\/p>\n Oh, and finally: as any Zork<\/em> fan knows, one thing you have to try in every game is typing, \u201cHello sailor\u201d\u2014it\u2019s kinda like the Zork-ish equivalent of the Konami cheat code, insofar as it\u2019s 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 \u201cNothing happens here.\u201d The implication is that something will happen somewhere else, but it never does. However! In Zork III, there\u2019s one location where that message becomes \u201cNothing happens yet.\u201d And if you wait long enough, then\u00a0lo and behold: cometh the hour, cometh the ancient mariner!<\/p>\n![\"Visible](\"https:\/\/gizmodo.com\/app\/uploads\/2026\/05\/Visible-Zorker.png\")
![\"Visible](\"https:\/\/gizmodo.com\/app\/uploads\/2026\/05\/Visible-Zorker-detail.jpg\")
![\"Zork](\"https:\/\/gizmodo.com\/app\/uploads\/2026\/05\/Hello-sailor.jpg\")