<!--
	Title: Zork and the Future of Computerized Fantasy Simulations
	Author: P David Lebling
	Source: BYTE, v5(12)
	Date: December 1980
	Transcription by Steve Derby
-->

<style>
blockquote {
	border-top: 0.25em solid var(--dark); border-bottom: 0.25em solid var(--dark);
	margin-left: 2em;
	padding: 0 1em;
	font-style: italic;
	font-size: 1.25em;
	p { margin: 0.25em 0; }
}
</style>

CFS (computerized fantasy simulation) games are a
new art form: the computerized storybook. Instead of
reading the story, you play it. The author presents the
story, but only as you squeeze it out of him by wit and
brute force. It's up to you to figure out what's going on,
and the satisfaction of doing so depends on how well
thought out the story is. To be fun to play, the story must
be more or less consistent and complete. To a large extent,
this means that the program that embodies the story
must simulate the universe well.

I have been involved for several years with *Zork*, one
of the larger and (I would like to think) better worked out
CFS games . The authors (Marc Blank, Tim Anderson,
Bruce Daniels, and I) have spent a lot of time trying to
make the universe of *Zork* as consistent and complete as
possible within the bounds of the space available. The
first version of *Zork* was written for the Digital Equipment
Corporation PDP-10; it eventually grew to strain
even the megabyte address space of that machine. The
game was completely rewritten for microcomputers and
is now limited primarily by the size of a 5-inch floppy
disk. *Zork* games swap data (programs and text) into
memory from the disk as needed and therefore aren't
limited by the size of the system's user memory.

Standard 5-inch floppy disks store about 100 K bytes
(some store more, some less). This works out to about
10,000 words of English prose and a similar amount
(about 40 K bytes) of code. This is large for a
microcomputer-based program, but as literature it's still
only at the short story length.

<div class="article-sidebar float-left" style="border: 1px solid var(--dark); background: inherit;">

*If you are interested in playing* Zork: The Great
Underground Empire, Part I, *the game is distributed
by Personal Software, 1330 Bordeaux Dr, Sunnyvale
CA 94086 on foppy disk for Apple II and TRS-80 computers.*
Zork *games are produced by lnfocom Inc,
POB 120, Kendall Sta, Cambridge MA 02142. Zork is
a trademark of lnfocom Inc.*

</div>

*Zork* is shrunk to fit into the micro-world by running
on a *Zork-language virtual machine*. This means that the
code that is running while you are playing *Zork* is much
more compact than the same program would be if written
in machine language (on a Radio Shack TRS-80, for example).
This is because the instruction set of the virtual
machine is tailored to CFS games. For example, the *Zork*-language
instruction to move an object from one room to
another takes just 3 bytes of storage. The other advantage
is that the *Zork* code is machine independent; all it
takes to move Zork to another machine is to write the
*Zork*-language interpreter for that machine. Such interpreters
currently exist for the Apple II, PDP-11, PDP-10
and the TRS-80. For more details about the *Zork*-language
see "How to Fit a l.arge Program into a Small
Machine," by Marc S Blank and SW Galley, July 1980,
*Creative Computing*.

Even using a disk to store parts of the game, the
PDP-10 *Zork* was still too large for the micro-world. As a
result, we split it into two smaller, independent games:
*The Great Underground Empire, Part I*, and *The Great
Underground Empire, Part II*. each of which is a self-contained
program. There was room left over, so we added
some new problems to round things out.

Still, a lot of universe can fit into a microcomputer and
disk. *Zork* "understands" a useful subset of English
(mostly imperative sentences), including sentences as
complex as "Put all of the books but the green one under
the rug." The *Zork* vocabulary is over 600 words and includes
100 verbs. A parser this powerful is a good-news/bad-news
proposition. On the one hand, such a parser
makes possible the implementation of subtle and realistic
problems. When the most complicated sentence you can
understand is "Drop uranium," you are limited to producing
certain types of situations. If you can say "Tell the
Robot 'Put the uranium in the lead box'," then the game
can become more interesting.

> One method of dealing with players who are "killed" in *Zork*
> is to resurrect them in a forest.

*Zork* has a fairly complicated parser for imperative
sentences. It endeavors to reduce its input to a construction
of:

<p style="text-align: center;">&lt;verb&gt; &lt;direct object&gt; &lt;indirect object&gt;</p>

where the objects are optional. Prepositions are folded into
the verb, which allows Zork to differentiate

<p style="text-align: center;"><em>&gt;PUT BOMB UNDER TROPHY CASE</em></p>

from

<p style="text-align: center;"><em>&gt;PUT BOMB IN TROPHY CASE</em></p>

(Lines beginning with &gt; are the player's input.)

Similarly, adjectives are used to distinguish among
several books, doors, or any collection of like objects. In
conjunction with *all* and *but*, adjectives provide powerful
constructs:

<p style="text-align: center;"><em>&gt;TAKE ALL THE TREASURES<br>
&gt;BURN ALL THE BOOKS BUT THE BLACK ONE</em></p>

The parser also allows the player to be laconic, if he so
desires. If only one object in the vicinity fits the verb he
uses, it will be selected and the player will be informed:

*&gt;KILL TROLL<br>
(with sword)*

If the meaning is not obvious, the player is asked to
clarify, and the new input is added to the old to produce a
complete sentence. This can go on indefinitely:

*&gt;OPEN<br>
Open what?<br>
&gt;DOOR<br>
Which door do you mean?<br>
&gt;THE TRAP DOOR*

For more details on the *Zork* parser and internal structure,
see "[Zork: A Computerized Fantasy Simulation
Game](/library/zork-a-computerized-fantasy-simulation-game)," by P David Lebling, Marc S Blank, and Timothy
A Anderson, in *IEEE Computer*, April, 1979.

On the negative side, having a clever parser means that
the player may expect almost any concept to be
understood. Unfortunately, only a small number of concepts
can be implemented given the available space.

Some concepts that *Zork* does implement are:

* **Properties:** Objects can have properties or attributes,
some of them changeable. Lamps can be on or off,
treasures valuable or worthless, villains fighting-mad or
peaceful. Some of these properties never change; a container
is always a container, for example. But other properties
can change; for example, some containers may be
opened and closed at will.

* **Containment:** Objects may have contents. Bottles can
contain water and be open or closed. Some objects are
transparent. Some objects must be unlocked before they
can be opened. The capacity of an object is limited. (For
example, a paper bag won't hold as much as a bucket.)

* **Weight:** Objects have weight. A solid gold coffin
weighs a lot more than a newspaper. The amount a
player can carry depends on the total number of objects
carried and on the total weight of the objects and their
contents.

* **Position:** An object may be in, on, or under another
object.

* **Vehicles:** The player may be in a vehicle which is
traveling through the locations in the game. In addition
to the player, the vehicle may have other contents
distinct from the player's belongings and the "contents"
of the location.

* **Time:** Game events may be scheduled to happen at arbitrary
future times. Time-bombs may go off, matches
burn out, lanterns grow dimmer, and so on.

* **Actors:** Actors are other characters who have roles in
the game. They may fight or choose not to. They may
speak to the player or be spoken to. They may move
around or stay in a particular place.

* **Fighting:** The player may engage in combat with other
inhabitants of the game. He may be wounded (affecting
his ability to carry heavy loads), or he may kill his opponent
and retrieve the opponent's weapon.

Every object in *Zork* has a pointer to its location
(which may be "nowhere"), which is its *parent*; a pointer
to the next object in the same location, which is its *sibling*;
and a pointer to its first contents, which is its first
*child*. Thus, a container points to its contents, and the
contents point back to it.

One result of this implementation is that an object can
be in only one place at one time. Things like water, which
can potentially be infinitely finely divided, are difficult to
implement in *Zork* for this reason. Consequently *Zork*
has two "water" objects; one for water in general (flowing
in streams, filling reservoirs, leaking from pipes) and
one for water in the player's possession (in a bottle, for
example). In handling water, the general sort always
eventually ends up as the specific sort, and exceptions
aren't tolerated:

*&gt;FILL BOTTLE WITH WATER<br>
The bottle is now full of water<br>
&gt;POUR WATER;<br>
The water spills to the ground and evaporates.*

Another aspect of containment involves problems of
weight and capacity. The weight of an object must
always be the sum of its own weight and the weight of its
contents. Naturally, each of the contained objects has its
weight calculated the same way. On the other hand, the
volume of an object is filled only by the size of the objects
directly in it.

*LOOK
You are in the magic boat.<br>
The magic boat contains:<br>
&nbsp;&nbsp;A shovel.<br>
&nbsp;&nbsp;A lamp.<br>
&nbsp;&nbsp;A solid-gold coffin.<br>
&nbsp;&nbsp;The solid-gold coffin contains:<br>
&nbsp;&nbsp;&nbsp;&nbsp;A brown sack.<br>
&nbsp;&nbsp;&nbsp;&nbsp;The brown sack contains:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A lunch.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A clove of garlic.*

Of course, containers have other properties. They can
be open or closed, opaque or transparent, locked or
unlocked.

*>INVENTORY<br>
You are carrying:<br>
A glass bottle.<br>
The glass bottle contains:<br>
&nbsp;&nbsp;A quantity of water.<br>
&gt;DRINK WATER<br>
1 can't reach the quantity of water.<br>
&gt;OPEN BOTTLE<br>
Opened.<br>
&gt;DRINK WATER<br>
Thank you very much. I was rather thirsty.*

The concept of a *surface* is implemented as a special
kind of containment. Objects which have surfaces on
which other objects may sit are actually containers with
an additional property of "surfaceness."

Vehicles are an even more specialized case of containers.
A vehicle has a property called the *action property*
that is allowed a chance to give special handling to any
input of the player. For example, a spaceship vehicle
might want to restrict the player's movement during the
acceleration phase of a flight or prevent him from taking
objects that are outside the ship.

Possibly the most useful concept in *Zork* is that of
*time*. An arbitrary event may be scheduled to occur at an
arbitrary time in the future: for example, the discharging
of the batteries in a lantern is controlled in this way.

Introducing time also introduces some problems. If an
event is scheduled, the circumstances under which it is
valid must be coded into it. Otherwise, the behavior of
the game can appear nonsensical. Suppose the player
lights the fuse on some dynamite. If he sticks around, he
will be blown to smithereens. He runs away, only to find
that the dynamite has apparently followed him. He still
gets blown up because, when the explosion happens, the
program doesn't check to see if he is still there.

One method of dealing with players who are "killed" in
*Zork* is to resurrect them in a forest. In an early version
of *Zork*, it was possible to be killed by the collapse of an
unstable room. Due to carelessness with scheduling such
a collapse, 50,000 pounds of rock might fall on your head
during a stroll down a forest path. Meteors, no doubt.

In an effort to introduce a little more randomness into
what was at one time a deterministic game, we added
fighting. The player was allowed to attack any of the
monsters or other characters he encountered during his
travels. The scheme we implemented is conceptually simple.
There is a range of possible outcomes for any attack,
either by the player on a villain or vice versa. You can be
killed outright, knocked unconscious, wounded, wounded
seriously, staggered, or you can have your weapon
knocked from your hand.

The villain, each time it is his turn to riposte, has the
option of parrying or turning and running (if he is not
limited to one room, as the troll is). Some weapons are
better against certain opponents than others. The relative
strengths of player and opponent figure into the outcome
as well (the player's strength is a function of health and
progress in the game). The results are a selection of appropriate
messages describing the fight as it progresses.

*&gt;KILL THIEF WITH SWORD<br>
Clang! Crash! The thief parries.<br>
&gt;AGAIN<br>
The thief receives a deep gash on his side.<br>
&gt;KILL<br>
The thief slowly approaches, strikes like a snake, and
leaves you wounded.<br>
&gt;ATTACK<br>
The thief is disarmed by a subtle feint past his guard. The
robber, somewhat surprised at this turn of events, nimbly
retrieves his stiletto.<br>
&gt;KILL THIEF<br>
A good stroke! Blood wells down the thief's leg. You
evidently frightened the robber. He flees, but the contents
of his bag fall to the floor.*

Well, he may live to fight another day, but you
recovered some of his booty. Fighting in *Zork* is pretty
primitive when compared to real life or even to a "melee"
in the popular game *Dungeons and Dragons*. You could
make combat more elaborate, and in fact there are CFS
games that have gone in that direction, producing quite
realistic "hack and slash" games.

Possibly, the most enjoyable aspect of writing *Zork*
was designing the other characters the player may encounter.
*Zork* contains various other actors, including a
troll, a thief, a wizard, various monsters and friendly
gnomes, and a beautiful princess. Some of these are pretty
simple. The troll is basically an obstacle. He doesn't
move but merely bars the way and must be defeated by
force of arms.

The thief, on the other hand, is embodied by a complex
program. After a while, he begins to take on a personality
of his own: the slightly down-at-the-heels younger son
of a noble family, perhaps. He is cultivated but has a
rather nasty sense of humor. For example, his idea of fun
is to foul up the standard Adventure maze-mapping
technique of identifying rooms by dropping objects in
them. When he finds a player doing that, he will wander
around switching objects, no doubt chuckling all the
while:

*You are in a maze of twisty little passages, all alike.<br>
&gt;DROP KNIFE<br>
Dropped.<br>
In the distance, you hear a voice saying, "My, I wonder
what this fine rope is doing here?"*

Some actions of the thief are motivated by the characterization;
he is unlikely to kill you during a fight if he
knocks your weapon out of your hand -- too well bred.
On the other hand, maybe his thiefly reflexes will get the
better of him . . . . Many of the thief's actions are
motivated by simple probability. There is a certain
chance he will stop in any room while roaming around, a
certain probability that he will steal any particular object
(high for treasures, of course), and a probability that he
will decide to attack the player. His behavior, nonetheless,
can seem very realistic: Sometimes he seems to dog
the player, who no sooner finds a treasure than the thief
filches it.

There is a rich range of possibilities in producing games
in which characters in the story (other than the player)
act more like real people and less like monsters or one-dimensional
villains. But the simulation of human
behavior is still an unsolved problem in the field of artificial
intelligence. The best approximations to date have
been the classic simulations of a nondirective
psychotherapist (Weizenbaum's Eliza) and of a psychotic
paranoid (Colby's Parry). But even they would not make
very interesting characters in a story. (These two curious
beings actually met once, as recorded in "Parry Encounters
the Doctor" by Vinton Cerf, in *Datamation*, July
1973.)

There are other, more mundane areas in which *Zork*
could be extended. For example, take a simple concept
like clothing. If the player can reference his clothing (or
even a magic ring he might be wearing) some interesting
questions arise. Is there a distinction between wearing
something and carrying something? Probably, because
when the player says "drop all," he probably doesn't
mean to include his clothes. Also, the existence of clothes
probably means the definition of many parts of the body.
You could take this to extremes:

*&gt;INVENTORY<br>
You are empty-handed.<br>
You are wearing a diamond ring on your right index
finger.<br>
You are wearing bells on your toes.<br>
You are wearing a coonskin cap on your head.*

Of course, if you implement clothes, there might as well
be pockets, and backpacks, and other "different" sorts of
containers. It would have to be defined whether the
player can reference things inside them (what if the flap
of the backpack is closed, for example?). What happens if
he falls into a lake? Do the clothes drag him down? What
about wearing a suit of armor? Clothes probably need a
weight or need to produce a fatigue effect on the player.

The mention of falling into a lake brings up another
possible extension to *Zork*. Currently players aren't
allowed to swim. One reason was to avoid the problems
associated with the player's belongings dragging him
under. Another is the question of what happens to his
belongings. Do they get wet? If so, do they ever dry out
again? What about wet matches (to give one example)? Is
wet paper still burnable? How long can the player swim?
Can he hold his breath and swim underwater? There are
any number of questions that have to be considered if
such a feature is to be implemented.

Even the addition of a run-of-the-mill object can produce
complications. In early versions of *Zork*. the troll's
axe disappeared when he was killed. We finally decided
to let the player recover it, as advances in *Zork* weapons
technology removed the reason for destroying it. Unfortunately,
we didn't think it through. One of our best
play testers, on hearing that "you can finally get the axe,"
immediately said, "Great, I'm going to go up to the forest
and chop down some trees." Oops. We never thought of
that, not to mention using the axe to chop through doors,
split timbers, and any number of other commonplace
uses for something we were thinking of strictly as a
weapon.

The authors of *Zork* have thought about several possible
extensions to the *Zork* parser. One that has come up
many times is to add adverbs. A player should be able to
do the following:

*&gt;GO NORTH QUIETLY<br>
You sneak past a sleeping lion who sniffs but doesn't
wake up.*

The problem is to think of reasons why you would not do
everything "quietly," "carefully," or whatever. Perhaps
there should be time and fatigue penalties for doing
things in a nonstandard way:

*&gt;SEARCH WALL CAREFULLY*

This would take a long time (and all the while the lamp is
burning down), possibly tiring the player out. To be fair
to the player, he should not need to search every wall
carefully, or walk quietly everywhere. There should be
reasonable clues or hints as to why and where he should
do such things.

This long discussion of the problems of extending *Zork*
is not intended to scare anyone (including the authors of
the game). The idea is to show that apparently simple extensions
to the game have their nonobvious ramifications. Of course,
it would be simple to ignore them, but
we think that the authors of a game should play fair with
the players. Just as it's disappointing to see the wires
holding up Flash Gordon's spaceship, it's disappointing
to see:

*&gt;PUT RING ON FINGER<br>
I don't know the word 'finger'.*

We authors would hardly claim that *Zork* is perfect in
this respect, but we have made an effort in that direction.
When we add something new, we try to think of how the
player might try to use it and what verbs he might try to
apply to it. Within the space available, we've tried to put
most of those things in.

All the CFS games that I have encountered are similar
in one major respect: they are about problem solving and
the acquisition of treasure. This is probably because a
structure containing problems and rewards is obvious
and easy to implement.

It is possible to imagine games in which the goals are
different. Some programmers in southern California have
designed a game in which the moral choices the player
makes have a significant impact on the game. For example,
does the player give an old man some water? Similarly,
the problem-solving idea could be shifted into
something closer to scientific research. The player could
be introduced into an environment where he performs experiments,
ponders the results, and ultimately gains
understanding and control of that environment.

Innovations in form as well as content are possible.
There are already CFS games that try to give the player a
graphic view of his surroundings . As microcomputer
technology advances, this will become more common,
and the renditions will achieve higher quality: it will be
technically feasible to have a CFS game "illustrated" by
Frank Frazetta or Jeff Jones. On the other hand, the
player's imagination probably has a more detailed picture
of the Great Underground Empire than could ever be
drawn. I can even recall discussions among the game's
implementors over who should play the thief in the
movie version.

Another area where experimentation is going on is that
of multiplayer CFS games. Each player (possibly not even
aware how many others are playing) would see only his
own view of the territory. He would be notified when
other players enter or leave the room, and could talk to
them. There was briefly a multiplayer version of the
PDP-10 Zork several years ago, and today there is a
"Multiple User Dungeon" at Essex University in England.

There are major problems, however. One is producing
problems that are compatible with different numbers of
players (from one to, say, a dozen). If it takes five players
to solve a problem (one to hold the light bulb and four to
turn the ladder?), what happens if only two people are
playing? The other problem, as far as the microcomputer
owner is concerned, is that few can afford an unlimited
number of machines or even video monitors to accommodate
so many players.

CFS games as an art form can continue to grow as long
as their medium continues to grow. *Zork* is already constricted
by the size of today's microprocessors (it was
large even on the PDP-10), but the new generations of
16- and 32-bit machines offer the opportunity of enormous
further growth. The possibilities of new concepts,
new milieux, and new purposes are enormous. We would
like to think that it will not be long before authors view
such scenarios as just another medium of expression. I
find the prospect exciting because I enjoy playing CFS
games as much as writing them.
