Exploring in Plain Text: Zork, SHRDLU, and Colossal Cave Adventure

Misplaced hype over the recent generation of chatbots and “AI” applications shows just how much technology comes full circle. Lauded as the next big development, most conversational user interfaces are actually more primitive than some programs developed in the 1960s and 1970s. Sure, Slack’s Slackbot (~2014) can interpret natural language like “tomorrow” and “next week” instead of being fed perfectly formatted dates, but check out the capabilities of 1968’s SHRDLU — a conversational program that had the user ask the computer to interact with a world of 3D shapes around it:

Person: Can a pyramid support a pyramid?

Computer: I DON’T KNOW.

Person: Stack up two pyramids.

Computer: I CAN’T.

Person: Will you please stack up both of the red blocks and either a green cube or a pyramid?

Computer: OK.

Person: Which cube is sitting on the table?


Person: Is there a large block behind a pyramid?


Person: Put a small one onto the green cube which supports a pyramid.

Computer: OK.

And this ever-so-complex modern innovation:


While SHRDLU didn’t have any more to it than the scope of the text above, it did show off how well a computer understands what you tell it. It was only a matter of time before that bizarre geometry experiment sent echoes into the formative world of video games and spawned classics like Colossal Cave Adventure and Zork.


Zork and CCA are the first major works of interactive fiction. The genre was essentially a digitalization of the era’s Choose Your Own Adventure books, with choices interpreted by the program’s language parser rather than the turn of a page. This gave the games a massive amount of flexibility. Every situation had a limitless number of branching possibilities. Even a sequence such as searching a room, finding a key, inspecting the key, and navigating back to find the locked door was too complex to be handled by Choose Your Own Adventure books. This was partially thanks to genre’s escape from physical books — which are limited to a small number of decision trees and pages — but mostly because of the computer’s ability to understand commands in an environment with lots of variables.

CCA, from 1976, was built to understand two-word phrases like “get sword” and “go north”. Zork was a step up. It could handle longer commands like “take all but paper and rug” and “go north go east wait”. The parser made the game more immersive than its rudimentary forerunners since it became more like a conversation with the game’s environment than an exercise in translating your actions into stripped-back commands. A 1979 feature in the Institute of Electrical and Electronics Engineers publication says “a great deal of the enjoyment of such games is derived by probing their responses in a sort of informal Turing test: “I wonder what it will say if I do this?” The players and designers delight in clever (or unexpected) responses to otherwise useless actions.”

Zork_photoIt’s been so long since the general user interacted with a computer through the terminal that we’ve all forgotten how powerful the natural language parsers of the 60s and 70s could be.

These days, we have terminals on our computer — Windows has cmd.exe, Mac has Terminal. In the 70s, when the first adventure games were being developed, computers were terminals. The idea of a graphical user interface was as sci-fi in the 70s as VR in the 80s. It follows that the first staggered steps of game development focused on text.

Skills with the terminal and the concept of a true power user are rarer these days, but in the 70s you couldn’t get by without your go-to text commands, shortcuts and bash scripts. The average computer user was essentially a programmer, which naturally led to a thriving scene driven by enthusiasts pushing the limits of their processors and memory. I bet that dozens of pre-Zorks were created back then, home-brewed, bootlegged, and marker-penned on floppy disks — lost forever in some filthy MIT dorm.

My excitement about interactive fiction follows my own adventures in making a text game for Secret Cave. It’s a project I’ve been picking away at for a long time, and something that Lee and I have been excitedly discussing in broken snippets of half-formed pipe dreams. The game, which will be made available on this site when it’s done, is rooted in the makeshift mythology of our corner of the internet. It uses procedural generation, creating an array of rooms and dividing them into sectors named after the output of @grimlocations. The rooms are populated with enemies, puzzles, items, and — in the true tradition of text game development — a few self-referential secrets lurking deep in a muddled network of functions and variables.The power and simplicity of the tool I’m working with — Ruby, a programming language developed in 1995 by Yukihiro “Matz” Matsumoto — is staggering when compared to the capabilities of the languages that birthed Zork and CCA. Ruby is an object-oriented programming language, which means it’s easy to define the limits of the game’s environment in code blocks known as “objects”. Objects are created from classes, which are basically templates that define the limitations of behaviour.

For example, the first room, Secret Cave Entrance, is an object of the Room class. The Room class allows its objects to have different attributes, such as a name, a description, map coordinates, and items. Using the Room class as a blueprint, the game begins by silently creating a grid and then using each grid coordinate to name rooms. The room’s attributes are then generated by pulling random values from pre-defined lists. As the game starts up, a random amount of objects from the game’s classes — Item, Enemy, and Room — are generated before, finally, the player’s limitations are defined and its coordinates are mapped to grid position [1,1].

This approach makes creating a game infinitely easier than it would have been in the 1970s. In an object-oriented game, the game is powered by simple functions that communicate with objects to transfer information. It’s close enough to plain English, and works in a very logical way. (Everything after ” # ” on a line is a comment):

def combat(player,enemy)
while player.alive? # WHILE THE PLAYER IS ALIVE...
player.swing(enemy) # THE PLAYER SWINGS AT THE ENEMY
sleep(1) # PAUSE FOR 1 SECOND
break unless enemy.alive? # IF THE ENEMY ISN'T DEAD
enemy.swing(player) # ...IT SWINGS BACK
if player.alive? == true # WHEN THE LOOP BREAKS, CHECK TO SEE WHO IS DEAD
puts "The #{enemy.name} is dead."
player.dead("The #{enemy.name} killed you.") # EXECUTE THE PLAYER'S "DEAD" FUNCTION

The Zork developers didn’t have the luxury of this flexibility. In Zork, every decision sent the program scrambling down the branches of a decision tree to check if, in this situation exactly, the player could “USE [ITEM] ON [OBJECT] IN [ROOM] WHILE [CONDITION]”. To accomplish this in an era when programming languages were more fit for solving mathematical problems quicker than a human with a scientific calculator is amazing, and there’s nothing like using powerful tools and building a weaker program to make that painfully obvious.

The advent of graphical processors, and the fact that text adventures were more of a hobbyist’s medium, left interactive fiction to die. The great leaps forward demonstrated by Infocom’s text parsers — especially 1983’s Enchanter, the most advanced text game of its time, understanding over 700 words — were absorbed into the all-encompassing world of enterprise technology, and used to inform commercial applications of AI. As noted by Thomas Colthurst in 2006, “one of history’s least noticed ironies [is that] the commercial viability of interactive fiction […] died at almost precisely the same time AI researchers discovered how to efficiently and effectively parse English sentences.”


Leave a Reply

Your email address will not be published. Required fields are marked *