<!--
	Title: Zork: A Computerized Fantasy Simulation Game
	Authors: P. David Lebling, Marc S. Blank, Timothy A. Anderson
	Source: IEEE Computer, v12(4), Apr 1979
	Game: Zork I
-->

<div style="display: flex; margin-bottom: 1em;">
<img style="height: 5em; margin: auto;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/cover-cartoon-transparent.png" alt="A cartoon drawing of an adventurer">
<div>
<hr>
<p style="font-size: 1.125em; width: 90%; margin: auto; font-style: italic; text-align: center;">
Is magic real? Do swords glow if the enemy is nearby? In the demonic world of
Zork, a simulated universe entices the player into a new form of problem
solving.
</p>
<hr>
</div></div>

<div class="article-sidebar float-left">
Welcome to Zork.<br>
This version created December 8.<br>
West of House<br>
You are in an open field west of a big white house with a boarded front door.<br>
There is a small mailbox here.<br>
&gt;GO NORTH<br>
North of House<br>
You are facing the north side of a white house. There is no door here, and all
the windows are barred.<br>
&gt;EAST<br>
Behind House<br>
You are behind the white house. In one corner of the house there is a small
window which is slightly ajar.<br>
&gt;OPEN THE WINDOW<br>
With great effort, you open the window far enough to allow entry.<br>
&gt;GO IN<br>
Kitchen<br>
You are in the kitchen of the white house. A table seems to have been used
recently for the preparation of food. A passage leads to the west, and a
dark staircase can be seen leading upward. To the east is a small window,
which is open.<br>
On the table is an elongated brown sack, smelling of hot peppers.<br>
A bottle is sitting on the table.<br>
The glass bottle contains:<br>
&nbsp;&nbsp;A quantity of water<br>
</div>

Beyond this nondescript kitchen, above and below the surface of the earth, lie
scores of rooms, some containing traps, some containing puzzles. Hundreds of
objects are scattered throughout this maze, some valuable treasures, some
magical tools. The little white house in the forest clearing is the entrance
to Zork, a game developed by the authors. Zork is one example of a new type of
game: the Computerized Fantasy Simulation game.

In this type of game, the player interacts conversationally with an omniscient
"Master of the Dungeon," who rules on each proposed action and relates the
consequences. If the player says "Go north," he may move north, or the dungeon
master may say "There is no way to go in that direction." If the player says
"Open the window," the dungeon master may respond "The window is locked." The
results depend on the design of the game, its architecture and furnishings, so
to speak: in one game picking a sword might be fatal, in another it might
confer magical powers. The design and implementation of such games is as much
an exercise in creative writing as in programming.

The interest in playing Zork (or any other CFS game) is two-fold. First, the
object of the game is usually to collect treasure, and this may be done only
by solving problems; in the above example, the player would garner 10 points
by being clever enough to open the window and enter the house. (Zork itself
has more than two dozen distinct problems to solve, some presented in several
stages.) Second, 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?" They players (and designers) delight in clever (or
unexpected) responses to otherwise useless actions.

<div class="clearsidebar"></div>

## Overview: simulating the universe

The heart of any CFS game is its ability to mimic omniscience. By this we mean
that the game should simulate the real world sufficiently well so that the
player is able to spend most of his time solving the problems rather than
solving the program. If, for example, the vocabulary is too small, the player
must always wonder if his problem is only that he hasn't yet found the right
word to use. Similarly, it is annoying for a possible solution to a problem to
be ignored by the game. In other words, the program must simulate the real world.

Obviously, no small computer program can encompass the entire universe. What
it can do, however, is simulate enough of the universe to appear to be more
intelligent than it really is. This is a successful strategy only because CFS
games are goal-directed. As a consequence, most players try to do only a
small subset of the things they might choose to do with an object if they
really had one in their possession.

Zork "simulates the universe" in an environment containing 191 different
"rooms" (places to be) and 211 "objects." The vocabulary includes 908 words,
of which 71 are distinct "actions" it handles. By contrast, a person's
conversational vocabulary is a factor of two (or more) larger. How then does a
limited program make a creditable showing in the conversational interaction
that characterizes Zork?

The technique Zork uses for simulating the universe is that of universal
methods modified for particular situations. For example, when a player tries
to take some object, he expects to end up carrying it. There are, as in the
real world, exceptions: some objects are "nailed down," and one's carrying
capacity is limited. These restrictions are included in the general ``TAKE``
function. However, the designer might want a special action in addition to, or
instead of, the general ``TAKE``: a knife might give off a blinding light when
taken; an attempt to take anything in a temple might be fatal. These
exceptions would not appear in the general ``TAKE`` function, but in functions
associated with the knife and the temple.

The details of this method of exceptions will be taken up later. The effect of
it is that "the expected thing" usually happens when the player tries to (for
example) take something. If the object he is trying to take is not special,
and the situation is not special, then "it works," and he gets the object. In
Zork, there are quite a few of these basic verbs. They include "take," "drop,"
"throw," "attack," "burn," "break," and others. These basic verbs are set up
to do reasonable things to every object the player will encounter in the game.
In many cases, objects have properties indicating that a certain verb is
meaningful when applied to them (weapons have a "weapon" property, for
example, that is checked by the verb "attack"). Applying a verb to an object
lacking the necessary property often results in a sarcastic retort ("Attacking
a troll with a newspaper is foolhardy."), but the point is that it does
something meaningful, something the player might have expected.

Another way in which the game tries to be real is by the judicious use of
assumptions in the dungeon master's command parser. Suppose the player says
"Attack." Assuming that he has a weapon and there is an enemy to attack, this
should work, and it does. Assumptions are implemented by the existence of verb
frames (stereotypes) and memory in the parser. In the example, the parser
picks up the verb frames for the verb "attack." They indicate that "Attack
'villain' with 'weapon'" is the expected form of the phrase. Now, "villain"
means another denizen of the dungeon, so the parser looks for one that is
presently accessible, a "villain" in the same room as the player. Similarly,
the player must have a "weapon" in his possession. Assuming only one "villain"
is in the room and the player has only one "weapon," they are placed in the
empty slots of the frame and the fight is on.

Suppose that there is only one villain available, the troll, but the player
has two weapons: a knife and sword. In that case, the dungeon master can't
decide for him which to use, so it gives up, saying "Attack troll with what?"
However, it remembers the last input, as augmented by the defaults ("Attack
troll"). Thus, if the user replies "With sword," or even "Sword," it is merged
with the leftover input and again the fight is on. This memory can last for
several turns: for example, "Attack"; "Attack troll with what?"; "With knife";
"Which knife?"; "Rusty knife"; and so on.

## Data structure and control structure

The underlying structure of Zork consists of the data base (known as "the
dungeon") and the control structure. The data base is a richly interconnected
pointer structure joining instances of four major data types: "rooms,"
locations in the dungeon; "objects," things that may be referenced; "actions,"
verbs and their frame structures; and "actors," agents of action. Each
instance of these data types may contain a function which is the specializing
element of that instance. The control structure of Zork is, at one level, a
specification of which of these functions is allowed to process an input
sentence and in what order.

In the simplest sense, Zork runs in a loop in which three different operations
are performed: command input and parsing, command execution, and background
processing. (Figure 1 is a flowchart of the Zork program.)

The command input phase of the loop is relatively straightforward. It is
intended to let the user type in his command, edit it if he needs to, and
terminate it with a carriage return.

The purpose of the Zork parser is to reduce the user's input specification
(command) to a small structure containing an "action" and up to two "objects"
where necessary.

<figure class="float-right">
	<img class="thumbnail" onclick="embiggen('img', this)" data-thumbnail-for="/public/img/articles/zork-a-computerized-fantasy-simulation-game/figure1.png" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/figure1.png" title="Figure 1. Zork flowchart" alt="Figure 1. Zork flowchart">
	<figcaption>Figure 1. Zork flowchart.</figcaption>
</figure>

The parser begins by verifying that all the words in the input sentence are in
its vocabulary. Then, it must determine which action and objects, if any, were
specified. For an object to be referenced in a sentence, it must be
"available" -- that is, it must be in the player's possession, in the room the
player is in, or within an object that is itself available. Objects not
meeting these criteria may still be referenced if they are "global objects,"
which are of two types: those that are always available (such as parts of the
player's body), and those that are available in a restricted set of rooms
(such as a forest or a house). Adjectives supplied with the sentence are used
to disambiguate objects of the same generic type (such as knives and buttons)
but are otherwise ignored. If an object remains ambiguous, the parser asks
which of the ambiguous objects was meant (for example, "Which button should
I push?").

Next is syntax checking, whereby the correct "action" is used for any verb.
Syntax checking makes use of any supplied prepositions, differentiating
between, for example, "look at" and "look under," which imply different
actions. Finally, having determined the appropriate syntax for a given
sentence, the parser ensures that all required objects for a given action were
specified. The parser may, for example, decide that the correct syntax for the
sentence "Give X" is "Give X to Y." An attempt is then made to supply an
appropriate "Y" to complete the sentence. This is made possible by the
definitions of the actions themselves, which include the attributes of the
objects to be acted upon. In the present example, the action for "Give"
defines the indirect object ("Y") to be another denizen of the dungeon; the
parser attempts to comply by seeing if one is available. If so, the indirect
object is found, and the parse is successful. If not, the player is asked to
supply the indirect object himself. ("Give X to whom?") Once this phase is
completed, the parse is finished and the parser's output is returned.

The adjectives and prepositions that were in the user's input are used only to
determine the "action" and the "objects," and are not part of the parser's
output. In addition, all articles are ignored, though users may add them to
increase the clarity (to themselves) of what they input. For example, an input
of "Knock down the thief with the rusty knife" reduces to something like

<p style="text-align: center;">
[&lt;action STRIKE&gt; &lt;object THIEF&gt; &lt;object RUSTY-KNIFE&gt;]
</p>

If, however, the input were "Knock on the thief," the parser would reduce that to

<p style="text-align: center;">
[&lt;action RAP&gt; &lt;object THIEF&gt;]

recognizing that the "action" to be performed depends, for the word "knock,"
on the syntax of the input sentence: "knock down" turns into "strike," while
"knock on" turns into "rap."

<div class="article-sidebar">
<pre>
;"An object: A stack of Zorkmid bills (Zorkmids are the currency of Zork)"<br>
&lt;OBJECT ["BILLS" "STACK" "PILE"]
                ;"The object's name and synonyms."
        ["NEAT"" "200" "ZORKM"]
                ;"Adjectives which refer to the object."
        "stack of zorkmid bills"
        &lt + ,OVISION, READBIT, TAKEBIT, BURNBIT&gt;
                ;"Properties of the object: it's visible, readable, takeable, flammable"
        BILLS-OBJECT
        ( )     ;"The contents of the object (always empty for this object)."
        [ODESC1
        "200 neatly stacked zorkmid bills are here."
                ;"The long description."
        ODESCO
        "On the floor sit 200 neatly stacked zorkmid bills."
                    ;"The initial long description (when first seen by the player)."
        OSIZE 10    ;"The object's weight."
        OTVAL 15    ;"The value of the object: points for finding it and saving it."
        OFVAL 10
        OREAD ,ZORKMID-FACE
                    ;"What to print when the object is read."]
                    ;"The elements of an object with tokens naming them are rare (few objects are readble
                      and thus need OREAD slots). The other slots are common to all objects."&gt;<br>
;"The object function for the Zorkmid bills. It is there mostly to make a few sarcastic comments."<br>
&lt;DEFINE BILLS-OBJECT ( )
        &lt;SETG BANK-SOLVE!-FLAG T&gt;
        &lt;COND (&lt;VERB? "BURN"&gt;
                &lt;TELL "Nothing like having money to burn!"&gt;
                &lt;&gt;);"Prints sarcasm but doesn't handle the command (accomplished by returning the false
                     object &lt;&gt;). This allows BURN to also deal with it."
                (&lt;VERB? "EAT"&gt;
                &lt;TELL "Talk about eating rich foods!"&gt;
                    ;"Doesn't allow EAT to run (by returning a non-false.")&gt;&gt;<br>
;"A room: the vault in which the Zorkmid bills are found"<br>
&lt;ROOM: "BKVAU"      ;"The internal name of the room."
        "This is the Vault of the Bank of Zork, in which there are no doors."
        "Vault"
        ,NULEXIT ;"There are no exits from this room."
        (&lt;GET-OBJ "BILLS"&gt;)
                ;"The bills are initially here."
        &lt;&gt;
        &lt; + ,RSACREDBIT ,RLANDBIT&gt;
                ;"The room may not be entered by the thief, and is a land room."
        [RGLOBAL &lt + ,WALL-ESWBIT ,WALL-NBIT&gt;]&gt;
                ;"The walls of the room are/may be referenced."
</pre>
</div>

Once parsing has been completed, processing of the command is started. The
functional element (if any) of each of the objects in the parsed input may be
invoked. Additionally, some objects not specifically referenced, but which
define the situation, are part of the processing sequence. The order in which
these functions are invoked is determined by a strategy of allowing the
exceptions an opportunity to handle the input before performing the action
associated with the most general case. The processing order is as follows:

1. The actor performing the command, if any. This allows, for example, a robot
   with a limited range of actions.

2. The vehicle the actor is in, if any. This allows the vehicle to restrict
   movement. For example, inside a freely drifting balloon the normal movement
   commands (such as "Run north") might be meaningless or even fatal.

3. The verb, or "action."

   (a) The indirect object of the sentence, of any.

   (b) The direct object of the sentence, if any.

4. The vehicle again, if any. The vehicle is called a second time to enable it
   to act based on changes in the state resulting from the action.

5. The room the player is in.

Each of these functions is invoked in turn and given the option of handling
the command. If it decides to handle the command, processing terminates at
that point, and the remaining functions are not invoked. Otherwise, the
sequence continues. Note that a function may do something (such as print a
message) without completely handling the input. The invocation of an object's
function is under the control of the verb; it may, after suitable checks,
determine that the player's request is not reasonable. ("Your load is too
heavy. You will have to leave something behind.") This limits flexibility
slightly, but it has the advantage that it localizes the tests for a
reasonable state.

Presumably, one of the functions will handle the command and print an
appropriate response. Should that not happen, the response "Nothing happens"
is printed by default. However, care has been taken to ensure that most input
commands produce some reasonable response. Indeed, much of the enjoyment of
the game is in being allowed to try ridiculous things, and the surprise of
having the game understand them.

The functions described so far are invoked in direct response to what the user
typed. Background processes, or "demons," are invoked after each input,
regardless of its nature. They allow the program to do things independently of
the player's actions.

<div class="article-sidebar">
<img style="height: 3em; display: block; margin: auto;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/examples0-transparent.png" alt="Examples from Zork">

**A demonstration of vehicles, specifically the magic boat (various ridiculous
things are attempted).**

&gt;LOOK<br>
Dam Base<br>
You are at the base of Flood Control Dam #3, which looms above you and to the
north. The River Frigid is flowing by here. Across the river are the White
Cliffs, which seem to form a giant wall stretching from north to south along
the east shore of the river as it winds its way downstream.<br>
There is an inflated boat here.<br>
The magic boat contains:<br>
&nbsp;&nbsp;A tan label<br>
&gt;BOARD THE MAGIC BOAT<br>
You are now in the magic boat.<br>
&gt;NORTH<br>
You can't go there in a magic boat.<br>
&nbsp;&nbsp;&nbsp;&nbsp;;The room to the north is defined not to allow boats.<br>
&gt;READ<br>
Read what?<br>
&gt;LABEL<br>
Taken.<br>
&nbsp;&nbsp;!!!! FROBOZZ MAGIC BOAT COMPANY !!!!

Hello, Sailor!

Instructions for use:

&nbsp;&nbsp;To get into boat, say 'Board'<br>
&nbsp;&nbsp;To leave boat, say 'Disembark'

&nbsp;&nbsp;To get into a body of water, say 'Launch'<br>
&nbsp;&nbsp;To get to shore, say 'Land'

&gt;LAUNCH<br>
Frigid River<br>
You are on the River Frigid in the vicinity of the Dam. The river flows
quietly here. There is a landing on the west shore. You are in the magic boat.<br>
&gt;DOWN
Frigid River<br>
The River turns a corner here making it impossible to see the Dam. The White
Cliffs loom on the east bank and large rocks prevent landing on the west.<br>
You are in the magic boat.<br>
&gt;UP<br>
You cannot go upstream due to strong currents.<br>
&gt;PUT BOAT IN BOAT<br>
How can you do that?<br>
&gt;DISEMBARK<br>
You realize, just in time, that disembarking here would probably be fatal.<br>
&gt;DOWN<br>
Frigid River<br>
The river is running faster here and the sound ahead appears to be that of
rushing water. On the west shore is a sandy beach. A small area of beach can
also be seen below the Cliffs.<br>
You are in the magic boat.<br>
There is a red buoy here (probably a warning).<br>
[in the roomj<br>
&gt;EAT BUOY<br>
Taken.<br>
I don't think that the red buoy would agree with you.<br>
&nbsp;&nbsp;&nbsp;&nbsp;The verb function has done all the processing.

**Playing with fire, attempting to burn the painting (in the end, the careless
adventurer gets his just deserts):**

<img class="float-right" style="width: 33%;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/examples1-transparent.png" alt="Cartoon illustrating scenes from Zork">
&gt;INVENTORY<br>
You are carrying:<br>
A pair of candles<br>
A matchbook<br>
A torch<br>
A painting<br>
A lamp<br>
&gt;LIGHT CANDLES WITH TORCH<br>
You realize, just in time, that the candles are already lighted.<br>
&gt;EXTINGUISH CANDLES<br>
The flame is extinguished.<br>
&gt;LIGHT CANDLES WITH TORCH<br>
The heat from the torch is so intense that the candles are vaporized.<br>
&nbsp;&nbsp;&nbsp;&nbsp;;The 'candles' function has handled being lit with the
torch.<br>
&gt;LIGHT MATCH<br>
One of the matches starts to burn.<br>
&gt;BURN PAINTING WITH MATCH<br>
The painting catches fire. Unfortunately, you were holding it at the time.<br>

**Demonstration of the parser, and a number of its features, Including the
remembering of previous inputs and the use of ALL and ALL EXCEPT:**

&gt;WEST<br>
Living Room<br>
You are in the living room. There is a door to the east, a wooden door with
strange gothic lettering to the west, which appears to be nailed shut, and a
large oriental rug in the center of the room.<br>
There is a trophy case here.<br>
A battery-powered brass lantern is on the trophy case. On hooks above the
mantelpiece hangs an elvish sword of great antiquity.<br>
&gt;TAKE ALL BUT PAPER AND RUG<br>
sword:<br>
&nbsp;&nbsp;Taken.<br>
lamp:<br>
&nbsp;&nbsp;Taken.<br>
&gt;READ<br>
Read what?<br>
&gt;THE DOOR<br>
The engravings translate to 'This space intentionally left blank'<br>
&gt;LOOK UNDER RUG<br>
Underneath the rug is a closed trap door.<br>
&gt;MOVE THE RUG<br>
With a great effort, the rug is moved to one side of the room.<br>
With the rug moved, the dusty cover of a closed trap-door appears.<br>
<img class="float-left" style="width: 33%;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/examples2-transparent.png" alt="Cartoon illustrating scenes from Zork">
&gt;OPEN<br>
Open what?<br>
&gt;DOOR<br>
Which door should open?<br>
&gt;THE TRAP DOOR<br>
The door reluctantly opens to reveal a rickety staircase descending into
darkness.<br>
&gt;GO DOWN<br>
It is pitch black. You are likely to be eaten by a grue.<br>
Your sword is glowing with a faint blue glow.<br>
&gt;WHAT'S A GRUE?<br>
The grue is a sinister, lurking presence in the dark places of the earth. Its
favorite diet is adventurers, but its insatiable appetite is tempered by its
fear of light. No grue has ever been seen by the light of day, and few have
survived its fearsome jaws to tell the tale.<br>
Your sword is glowing with a faint blue glow.<br>
&gt;TURN ON LAMP<br>
The lamp is now on.<br>
Cellar<br>
You are in a dark and damp cellar with a narrow passageway leading east, and a
crawlway to the south. On the west is the bottom of a steep metal ramp which
is unclimbable.<br>
The trap door crashes shut, and you hear someone barring it.<br>
&nbsp;&nbsp;&nbsp;&nbsp;;The room function closes the trap door to bar escape.

<img class="float-right" style="width: 33%;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/examples3-transparent.png" alt="Cartoon illustrating scenes from Zork">

**The robber, demonstrating his sadistic streak:**

You are in a tiny cave with entrances west and north, and a dark, forbidding
staircase leading down.<br>
There is a suspicious-looking individual, holding a bag, leaning against one
wall. He is armed with a vicious-looking stiletto.<br>
&gt;INVENTORY<br>
You are carrying:<br>
A lamp<br>
A sword<br>
A platinum bar<br>
A jade figurine<br>
The butt of his stiletto cracks you on the skull, and you stagger back.<br>
&nbsp;&nbsp;&nbsp;&nbsp;;The fighting 'demon' just ran.<br>
The other occupant just left, still carrying his large bag. You may not have
noticed that he robbed you blind first.<br>
&nbsp;&nbsp;&nbsp;&nbsp;;The thief 'demon' just ran.<br>
&gt;INVENTORY<br>
You are carrying:<br>
A lamp<br>
&gt;SIGH<br>
You'll have to speak up if you expect me to hear you!<br>

**A not atypical run-in and battle with the troll (unfortunately, this one
results In the death of the adventurer):**

&gt;EAST<br>
The Troll Room<br>
You are in a small room with passages off in all directions.<br>
Bloodstains and deep scratches (perhaps made by an axe) mar the walls.<br>
A nasty-looking troll, brandishing a bloody axe, blocks all passages out of
the room.<br>
Your sword has begun to glow very brightly.<br>
&gt;KILL TROLL WITH SWORD<br>
A mighty blow, but It misses the troll by a mile.<br>
The axe gets you right in the side. Ouch!<br>
&gt;SWING BOTTLE AT TROLL<br>
Trying to attack a troll with a glass bottle is suicidal.<br>
The axe crashes against the rock, throwing sparks!<br>
&gt;JUMP OVER TROLL<br>
The troll is too big to jump over.<br>
You stagger back under a hail of axe strokes.<br>
&gt;TIE UP TROLL<br>
with what?<br>
&gt;ROPE<br>
The troll struggles and you cannot tie him up.<br>
The troll hits you with a glancing blow, and you are momentarily stunned.<br>
&gt;DIAGNOSE<br>
You have a light wound, which will be cured after 29 moves.<br>
You can be killed by one more light wound.<br>
The troll swings his axe, but it misses.<br>
&nbsp;&nbsp;&nbsp;&nbsp;;The troll, no gentleman, keeps fighting while you
examine your wound.<br>
&gt;SCREAM<br>
Aaaar-r-gggggggggggggghhhhhhhhhhhhhh!<br>
The axe crashes against the rock, throwing sparks!<br>
&gt;WAKE UP THE TROLL<br>
The troll isn't sleeping.<br>
The axe sweeps past as you jump aside.<br>
&gt;JUMP<br>
Wheeeeeeeeeel!!!!<br>
The troll's axe stroke cleaves you from the nave to the chops.<br>
It appears that that last blow was too much for you. I'm afraid you are dead.<br>

<img style="width: 90%; display: block; margin: auto;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/examples4-transparent.png" alt="Cartoon illustrating scenes from Zork">

**A demonstration of the Clock Demon, with the Gnome of Zurich appearing a
specifled number of moves following entrapment In the Small Room:**

Small Room<br>
You are in a small, bare room with no distinguishing features. There are no
exits from this room.<br>
&gt;NORTH<br>
There is a wall there.<br>
&gt;EAST<br>
There is a wall there.<br>
&gt;SOUTH<br>
There is a wall there.<br>
&gt;WEST<br>
There is a wall there.<br>
&gt;UP<br>
There is no way up.<br>
&gt;DOWN<br>
There is no way down.<br>
&gt;FOO<br>
Well, FOO, BAR, and BLETCH to you too!<br>
&gt;CLIMB UP WALLS<br>
Climbing the walls is of no avail.<br>
An epicene Gnome of Zurich wearing a three-piece suit and carrying a
safety-deposit box materializes in the room. 'You seem to have forgotten to
deposit your valuables,' he says, tapping the lid of the box impatiently. 'We
don't usually allow customers to use the boxes here, but we can make this ONE
exception, I suppose. . .' He looks askance at you over his wirerimmed
bifocals.<br>
&gt;HELLO GNOME!<br>
The gnome appears increasingly impatient.<br>
&gt;INVENTORY<br>
You are carrying:<br>
A lamp<br>
A clove of garlic<br>
A knife<br>
&gt;GIVE GNOME THE GARLIC<br>
'I wouldn't put THAT in a safety deposit box,' remarks the gnome with disdain,
tossing it over his shoulder, where it disappears with an understated 'pop.'<br>
&gt;STAB GNOME WITH KNIFE<br>
The gnome says 'Well, I never. . .' and disappears with a snap of his fingers,
leaving you alone.<br>
&gt;LOOK<br>
Small Room<br>
You are in a small, bare room with no distinguishing features. There are no
exits from this room.

</div>

Currently, there are four demons. The first is the "fighting" demon. The
residents of the dungeon are frequently hostile; this demon allows them to
assault the player unprovoked, and to keep fighting him even if he ignores
them.

Next is the driving process behind the "thief," described as a "seedy looking
gentleman carrying a large bag." The thief's purpose is to make life difficult
for the player by absconding with treasures or other randomly selected
objects. In many ways he acts like another, rather hostile and powerful,
player in the dungeon.

The third demon is used to warn the player of the presence of hostile forces
by causing his sword (if he has it) to glow if there are enemies nearby. It
looks at the player's vicinity and prints an appropriate message if the "state
of alert" changes; since the thief moves on his own, it is not sufficient to
look for hostiles when the player moves.

Last is the "clock" demon. It is the mechanism by which the concept of future
time is introduced into the game; arbitrary events can be scheduled for
arbitrary future times. For example, the lamp can burn out after being on for
some number of moves, and wounds inflicted in a fight will eventually heal.
Out of consideration for poor typists, the clock does not tick after
unparsable input.

## The history of Zork

The-existence of Zork is a direct consequence of the existence of two
excellent games: Dungeons and Dragons, a fantasy simulation game (not computer
based) invented by Dave Arneson and Gary Gygax, and Adventure, a computerized
fantasy simulation game originally written by Wil Crowther and later
extensively expanded by Don Woods.

Adventure itself was inspired by D&amp;D (as it is familiarly known), in
particular a D&amp;D variation then being played out at Bolt Beranek and Newman,
a Cambridge, Massachusetts, computer firm. It eventually was released to the
public, and it became one of the most popular computer games in recent memory.

One laboratory that acquired a copy of Adventure was MIT's Laboratory for
Computer Science, with which the designers of Zork (the authors and Bruce K.
Daniels) were all then affiliated. In the process of "solving" Adventure,
however, the game's deficiencies and the competitive spirit that often
animates computer researchers kindled the desire of the authors to write a
successor game.

Our natural choice of language was MDL, which is one of the languages in use
at LCS. MDL recommended itself for other reasons, however. It is a descendent
of LISP and is functionally extensible. It also permits user-defined data
types, which is important in a game of "rooms," "objects," "verbs," and
"actors." Finally, MDL makes it easy to imbed implicit functional invocations
in data structures to tailor the game as described above. The initial version
of the game was designed and implemented in about two weeks.

The first version of Zork appeared in June 1977. Interestingly enough, it was
never "announced" or "installed" for use, and the name was chosen because it
was a widely used nonsense word, like "foobar."

The original version of the game was much smaller, both geographically and in
its capabilities. Various new sections have prompted corresponding expansions
in the amount of the universe simulated. For example, the need to navigate a
newly added river prompted the invention of vehicles (specifically, a boat).
Similarly, the addition of a robot prompted the invention of other actors than
the player himself: beings that could affect their surroundings, and so on.
Fighting was added to provide a little more randomness in a fairly
deterministic game.

## The future of computer fantasy simulation games

Zork itself has nearly reached the practical limit of size imposed by MDL and
the PDP-10's address space. Thus the game is unlikely to expand (much?),
further. However, the substrate of the game (the data types, parser, and basic
verbs) is sufficiently independent that it would not be too difficult to use
it as the basis for a CFS language.

There are several ways in which future computerized fantasy simulation games
could evolve. The most obvious is just to write new puzzles in the same
substrate as the old games. Some of the additions to Zork were exactly this,
in that they required little or no expansion of the simulation universe. A
sufficiently imaginative person or persons could probably do this indefinitely.

Another similar direction would be to change the milieu of the game. Zork,
Adventure, and Haunt (the CFS games known to the authors) all flow back to D&amp;D
and the literary tradition of fantasy exemplified by J. R. R. Tolkien, Robert
E. Howard, and Fritz Leiber. There are, however, other milieus; science
fiction is one that comes to mind quickly, but there are undoubtedly others.

A slightly different approach to the future would be to expand the simulation
universe portrayed in the game. For example, in Zork the concept of "wearing
something" is absent: with it there could be magic rings, helmets, boots, etc.
Additionally, the player's body itself might be added. For example, a player
could be wounded in his sword arm, reducing his fighting effectiveness, or in
his leg, reducing his ability to travel.

The preceding are essentially trivial expansions to the game. A more
interesting one might be the introduction of magic spells. To give some idea
of the kinds of problems new concepts introduce to the game, consider this
brief summary of problems that would have to be faced: If magic exists, how
do players learn spells? How are they invoked? Do they come in different
strengths? If so, how does a player qualify for a stronger version of a spell
than he has? What will spells be used for (are they like the magic words in
Adventure, for example)? How does a player retain his magic abilities over
several sessions of a game?

As can be seen, what at first seems to be a fairly straightforward addition to
a game that already has magical elements raises many questions. One of the
lessons learned from Zork, in fact, is one that should be well known to all in
the computing field: "There is no such thing as a small change!"

A still more ambitious direction for future CFS games is that of
multiple-player games. The simplest possible such game introduces major
problems, even ignoring the mechanism used to accomplish communication or
sharing. For example, there are impressive problems related to the various
aspects of simultaneity and synchronization. How do players communicate with
each other? How do they coordinate actions, such as attacking some enemy in
concert?

Putting aside implementation problems, a multiple-player game would need to
have (we believe) fundamentally different types of problems to be interesting.
If the game were cooperative (as are most D&amp;D scenarios), then problems
requiring several players' aid in solving them would need to be devised. If
the game were competitive and like the current Zork, the first player to
acquire the (only) correct tool for a job would have an enormous advantage, to
give just one example. Other issues are raised by the statistic that the
average player takes weeks and many distinct sessions to finish the game; what
happens to him during the time he is not playing and others are?

We believe there is a great future for this type of game, both for the players
and for the implementers and designers of more complex, more sophisticated,
and -- in short -- more real simulation games.

## Zork distribution

Zork is available from two sources. The most up-to-date version is available
from P. David Lebling, Room 205, 545 Technology Square, Cambridge, MA 01239.
This version is compatible with the ITS, Tenex, and Tops-20 operating systems
for the Digital Equipment Corp. PDP-10. To obtain this version, you must
enclose a magnetic tape and return postage. Another version, translated from
MDL into Fortran, is available through DECUS, (the Digital Equipment Computer
Users Society), One Iron Way, Marlboro, MA 01752. This version is compatible with
PDP-11 and VAX operating systems.

## Bibliography

S. W. Galley and Greg Pfister, *MDL Primer and Manual*, MIT Laboratory for
Computer Science, 1977.

P. David Lebling, *The MDL Programming Environment*, MIT Laboratory for
Computer Science, 1979.

Gary Gygax and Dave Arneson, "Dungeons and Dragons," TSR Hobbies, Inc., Lake
Geneva, Wisc.

<img class="float-left" style="height: 5em; clear: both;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/lebling.jpg" alt="Dave Lebling" name="Dave Lebling">

**P. David Lebling** is a staff member of the MIT Laboratory for Computer
Science, where he works on data-intensive planning systems and computer
message systems. He was previously involved in Morse code transcription and
understanding system. He holds SB and SM degrees in political science from
MIT.

<img class="float-left" style="height: 5em; clear: both;" src="/public/img/articles/zork-a-computerized-fantasy-simulation-game/blank.jpg" alt="Marc Blank" name="Marc Blank">

**Marc S. Blank** is a medical student at the Albert Einstein College of
Medicine; he expects to graduate in June. He is employed from time to time as
a consultant at the MIT Laboratory for Computer Science, where he works on MDL
databases and system maintenance. A graduate of MIT with a BS in biology, he
is a member of Phi Beta Kappa and Phi Lamdba Upsilon.

**Timothy A. Anderson** is a member of the research staff at Computer
Corporation of America, Cambridge, Massachusetts, where he works on the
distributed data base system SDD-1. As a graduate student at MIT Laboratory
for Computer Science, Anderson was involved in research on Morse code
understanding. He is a member of ACM, Sigma Xi, Tau Beta Pi, and Eta Kappa Nu,
and holds SB and SM degrees in computer science from MIT.
