AdventureA world at the other end of a sentence

You have found a lamp, a set of keys and a way underground. There are no pictures of the cave. There is no little figure to steer around it. You type what you want to do, press Return, and wait to find out whether it worked.

Soon you are drawing a map. You have started remembering places you have never seen. An object that seemed like a prize has become a problem, and something you left behind suddenly seems rather useful.

The remarkable thing is how much of this world starts to feel like somewhere you know. You remember the way back to the building. You have a plan for that awkward passage. You are fairly sure the game is being unreasonable about the bird, although perhaps there is something you have missed.

Adventure gives you words, but it also gives you things to do with them. The lamp can be picked up. The grate can be unlocked. The cave remembers what you have changed, and sometimes makes you wish you had thought a little further ahead. Let’s go underground and see how it manages all of that.

The cave we are exploring is the 350-point game developed by Will Crowther and Don Woods, expanded by Woods in 1977. [1–3]

Spoilers. The entrance is discussed openly. Three worked puzzle examples are folded away below. The ending’s structure is discussed, but its winning command sequence and a complete cave map are omitted.

A road, a building and a reason to investigate

Adventure starts with things you can understand. There is a road, a small building and a stream. The building invites investigation; the water suggests somewhere to go. You do not need to understand the scoring system to have an idea worth trying.

Inside are supplies. Take the lamp and it joins your inventory, the things you carry. Leave the building, come back, and it is still yours. Put it down and the room can describe it again. The computer has remembered a change in the world. 2

We have barely begun, but already this is a different pleasure from reading about someone else’s expedition. You can change what happens. The words on screen describe a place whose contents depend on what you have done there.

Soon there is a grate in the way. You have found a route underground and cannot use it. The keys give you something to try; unlocking the grate gives you somewhere new to go. A few words and a small change in the program have opened up the cave.

By the time you get through, you have explored, collected supplies and used one thing to change another. You have also had a small success worth following up. What is down there?

The player is running a model too

You try a passage and end up somewhere familiar. Nothing has opened, no treasure has appeared and the score has not rewarded you. Still, that was useful. You can add a line to your map.

While the program remembers where things are, you are building your own picture of the cave. Perhaps those two passages meet. Perhaps that object will be useful later. Perhaps a phrase you skimmed past was a clue. You read, imagine a possibility, try it and make sense of the reply.

Learning a word the game accepts can be as helpful as finding a tool. So can ruling out an idea. Some progress happens in the program; some happens in your head.

The character may have lost everything, but the player remembers. On a second expedition, you can head straight for something that took ages to find the first time. Adventure’s cave is becoming familiar territory.

There is room for someone else beside the keyboard, too. One person can type while another spots a clue or disputes the map. Sharing the puzzle is one pleasure the form allows, although access to a machine, time and confidence with its language still decide who gets the chance to join in.

What the parser actually does

You can see the lamp. You know what you want to do with it. Getting the computer to understand you is another matter.

The part of the program that makes sense of your request is called the parser. It has to turn the words you type into an action the game knows how to attempt. Adventure cannot understand everything you might say, but it has a few ways to meet you halfway.

Adventure works with short requests. A direction can be enough on its own; an action and an object can tell it more. GET and TAKE mean the same thing to it, while LAMP and LANTERN refer to the same possession. It sorts recognised words into groups such as directions, objects and actions, then works out what to do with them. 2

There are shortcuts, too. N and NE save you typing whole directions. They work because the game knows those abbreviations; inventing your own may still leave it baffled.

There is more flexibility than the two-word limit suggests. You can give a direction on its own, leave a request unfinished and answer the follow-up, or name an object before saying what to do with it.

What you type	What happens
TAKE, then LAMP	The game asks what you want to take, then completes the request when you answer.
LAMP, then DROP	You can start with the object and follow up with what you want to do.
LAMP TAKE	The object and action can arrive in reverse order.
TAKE LANTERN while carrying the lamp	The game recognises its other name and knows you already have it.

These are small kindnesses, but they make a difference. After TAKE, you get to finish the thought instead of starting the whole request again. 2

Recognising a request is only the beginning

Suppose the parser recognises TAKE LAMP. The game still has work to do. Is the lamp here? Are you already carrying it? Is there room to carry another object? Is this an ordinary object, or does taking it need a special rule?

If the wording is wrong, we have a syntax problem: the program cannot make sense of the request’s form. If it understands us but the lamp is elsewhere, the problem is the world state, the situation at this moment.

That distinction matters when you are staring at a refusal. Should you try another word, or go and find the lamp? A reply that helps you choose keeps the conversation moving. A vague one can send you round in circles, changing perfectly good words while the object you need is in another room.

How a richer parser changes the bargain

Sooner or later, we want to say something that won’t fit into two words. Suppose we invent a small puzzle with a key and a box:

PUT THE BRASS KEY IN THE BOX

This is our example, not a command from Adventure. But the intention is easy for us to follow. Something is being moved, and we have said where it should go. “Brass” might distinguish this key from another one. “In” tells us how the key and box are meant to relate.

A more capable parser can work through several questions:

1. Which words are these? Split the input into tokens and recognise vocabulary or permitted values.
2. What form does the request have? Match a grammatical pattern such as putting one object inside another.
3. Which things are meant? Resolve the noun phrases against objects the player can refer to.
4. Is anything missing or ambiguous? Infer a safe default or ask a focused question.
5. What action should the game attempt? Pass the identified action and object references to the world rules.

There are different ways to build this machinery. The diagram pulls apart the jobs a richer parser has to do, so we can follow one request through them.

Now add a second key. Which one did you mean? We have reached object resolution, the work of matching your words to particular things. “Brass key” can settle the choice. If there is only one suitable key, the game may be able to work it out for itself. If you call it “it” in the next request, the parser needs to remember what you were talking about.

Finding the right object is only part of it. Suppose you can see a key behind glass. You might be able to examine it, yet still be unable to pick it up. Systems such as Inform use scope rules to decide which things a command can refer to; the world’s other rules decide what you can actually do with them. Being visible, being known about and being within reach need not be the same thing. The action you are trying matters too. [6–8]

The Zork designers’ 1979 paper describes a parser producing an action and object references, using adjectives, prepositions and contextual questions. It also describes general actions with special behaviour attached to particular objects and situations. This gave the authors more expressive requests and more reusable behaviour than treating each sentence as an isolated puzzle command. 9

A menu could offer “Put the key in the box” as an option. We would know the action was available as soon as we saw it. With a parser, proposing the action is part of the discovery. That freedom can be exciting: perhaps the game will let us try an idea it hasn’t advertised.

It can also promise more than the author has built. A wonderfully capable parser is little comfort if the world has no response to the sensible thing you just asked to do. Language handling and implemented possibilities have to grow together.

To try the separation yourself, our two-word parser in Spectrum BASIC comes with an original tiny adventure and a vocabulary you can edit. A Z80 version shows another way to store and recognise the same commands. Both leave the world and its rules to the game.

A refusal can still be useful feedback

A failed request can still leave you better off. Perhaps you used a word the game doesn’t know. Perhaps it knows exactly what you mean, but something is in the way. Those replies point towards quite different next attempts.

Kind of difficulty	What the player needs to learn
Unknown vocabulary	The program has not recognised a word; another permitted expression may help.
Incomplete request	It understands enough to ask what object, destination or instrument is missing.
Ambiguous reference	More than one object fits; it should identify the choice. This is a wider parser concern, not a general disambiguation feature demonstrated in Adventure.
Object unavailable	The named thing is understood, but cannot be referred to or reached in this situation.
Rule prevents action	The request is understood and the thing is available, but a condition is unmet: a lock, a carrying limit, a frightened creature.
Valid action with little effect	The experiment was possible, but did not produce a useful change. A distinctive response can still acknowledge the idea.

The writing sets up expectations before we type anything. Mention a prominent handle and someone will pull it. Describe a loose stone and someone will try to move it. An author cannot prepare for everything we might imagine, but these are reasonable things to expect us to try.

We don’t need every reply to give away the answer. We do need something to work with. A good response lets a failed experiment narrow the field.

At its best, this feels like getting closer: the idea didn’t work, but now you know why. At its worst, you are hunting for a word the author happened to choose. Adventure gives us enough of both to make the difference worth paying attention to.

The cave is data with rules attached

Leave the building and come back. How does the game know where you are? How does it know whether you left the lamp there?

Each “room” is a location the program can distinguish. It might be a chamber underground, a stretch of forest or a ledge. The name is convenient, even when there are no walls or roof.

The map can be represented as a directed graph: locations are nodes, and permitted journeys connect them. “Directed” matters. Going east from one place does not, by itself, guarantee that going west from the destination will return you. Authors can model winding passages, one-way routes, magical travel or deliberate disorientation without drawing a continuous landscape.

Adventure stores descriptions, routes, vocabulary and messages as data, with code to apply the rules. Each location has its own identity. Two places can have identical descriptions and still lead to different destinations, which is useful if you want to make a maze rather confusing. 23

The lamp needs its own record. The word LAMP lets us refer to it, but the game also has to remember where it is and whether it is lit. Move it, extinguish it or leave it behind, and the next description may need to change. Those remembered facts are what let a handful of words behave like a possession.

Here is a simplified description of a possible state, written for us to reason about rather than as runnable Adventure code:

Fact	Example value	Why it matters
Player location	Outside the grate	Selects the current surroundings and available routes.
Lamp location	Carried	Makes it available to the player.
Lamp state	On	May provide light where the cave itself does not.
Lamp energy	Some remaining amount	Limits how long that light lasts.
Grate state	Locked	Prevents a particular journey.
Keys location	Carried	Gives us something to try on the lock.

A description can then combine relatively fixed prose with changing information. It can describe the chamber, list the objects currently there and report that a barrier is open. We do not need a separate handcrafted paragraph for every combination.

All those accounts need to agree. If the game refuses to let you take something, you expect to find it where you left it. An object that disappears after a failed request, or appears both on the floor and in your inventory, breaks our trust in the cave. A failed attempt may still cost a turn; it should not accidentally move the object as well.

A believable object is not a complete simulation

The bird and cage behave as a relationship, but Adventure does not need a universal model of every possible container to implement them. Its special rules keep those particular objects together when carried. Liquids, the bottle, immovable scenery and objects appearing from more than one location also receive particular treatment. 2

Later systems such as Inform provide more general containment and visibility rules. A key can be in a box, the box in a room, and the box’s open or transparent state can affect what can be seen and reached. That is a useful contrast, rather than a feature to read back into Adventure. 67

We learn a game’s habits as we play. If boxes usually hold things, we will try putting something in the next box we find. A special case can be a lovely surprise, but after too many unexplained exceptions we stop trusting what we have learnt. The next puzzle becomes a guess about which rules the author has decided to bend.

Mapping, landmarks and the pleasure of getting lost

A few locations in, a scrap of paper starts to look useful. Draw a place, add an exit, then try to join it to the next place. Before long you are adding notes: something to investigate, an object left behind, a passage you couldn’t use.

Soon a line between two places needs a note of its own. Can you always get through, or only after opening the grate? A magic word may connect places that seem far apart. A passage you used empty-handed may refuse you when you bring back a treasure. Your map is starting to record rules as well as places.

In the famous maze, even knowing where you are becomes a puzzle. Different places have similar descriptions, and their exits connect differently. Have you come back, or found another place that sounds the same? Leaving an object behind gives you something to recognise on a return visit.

Leave some food as a marker. Take a route that loops back and there it is again: this must be the same place. At last, something to put on the map with confidence. We have found no treasure, but we have found our bearings. 2

There is real satisfaction in turning confusing passages into a place you understand. A landmark helps; so does recognising a route from the far side or finding a shortcut home. Your untidy sketch starts to make sense.

The maze asks how much of that work you enjoy. Leaving markers and testing exits can be absorbing detective work. It can also become an evening of administration. If every direction needs the same laborious check, the pleasure of discovery has to carry a lot of repetition.

Puzzles are relationships, not just locked doors

The grate gave us a clear problem: there is somewhere we want to go, and something is stopping us. Find the right tool and the cave gets larger. Designers call that sort of obstacle a gate.

Other discoveries change places we already know. A shortcut can make a long journey manageable. Finding a new use for an old object can send us back to a passage we gave up on earlier. The answer might depend on a word, a creature, the order in which we act, or a rule we haven’t spotted yet.

When one achievement needs another, we have a dependency. We need the keys before we can unlock the grate. A puzzle may need several things to come together, or allow more than one way through. These arrangements shape an evening’s play. A chain of problems gives us one thing to concentrate on; several open branches let us go and try something else when we are stuck.

Then Adventure makes a nuisance of something you thought was useful. Carrying every tool seems sensible, until one of them prevents another idea from working. The cave starts asking you to think about what things do together.

Worked puzzle: the bird, cage and rod — selected early-game spoilers

You have found a bird and a cage. That looks promising. Without the cage, you can approach the bird but cannot carry it. Bring the cage along with the rod, though, and the bird becomes disturbed. Put the rod down and you can catch it.

It was tempting to keep changing the command. The answer involved putting something down: you need the cage and you must leave behind the thing that frightens the bird. Having the right equipment is only half the answer.

The captured bird can then remove the snake blocking routes from the Hall of the Mountain King. Release it and a way forward opens. Something that first seemed like another problem has become the answer to one elsewhere in the cave. 2

Once you know the answer, the pieces fit neatly. Getting there is another matter. The bird’s reaction tells you something is wrong, but you still have to discover what is upsetting it. That can make for a satisfying experiment, provided you notice enough in the reply to think of putting the rod down.

Worked puzzle: the crystal bridge — a reversible change

The fissure stops your westward journey. Wave the rod and a bridge appears. Now you can cross. Wave it again and the bridge disappears. 2

Once again, the rod has earned its place in your inventory. This time it acts as a toggle, switching between two states. It stays with you, and you have learnt something about where it works: waving it elsewhere need not have the same effect.

You can try the change and reverse it, which makes this a welcoming sort of experiment. The game still needs to make the result clear. Before stepping out over a fissure, you would quite like to know whether the bridge is there.

Worked puzzle: the gold — finding treasure is not getting it home

Gold! Now to take it home. Except the upward route from the Hall of Mists to the small pit no longer works while you are carrying it. Put it down and you can use that route again. A nearby warning gives you a chance to anticipate the problem. 2

You have reached the prize and picked it up. You still haven’t solved the puzzle. The gold changes which way you can travel, so you need a return plan as well as a route in.

Designers can separate access, reaching something, from extraction, getting it out. That leaves room for a second discovery after the apparent success of finding a treasure. Many later games give us comparable problems, although that resemblance alone cannot tell us whether they borrowed from this one.

The rod that frightens a bird can help you cross a fissure. The gold you wanted can close off your way home. Once these relationships begin to matter, a list of objects and a map of rooms are only the start of understanding the cave.

Time stands still — until it does not

You can stop typing and think. Put the kettle on, argue about the map, or spend a while looking at the words already on screen. The cave waits for your next request. That gives an expedition a different rhythm from steering a ship in real time.

Once you press Return, though, time can start moving. An attempt can use a turn even when it achieves nothing. An unrecognised word can cost lamp life; so can checking your inventory. 23

That is an awkward discovery to make when your lamp has limited life. You were trying to understand a word, and the light was running down anyway. Planning an efficient trip is one challenge; worrying that every unsuccessful question uses up your chance to explore is another.

We could make a different choice in a game of our own. Looking around might be free. A clarification could finish before the world takes its next turn. Or we could keep a timer for a moment when pressure adds excitement. Each choice changes what the player feels safe trying.

Light, carrying and the shape of an expedition

Leaving the lamp behind is a decision you may regret underground. Some places have light of their own; others need a working lamp nearby before you can see what is there or travel safely. Owning it is not enough. Where is it, is it on, and has it any power left?

The lamp will not last forever. Help and hints can affect its allowance, so learning the cave and learning how to manage the light become part of the same expedition. 2

So the life of your lamp is tied to more than distance travelled. Asking for help, choosing what to carry and finding a quicker route can all affect how you plan the next expedition.

There is another limit to deal with: you cannot carry everything. The cave’s counting rules take a little getting used to, including special handling for the bird and cage. Guessing by an object’s apparent size won’t necessarily tell you how much room it uses in your inventory.

Getting ready for another trip can become a pleasure of its own. You know where you want to go this time. Which tools will you need? What can you afford to leave behind? A good shortcut suddenly becomes much more valuable.

Ferrying the same objects through familiar passages is less exciting. So is losing another expedition because the lamp ran out while you were trying to work something out. These limits deserve credit when they give us interesting decisions. Their age, or the smallness of the computer running them, doesn’t make every inconvenience enjoyable.

Dwarves, a pirate and a world that interferes

Adventure is not a collection of puzzles politely waiting for us to arrive. Its lower cave contains moving hazards. Dwarves can block or threaten travel, and a pirate can interfere with treasure carrying. The source gives them rules about where they can go and when they act. 23

So much for the tidy route you had planned. Knowing the passages does not make the journey safe, and carrying treasure gives you something to worry about losing. An encounter can turn a routine trip into an urgent problem.

Chance adds another reason for a return journey to feel different from the trip out. Knowing the map cannot tell you everything that will happen on it.

This makes working things out harder in an interesting way. Did that attempt fail because you missed a condition, or because luck went against you? Repeating a test can expose a dependable rule. If chance is involved, the same experiment may give you different answers. The player has to decide how much to trust what just happened.

Losing, returning and keeping what you learnt

Death need not end an expedition permanently. The 350-point game offers reincarnation under particular conditions, with a score cost and consequences for carried objects.

A fatal trip in the dark can end with you back above ground, alive again but without your former inventory. The lamp can be recovered at the road; other objects need finding again. You cannot keep taking this way out indefinitely, and once the cave is closing, the offer is gone. 23

You are back, but your expedition needs repairing. Reincarnation carries the game forward with a penalty and a changed situation. It is quite different from being allowed to take back the fatal decision. Other ways of recovering offer different sorts of second chance:

Recovery method	What it normally restores
Reincarnation in this Adventure	A continued game after death, with particular penalties and relocated objects.
Loading a saved game	A previously recorded state, according to that version’s save rules.
Undo in an engine that supplies it	An earlier action boundary, if the engine and game allow it. Not a feature established in this Adventure build.
Restarting	The initial game state, while the player retains knowledge.

Saving offers a different comfort: a way back to the expedition before things went wrong. Microsoft Adventure’s 1981 IBM manual gives saving and returning their own instructions. 4

The IBM manual also reminds us what saving meant at the desk. Remove the diskette’s write-protect tab, then choose one of two numbered saved cave images. Save over an occupied slot and the old expedition is gone. A way back depends on a writable disk and on choosing the slot carefully, especially if someone else uses it too. 4

Worse than a sudden death can be discovering much later that you lost your chance ages ago. An unwinnable state lets play continue after some earlier decision has made the ending, or the maximum score, impossible. You may spend an evening searching for a solution that no longer exists. Warnings and recoverable mistakes matter because they protect the time and thought a player is putting into the game.

What does 350 measure?

Three hundred and fifty points sounds like a target we can understand. Getting them involves more than finding a pile of treasure. The game rewards discoveries, gives more for bringing treasures back in suitable condition, and counts survival, later phases and the ending too. Hints can cost points. There is even a small reward in the scoring code for leaving a magazine in a particular place. 23

A treasure seen, a treasure carried and a treasure safely deposited are therefore different states. The design rewards bringing things home, not just touching every interesting object.

Of course, 350 needn’t be your only reason to play. Getting past one baffling obstacle can be enough of a triumph for an evening. A hint may cost points and still buy you a much better time in the cave. Reaching more of the game and reaching its highest score are different ambitions.

The final rating also turns a number into a judgement about the adventurer. It can encourage another attempt, although a novice confronted with a dismissive label may feel rather less welcomed. Tone is part of feedback too.

The cave has an ending

Eventually, the long series of expeditions begins to give way to something else. Woods’s game has a closing phase, with changes to the cave and a final problem beyond the treasure hunt.

The game keeps track of treasures still to be discovered. When that count reaches zero in qualifying cave locations, a clock begins moving towards the closing warning. Later, the game changes access, removes some hazards and eventually transports the player into a compact final situation using familiar objects in a different arrangement. 23

The cave you have spent so long learning starts to change around you. Familiar routes and routines stop being dependable, and familiar objects have to be considered afresh. A wide-ranging expedition narrows into a final problem.

The discoveries that trigger closing and the time left before it happens give these last stages their own urgency. We will leave the winning sequence for you to discover.

A real cave, two authors and several kinds of imagination

The cave was not invented entirely at a keyboard. Will Crowther was an experienced caver and cave surveyor as well as a programmer at Bolt Beranek and Newman. Parts of the game correspond closely to the Bedquilt region of Colossal Cave in Kentucky’s Mammoth Cave system. 1

That makes the act of mapping especially pleasing. Crowther had helped survey real passages and record how they joined up. Now a player at a keyboard was trying to work out some of those relationships from the other direction. The particular turns, slopes and landmarks came from somewhere.

The survey work was shared. Patricia Crowther, later Patricia Wilcox, was an important collaborator in exploring and recording the cave. That contribution belongs in the story of how this place reached a computer, alongside the programming credited to Will Crowther. 1

Crowther also played Dungeons & Dragons, and his original cave had room for magic, creatures and puzzles alongside its recognisable geography. His later accounts and family recollections describe a game his children could enjoy. The same program could draw on the caves he knew and offer his children an imaginary expedition.

Then Don Woods encountered the program at Stanford and obtained the source from Crowther. His 1977 expansion gave players more territory, scoring, inventory and further encounters. The cave became a longer, more involved expedition, with much of Crowther’s earlier work still there to explore. 1

The two versions give us a chance to see a game growing between people. Crowther supplied a place and a way to explore it. Woods saw room for a longer expedition and more things to discover. Looking at what each added tells us more than trying to award the whole cave to one of them.

Photograph source and credit · CC BY 2.0.

The writing makes the machine feel larger

After a while, you get to know the voice at the other end of the conversation. Sometimes it helps. Sometimes it teases. Sometimes it is rather sharp about your latest attempt. A description can carry a clue while making you smile, or make you suspicious that there is more to this place than it is telling you.

The contrast between the practical and the impossible is especially effective. A narrow passage or a limited lamp invites physical reasoning. A magical effect tells us that physical reasoning alone will not be enough. The cave can feel like a place while refusing to be a literal simulation.

The singing bird is a good example. There is no recording to play: the words let you imagine the sound. The same happens with colour, depth and movement. A short description can occupy far more space in your head than it takes up on screen. Much of the pleasure comes from filling in what the words suggest.

The form also has limits. English vocabulary and idiom can be barriers. An unfamiliar cultural reference may make a clue harder for reasons unrelated to reasoning skill. Text can suit a screen reader, but that does not prove a particular terminal or browser implementation is accessible. Repeated output, prompt focus and the way updates are announced still need testing.

The story you take away may be the expedition you made: the foolish mistake, the idea that finally worked, the return with something you thought you had lost. Later authors could use related machinery for richer characters and more directed plots. They would still have to write them. A parser can recognise a request; it cannot make a dull scene worth caring about.

From a shared computer to a product on a shelf

Adventure travelled through research computing communities and source exchange. That environment affected who could encounter it, how it could be altered and what “distribution” meant. A useful program could spread between people with institutional access without ever passing through a shop.

To join in, though, you needed a way to reach those computers and communities. A spare evening did not buy you a machine account. Access to an institution and its people could decide whether you ever saw the cave.

When Adventure reached MIT, it gave another group an itch to make a game of their own. Tim Anderson’s later history of Zork recalls that arrival and the ambition to do more. It is a creator’s recollection, complete with jokes and judgements; here we can follow an influence someone actually described. 10

Bringing the cave home changed the problem. Now someone had to find a copy they could buy, get it running on their machine and work out what to do when they became hopelessly stuck. The manual, packaging and ways of getting help became part of the invitation underground.

Microsoft Adventure reached the IBM PC in 1981, with Gordon Letwin credited for the implementation. The disk supplied its own operating system, so the computer could start straight into the adventure. The manual helped you get ready for exploratory trips, bring treasure back and attempt the Grand Master game. It also explained how to save an expedition you wanted to return to. 4

Before the first prompt, there was a disk to load and a manual to consult. The cave might be imagined, but getting into it depended on a very particular machine on your desk.

Level 9: fit more cave into less space

Level 9’s Colossal Adventure offers another response. The BBC manual examined here describes a mainframe adaptation with an enlarged endgame, compact adventure instructions and compressed text. It offers help by post, with a specific question more likely to receive a useful answer. 5

The enlarged endgame gives you something new to look forward to even if you know the earlier cave. Compressed text helps fit the adventure into a smaller machine. And if the puzzles defeat you, help by post is a slower conversation to fall back on.

Playing Adventure on another machine could bring something new to discover, even for someone who thought they knew every passage.

What a contemporary reviewer valued

In December 1980, BYTE reviewer Bob Liddil considered Microsoft Adventure worth $29.95 on a 32K TRS-80 with a disk drive. He praised the descriptions, shorthand commands, documentation and packaging. He also explained how fetching text from disk made room for fuller prose. The pleasure of imagining the cave was part of what you were buying. 16

He also notices that its presentation differs from other microcomputer adventures, including the split-screen format familiar from Scott Adams’s games. That difference does not prevent him recommending it. Ease of interaction and the imagined world are central to his judgement.

There is another concern on the page: an editorial note asks that Crowther and Woods receive credit alongside the commercial implementation. Even while praising a product you could take home, the magazine was asking readers to remember the people behind the cave. This is one review, but it gives us a welcome glimpse of what someone valued at the time.

From playing an adventure to authoring one

Finish a game you love and there is a tempting next question: could I make something like this?

Scott Adams asked his own version of it. In his December 1980 BYTE article, he recalls completing the 350-point Adventure and wondering what a small home computer could offer. He wanted to make a game of his own, with a different adventure to go on.

His answer separated an interpreter from adventure data. The interpreter supplied machinery that could be reused across games; the data supplied a particular world. Adams describes Pirate’s Adventure as a 16K TRS-80 BASIC product delivered with an interpreter and data file, and credits Alexis Adams’s ideas for its scenario. Those are distinct creative and technical contributions. 15

Once the interpreter works, another adventure can use it. New places, words and puzzles can go into new data. Adams’s account gives us a direct route from enjoying Adventure to building different games, and a practical way to avoid starting every one from scratch.

An authoring system takes that opportunity further. It can give a writer tables for vocabulary, descriptions, objects, connections, conditions and actions. You can get on with inventing a world while the system handles familiar operations. It cannot decide whether your clue is helpful or your puzzle is enjoyable; those jobs are still yours.

The Quill put this possibility within reach of home-computer owners, beginning on the Spectrum. Graeme Yeandle’s system let you build an adventure by editing tables. Its Oric/Atmos manual, crediting Tim Gilberts for that conversion, walks through vocabulary, places, objects and rules: the pieces of an adventure you could make your own. 11

The manual puts a responsibility back in the author’s hands: you choose which words the game knows. If your description makes people want to examine something, you need to consider what happens when they try. The tool cannot rescue a room full of tempting things whose names the game refuses to recognise.

The Spectrum’s text adventures need not be treated as pale copies of one cave game. Different subjects, voices, puzzles, audiences and production circumstances can make the shared form do different things. CRASH’s April 1985 adventure chart places Colossal Adventure, Snowball, The Hobbit and several other kinds of adventure together. It shows a varied conversation among readers, not a complete market survey or proof of a common direct ancestry. 12

There is plenty to explore from here: the language and characters of The Hobbit, the tools in Professional Adventure Writer, or the world of Zork. Pictures can give us more to look at, and different controls can change how we find things to try. There is still a particular pleasure in proposing an idea in your own words and discovering that the game has an answer.

From typing to jumping

The puzzles could travel beyond the text prompt, too. In Dizzy, finding an object is often the beginning of another question: where might this be useful? You carry things between places, try to work out what is blocking your progress, and return when you think you have an answer. This time you can see your character, and you have jumps to judge as well as puzzles to solve.

The Oliver Twins describe wanting the objects in Dizzy to mean more. They turned towards the text adventures they had enjoyed, including Zork, when shaping its puzzles. That thinking fits comfortably into a cartoon world: the player still has to notice, remember and experiment, even when the way forward involves a somersault. 17

Testing the conversation, not just the solution

You know the solution. You type the commands in the right order, reach the end and declare the game finished. Then someone else sits down and asks to do something you never thought of.

Even a toy world with three movable objects and five possible places for each object has 125 combinations before we add locks or timers. Some may be unreachable or irrelevant, but the number shows how quickly interactions grow.

Players will use different words, carry things in an inconvenient order and return to places you thought they were finished with. They will have ideas you didn’t. Following your own winning route won’t tell you what happens on theirs.

For our small grate example, a useful investigation includes more than successfully unlocking it. Try without keys, with keys carried, with keys dropped nearby, when already unlocked, and after a relevant world-state change. Check that both the rule and the description agree.

Parser testing needs equivalent intentions expressed differently, incomplete requests, extra words, synonyms, unavailable objects and ambiguous references where the engine supports them. World testing needs transitions: take and drop, light and extinguish, open and close, move away and return.

Recovery needs its own attention. What persists after death? What does a save record? Can an object become duplicated, disappear or remain described where it no longer exists? Can a puzzle appear solved while the necessary state change has not happened?

Dave Lebling’s 1984 account of Infocom testing includes crashes, implausible character responses and inconsistent prose. Some failures break the program; others leave it running while the fiction falls apart. Both can spoil the adventure. Checking what the world says and does belongs alongside checking that the code runs. 13

The Vault’s Adventure reference entry and text-adventure overview provide shorter historical and genre routes alongside this longer investigation.

What we would borrow, and what we would question

Think back to the lamp in the building. You took it, and the game remembered. From that small beginning came a cave you could learn, change and make plans about. A few objects acquired unexpected uses. Words became ways of testing ideas.

Those are things worth trying in our own games. So are the questions the rough edges leave us with. When a player gets stuck, have we given them something useful to think about? When they make a mistake, can they learn from it? How much familiar ground must they cover before they get another chance at the interesting part?

Graham Nelson returned to questions like these in The Craft of Adventure: give warnings, accept reasonable vocabulary, let people recover from mistakes and spare them needless tedium. He was writing in 1995, looking back with years of adventure-making experience available to him. His arguments give us another way to think about how it feels to be the person at the keyboard. 14

We could start very small: a room that remembers where we left an object, or a parser that asks one useful follow-up question. Try a puzzle with two different replies to the same failed attempt and see which gives someone a better idea. These would be our own small experiments for future Craft work, with original words and places.

Adventure makes that prospect inviting. Someone described a place, gave it rules and let us loose in it. We drew maps, tried unlikely ideas and started caring whether we could get home with the gold. There is a whole cave on the other side of that prompt. What will you try next?

Sources and further reading

1. Dennis G. Jerz, “Somewhere Nearby is Colossal Cave: Examining Will Crowther’s Original ‘Adventure’ in Code and in Kentucky”, Digital Humanities Quarterly 1.2 (2007). Source comparison, chronology, interviews, cave records and field investigation. Distinguish retrospective testimony from dated artefacts.

2. Arthur O’Dwyer, ODWY0350, with the repository’s port history. Our selected encounter records and implementation limits accompany the canonical study.

3. Crowther and Woods, 350-point FORTRAN source and data. The archive’s preservation notes identify the recovered source chain; it is not an original-hardware execution record.

4. IBM, Microsoft Adventure: Program Instructions, first edition, June 1981: title credit; pp. 6–7, 22–23. Scanned spreads contain two printed pages apiece.

5. Level 9 Computing, Colossal Adventure BBC manual: “The Game”, “How to Load and Start”, “Hints” and “Implementation”. Platform identified from loading instructions; exact issue date remains uncertain.

6. Graham Nelson, Inform Designer’s Manual, fourth edition (2001), §26, describing objects and rooms. A later system used for comparison, not Adventure documentation.

7. Nelson, §32, scope and what you can see.

8. Nelson, §30, how verbs are parsed, §31, tokens of grammar, and §33, helping the parser out of trouble.

9. P. David Lebling, Marc S. Blank and Timothy A. Anderson, “Zork: A Computerized Fantasy Simulation Game”, IEEE Computer 12.4 (April 1979), pp. 51–59. Archived transcription and publication details.

10. Tim Anderson and Stu Galley, “The History of Zork”, The New Zork Times, Winter–Summer 1985. Creator recollections; jokes and judgements are not quantitative industry evidence.

11. Graeme Yeandle / Gilsoft, The Quill, Oric-1/Atmos Serial A manual, 1985; Oric version credited to Tim Gilberts. Introduction, vocabulary, movement, event/status and condition/action sections. Not the original Spectrum manual.

12. CRASH 15, “Hotline”, Adventure Top 30, April 1985. A mixed reader chart; keep it distinct from the main software Top 30.

13. Dave Lebling, “They’re Never Satisfied”, The New Zork Times, Fall 1984, p. 2.

14. Graham Nelson, The Craft of Adventure, second edition (1995), especially “Bill of Player’s Rights”. Historical design criticism, not current legal guidance.

15. Scott Adams, “Pirate’s Adventure”, BYTE 5.12 (December 1980), pp. 192–212, especially the introductory and “Program Notes” columns on p. 192. Issue scan. Creator account, interpreter/data design and Alexis Adams’s scenario contribution; the article’s BASIC listings are not redistributed here.

16. Bob Liddil, “Microsoft Adventure”, BYTE 5.12 (December 1980), pp. 264 and 266, including the editorial note signed GW. Issue scan. TRS-80 product review; keep it distinct from the IBM manual’s June 1981 edition.

17. The Oliver Twins, “Dizzy: The Ultimate Cartoon Adventure — Story Behind Dizzy”. Creator recollection describing text-adventure influences and the decision to give collected objects a puzzle-solving purpose.