1998Q1/

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, The Craft of Adventure</title>

<link rev="made" href="mailto:claw#under,engr.sgi.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">

MUD-Dev mailing list archive

[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
 <hr>

Date:&nbsp;
[&nbsp;<a href="msg00706.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00708.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00711.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00705.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00707">Author</A>
&nbsp;|&nbsp;<A HREF="#00707">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00707">Thread</A>
&nbsp;]

<H1>The Craft of Adventure</H1>
<HR>


<UL>
<LI>To: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI>Subject: The Craft of Adventure</LI>
<LI>From: J C Lawrence &lt;<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>&gt;</LI>
<LI>Date: Thu, 12 Mar 1998 19:37:26 -0800</LI>
</UL>


<HR>


<PRE>

<A HREF="ftp://ftp.gmd.de/if-archive/programming/general-discussion/Craft.Of.Adventure.txt">ftp://ftp.gmd.de/if-archive/programming/general-discussion/Craft.Of.Adventure.txt</A>

------------------------------------------------------------------------------
The Craft of Adventure

Five articles on the design of adventure games

(Second edition, plain text version)
------------------------------------------------------------------------------
1 Introduction
2 In The Beginning
3 Bill of Player's Rights
4 A Narrative...
5 ...At War With a Crossword
6 Varnish and Veneer
------------------------------------------------------------------------------

1 Introduction
===============

Skill without imagination is craftsmanship and gives us
many useful objects such as wickerwork picnic baskets.
Imagination without skill gives us modern art.

-- Tom Stoppard, Artist Descending A Staircase

Making books is a skilled trade, like making clocks.

-- Jean de la Bruyere (1645-1696)

If you're going to have a complicated story you must work to
a map; otherwise you'll never make a map of it afterwards.

-- J. R. R. Tolkien (1892-1973)

Designing an adventure game is both an art and a craft. Whereas art cannot
be taught, only commented upon, craft at least can be handed down: but the
tricks of the trade do not make an elegant narrative, only a catalogue. This
small collection of essays is just such a string of grits of wisdom and
half-baked critical opinions, which may well leave the reader feeling
unsatisfied. One can only say to such a reader that any book claiming to
reveal the secret of how to paint, or to write novels, should be recycled at
once into something more genuinely artistic, say a papier-mache sculpture.

If there is any theme here, it is that standards count: not just of
competent coding, but of writing. True, most designers have been either
programmers `in real life' or at the `Hardy Boys Mysteries' end of the
literary scale, but that's no reason to look down on their better works, or
to begrudge them a look at all. Though this book is mainly about the larger
scale, one reason I think highly of `Spellbreaker' is for memorable phrases
like `a voice of honey and ashes'. Or `You insult me, you insult even my
dog!'

The author of a text adventure has to be schizophrenic in a way that the
author of a novel does not. The novel-reader does not suffer as the player
of a game does: she needs only to keep turning the pages, and can be trusted
to do this by herself. The novelist may worry that the reader is getting
bored and discouraged, but not that she will suddenly find pages 63 to the
end have been glued together just as the plot is getting interesting.

Thus, the game author has continually to worry about how the player is
getting along, whether she is lost, confused, fed up, finding it too tedious
to keep an accurate map: or, on the other hand, whether she is yawning
through a sequence of easy puzzles without much exploration. Too difficult,
too easy? Too much choice, too little? So this book will keep going back
to the player's eye view.

On the other hand, there is also a novel to be written: the player may get
the chapters all out of order, the plot may go awry, but somehow the author
has to rescue the situation and bind up the strings neatly. Our player
should walk away thinking it was a well-thought out story: in fact, a novel,
and not a child's puzzle-book.

An adventure game is a crossword at war with a narrative. Design sharply
divides into the global - plot, structure, genre - and the local - puzzles
and rooms, orders in which things must be done. And this book divides
accordingly.

Frequent examples are quoted from real games, especially from `Adventure'
and the middle-period Infocom games: for two reasons. Firstly, they will
be familiar to many aficionados. Secondly, although a decade has passed
they still represent the bulk of the best work in the field. In a few
places my own game `Curses' is cited, because I know all the unhappy
behind-the-scenes stories about it.

I have tried not to give anything substantial away. So I have also avoided
mention of recent games other than my own; while revising this text, for
instance, I had access to an advance copy of David M. Baggett's fine game
`The Legend Lives', but resisted the temptation to insert any references to
it. Except to say that it demonstrates that, as I write this, the genre is
still going strong: well, long may it.

Graham Nelson
Magdalen College, Oxford
January 1995

2 In The Beginning
===================

It's very tight. But we have cave!

-- Patricia Crowther, July 1972

Perhaps the first adventurer was a mulatto slave named Stephen Bishop, born
about 1820: `slight, graceful, and very handsome'; a `quick, daring,
enthusiastic' guide to the Mammoth Cave in the Kentucky karst. The story
of the Cave is a curious microcosm of American history. Its discovery
is a matter of legend dating back to the 1790s; it is said that a hunter,
John Houchin, pursued a wounded bear to a large pit near the Green River and
stumbled upon the entrance. The entrance was thick with bats and by the War
of 1812 was intensively mined for guano, dissolved into nitrate vats to make
saltpetre for gunpowder. After the war prices fell; but the Cave became a
minor side-show when a dessicated Indian mummy was found nearby, sitting
upright in a stone coffin, surrounded by talismans. In 1815, Fawn Hoof, as
she was nicknamed after one of the charms, was taken away by a circus,
drawing crowds across America (a tour rather reminiscent of Don McLean's
song `The Legend of Andrew McCrew'). She ended up in the Smithsonian but
by the 1820s the Cave was being called one of the wonders of the world,
largely due to her posthumous efforts.

By the early nineteenth century European caves were big tourist attractions,
but hardly anyone visited the Mammoth, `wonder of the world' or not. Nor
was it then especially large (the name was a leftover from the miners, who
boasted of their mammoth yields of guano). In 1838, Stephen Bishop's owner
bought up the Cave. Stephen, as (being a slave) he was invariably called,
was by any standards a remarkable man: self-educated in Latin and Greek, he
became famous as the `chief ruler' of his underground realm. He explored
and named much of the layout in his spare time, doubling the known map in a
year. The distinctive flavour of the Cave's names - half-homespun American,
half-classical - started with Stephen: the River Styx, the Snowball Room,
Little Bat Avenue, the Giant Dome. Stephen found strange blind fish,
snakes, silent crickets, the remains of cave bears (savage, playful
creatures, five feet long and four high, which became extinct at the end of
the last Ice Age), centuries-old Indian gypsum workings and ever more cave.
His 1842 map, drafted entirely from memory, was still in use forty years
later.

As a tourist attraction (and, since Stephen's owner was a philanthropist,
briefly a sanatorium for tuberculosis, owing to a hopeless medical
theory) the Cave became big business: for decades nearby caves were hotly
seized and legal title endlessly challenged. The neighbouring chain, across
Houchins Valley in the Flint Ridge, opened the Great Onyx Cave in 1912. By
the 1920s, the Kentucky Cave Wars were in full swing. Rival owners diverted
tourists with fake policemen, employed stooges to heckle each other's guided
tours, burned down ticket huts, put out libellous and forged advertisements.
Cave exploration became so dangerous and secretive that finally in 1941 the
U.S. Government stepped in, made much of the area a National Park and
effectively banned caving. The gold rush of tourists was, in any case,
waning.

Convinced that the Mammoth and Flint Ridge caves were all linked in a huge
chain, explorers tried secret entrances for years, eventually winning
official backing. Throughout the 1960s all connections from Flint Ridge -
difficult and water-filled tunnels - ended frustratingly in chokes of
boulders. A `reed-thin' physicist, Patricia Crowther, made the breakthrough
in 1972 when she got through the Tight Spot and found a muddy passage: it
was a hidden way into the Mammoth Cave.

Under the terms of his owner's will, Stephen Bishop was freed in 1856, at
which time the cave boasted 226 avenues, 47 domes, 23 pits and 8 waterfalls.
He died a year later, before he could buy his wife and son. In the 1970s,
Crowther's muddy passage was found on his map.

The Mammoth Cave is huge, its full extent still a matter of speculation
(estimates vary from 300 to 500 miles). Patricia's husband, Willie
Crowther, wrote a computer simulation of his favourite region, Bedquilt
Cave, in FORTRAN in the early 1970s. (It came to be called Colossal Cave,
though this name actually belongs further along.) Like the real cave, the
simulation was a map on about four levels of depth, rich in geology. A good
example is the orange column which descends to the Orange River Rock room
(where the bird lives): and the real column is indeed orange (of travertine,
a beautiful mineral found in wet limestone).

The game's language is loaded with references to caving, to `domes' and
`crawls'. A `slab room', for instance, is a very old cave whose roof has
begun to break away into sharp flakes which litter the floor in a crazy
heap. The program's use of the word `room' for all manner of caves and
places seems slightly sloppy in everyday English, but is widespread in
American caving and goes back as far as Stephen Bishop: so the
Adventure-games usage of the word `room' to mean `place' may even be
bequeathed from him.

Then came elaboration. A colleague of Crowther's (at a Massachusetts
computing firm), Don Woods, stocked up the caves with magical items and
puzzles, inspired by a role-playing game. Despite this, very many of the
elements of the original game crop up in real life. Cavers do turn back
when their carbide lamps flicker; there are mysterious markings and initials
on the cave walls, some left by the miners, some by Bishop, some by 1920s
explorers. Of course there isn't an active volcano in central Kentucky, nor
are there dragons and dwarves. But even these embellishments are, in a
sense, derived from tradition: like most of the early role-playing games,
`Adventure' owes much to J. R. R. Tolkien's `The Hobbit', and the passage
through the mountains and Moria of `The Lord of the Rings' (arguably its
most dramatic and atmospheric passage). Tolkien himself, the most
successful myth-maker of the twentieth century, worked from the example of
Icelandic, Finnish and Welsh sagas.

By 1977 tapes of `Adventure' were being circulated widely, by the Digital
user group DECUS, amongst others: taking over lunchtimes and weekends
wherever it went... but that's another story. (Tracy Kidder's fascinating
book `The Soul of a New Machine', a journalist's-eye-view of working in a
computing firm at about this time, catches it well.)

There is a moral to this tale, and a reason for telling it. The original
`Adventure' was much imitated and many traditions are derived from it. It
had no direct sequel itself but several `schools' of adventure games began
from it. `Zork' (which was to be the first Infocom game) and
`Adventureland' (the first Scott Adams game) include, for instance, a
rather passive dragon, a bear, a troll, a volcano, a maze, a lamp with
limited battery-power, a place to deposit treasures and so on. The earliest
British game of real quality, `Acheton', written at Cambridge University in
1979-80 by David Seal and Jonathan Thackray (and the first of a dozen or so
games written in Cambridge) has in addition secret canyons, water, a
wizard's house not unlike that of `Zork'. The Level 9 games began with a
good port of `Adventure' (which was generally considered at the time, and
ever since, to be in the public domain, on what legal grounds it's hard to
see) and then two sequels in similar style. All these games had a standard
prologue-middle game-end game form: the prologue is a tranquil outside
world, the middle game consists of collecting treasures in the cave, the end
is usually called a Master Game (Level 9 expanded on the `Adventure' end
game somewhat, not so well).

Of this first crop of games, `Adventure' remains the best, mainly because it
has its roots in a simulation. This is why it is so atmospheric, more so
than any other game for a decade after. The Great Underground Empire of
`Zork' is an imitation of the original, based not on real caves but on
Crowther's descriptions. `Zork' is better laid out as a game but not as
convincing, and in places a caricature: too tidy, with no blind alleys, no
secret canyons. Its mythology is similarly less well-grounded: the
long-gone Flathead dynasty, beginning in a few throwaway jokes, ended up
downright tiresome in the later sequels, when the `legend of the Flatheads'
had become, by default, the distinguishing feature of `Zorkness'. The
middle segments especially of `Zork' (now called `Zork II') make a fine
game, one of the best of the `cave' games, but `Zork' remains flawed in a
way that many of Infocom's later games were not.

In the beginning of any game is its `world', physical and imaginary,
geography and myth. The vital test takes place in the player's head: is the
picture of a continuous sweep of landscape, or of a railway-map on which a
counter moves from one node to another? `Adventure' passes this test,
however primitive some may call it. If it had not done so, the genre might
never have started.

3 Bill of Player's Rights
==========================

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.

-- P. David Lebling

W. H. Auden once observed that poetry makes nothing happen. Adventure games
are far more futile: it must never be forgotten that they intentionally
annoy the player most of the time. There's a fine line between a challenge
and a nuisance: the designer has to think, first and foremost, like a
player (not an author, and certainly not a programmer). With that in mind,
I hold the following rights to be self-evident:

1. Not to be killed without warning

At its most basic level, this means that a room with three exits, two of
which lead to instant death and the third to treasure, is unreasonable
without some hint. On the subject of which:

2. Not to be given horribly unclear hints

Many years ago, I played a game in which going north from a cave led to a
lethal pit. The hint was: there was a pride of lions carved above the
doorway. Good hints can be skilfully hidden, or very brief, but should
not need explaining after the event. (The game was Level 9's `Dungeon',
in which pride comes before a fall. Conversely, the hint in the
moving-rocks plain problem in `Spellbreaker' is a masterpiece.)

3. To be able to win without experience of past lives

This rule is very hard to abide by. Here are three examples:
(i) There is a nuclear bomb buried under some anonymous
floor somewhere, which must be disarmed. The player knows
where to dig because, last time around, it blew up there.
(ii) There is a rocket-launcher with a panel of buttons, which looks
as if it needs to be correctly programmed. But the player
can misfire the rocket easily by tampering with the controls
before finding the manual.
(iii) (This from `The Lurking Horror'.) Something needs to be cooked
for the right length of time. The only way to find the right
time is by trial and error, but each game allows only one trial.
On the other hand, common sense suggests a reasonable answer.

Of these (i) is clearly unfair, most players would agree (ii) is fair enough
and (iii), as tends to happen with real cases, is border-line. In principle,
then, a good player should be able to play the entire game out without doing
anything illogical, and deserves likewise:

4. To be able to win without knowledge of future events

For example, the game opens near a shop. You have one coin and can buy a
lamp, a magic carpet or a periscope. Five minutes later you are transported
away without warning to a submarine, whereupon you need a periscope. If you
bought the carpet, bad luck.

5. Not to have the game closed off without warning

`Closed off' meaning that it would become impossible to proceed at some
later date. If there is a Japanese paper wall which you can walk through at
the very beginning of the game, it is extremely annoying to find that a
puzzle at the very end requires it to still be intact, because every one of
your saved games will be useless. Similarly it is quite common to have a
room which can only be visited once per game. If there are two different
things to be accomplished there, this should be hinted at.

In other words, an irrevocable act is only fair if the player is given due
warning that it would be irrevocable.

6. Not to need to do unlikely things

For example, a game which depends on asking a policeman about something he
could not reasonably know about. (Less extremely, the problem of the
hacker's keys in `The Lurking Horror'.) Another unlikely thing is waiting
in dull places. If you have a junction at which after five turns an elf
turns up bearing a magic ring, a player may well never spend five
consecutive turns there and will miss what you intended to be easy. (`Zork
III' is very much a case in point.) If you intend the player to stay
somewhere for a while, put something intriguing there.

7. Not to need to do boring things for the sake of it

In the bad old days many games would make life difficult by putting
objects needed to solve a problem miles away from where the problem was,
despite all logic - say, a boat in the middle of a desert. Or, for example,
a four-discs tower of Hanoi puzzle might entertain. But not an eight-discs
one. And the two most hackneyed puzzles - only being able to carry four
items, and fumbling with a rucksack, or having to keep finding new light
sources - can wear a player's patience down very quickly.

8. Not to have to type exactly the right verb

For instance, "looking inside" a box finds nothing, but "searching" it
does. Or consider the following dialogue (amazingly, from `Sorcerer'):

&gt;unlock journal
(with the small key)
No spell would help with that!
&gt;open journal
(with the small key)
The journal springs open.

This is so misleading as to constitute a bug, but it's an easy design fault
to fall into. (Similarly, the wording needed to use the brick in `Zork II'
strikes me as quite unfair, unless I missed something obvious.) Consider
how many ways a player can, for instance, ask to take a coat off:

remove coat / take coat off / take off coat / disrobe coat
doff coat/ shed coat

(I was sceptical when play-testers asked me to add "don" and "doff" to my
game `Curses', but enjoyed a certain moment of triumph when my mother tried
it during her first game.) Nouns also need...

9. To be allowed reasonable synonyms

In the same room in `Sorcerer' is a "woven wall hanging" which can instead
be called "tapestry" (though not "curtain"). This is not a luxury, it's an
essential. For instance, in `Trinity' there is a charming statue of a
carefree little boy playing a set of pan pipes. This can be called the
"charming" or "peter" "statue" "sculpture" "pan" "boy" "pipe" or
"pipes". Objects often have more than 10 nouns attached.

Perhaps a remark on a sad subject might be intruded here. The Japanese
woman near the start of `Trinity' can be called "yellow" and "Jap", for
instance, terms with a grisly resonance. In the play-testing of `Curses',
it was pointed out to me that the line "Let's just call a spade a spade"
(an innocent joke about a garden spade) meant something quite different to
extreme right-wing politicians in southern America; in the end, I kept
the line, but it's never seemed quite as funny since.

10. To have a decent parser

(If only this went without saying.) At the very least the parser should
provide for taking and dropping multiple objects.

Since only the Bible stops at ten commandments, here are seven more, though
these seem to me to be matters of opinion:

11. To have reasonable freedom of action

Being locked up in a long sequence of prisons, with only brief escapes
between them, is not all that entertaining. After a while the player begins
to feel that the designer has tied him to a chair in order to shout the plot
at him. This is particularly dangerous for adventure game adaptations of
books (and most players would agree that the Melbourne House adventures
based on `The Lord of the Rings' suffered from this).

12. Not to depend much on luck

Small chance variations add to the fun, but only small ones. The thief in
`Zork I' seems to me to be just about right in this respect, and similarly
the spinning room in `Zork II'. But a ten-ton weight which fell down and
killed you at a certain point in half of all games is just annoying.
(Also, you're only making work for yourself, in that games with random
elements are much harder to test and debug, though that shouldn't in an ideal
world be an issue.)

A particular danger occurs with low-probability events, one or a
combination of which might destroy the player's chances. For instance, in
the earliest edition of `Adventureland', the bees have an 8% chance of
suffocation each turn carried in the bottle: one needs to carry them for 10
or 11 turns, which gives the bees only a 40% chance of surviving to their
destination.

There is much to be said for varying messages which occur very often (such
as, "You consult your spell book.") in a fairly random way, for variety's
own sake.

13. To be able to understand a problem once it is solved

This may sound odd, but many problems are solved by accident or trial and
error. A guard-post which can be passed if and only if you are carrying a
spear, for instance, ought to indicate somehow that this is why you're
allowed past. (The most extreme example must be the notorious Bank of
Zork, of which I've never even understood other people's explanations.)

14. Not to be given too many red herrings

A few red herrings make a game more interesting. A very nice feature of
`Zork I', `II' and `III' is that they each contain red herrings explained in
the others (in one case, explained in `Sorcerer'). But difficult puzzles
tend to be solved last, and the main technique players use is to look at
their maps and see what's left that they don't understand. This is
frustrating when there are many insoluble puzzles and useless objects. So
you can expect players to lose interest if you aren't careful. My personal
view is that red herrings ought to be clued: for instance, if there is a
useless coconut near the beginning, then perhaps much later an absent-minded
botanist could be found who wandered about dropping them. The coconut
should at least have some rationale.

An object is not a red herring merely because it has no game function: a
useless newspaper could quite fairly be found in a library. But not a
kaleidoscope.

The very worst game I've played for red herrings is `Sorcerer', which by
my reckoning has 10.

15. To have a good reason why something is impossible

Unless it's also funny, a very contrived reason why something is
impossible just irritates. (The reason one can't walk on the grass in
Kensington Gardens in `Trinity' is only just funny enough, I think.)

Moral objections, though, are fair. For instance, if you are staying in
your best friend's house, where there is a diamond in a display case,
smashing the case and taking the diamond would be physically easy but quite
out of character. Mr Spock can certainly be disallowed from shooting
Captain Kirk in the back.

16. Not to need to be American

The diamond maze in `Zork II' being a case in point. Similarly, it's
polite to allow the player to type English or American spellings or idiom.
For instance `Trinity' endears itself to English players in that the soccer
ball can be called "football" - soccer is a word almost never used in
England. (Since these words were first written, several people have
politely pointed out to me that my own `Curses' is, shall we say, slightly
English. But then, like any good dictator, I prefer drafting constitutions
to abiding by them.)

17. To know how the game is getting on

In other words, when the end is approaching, or how the plot is
developing. Once upon a time, score was the only measure of this, but
hopefully not any more.

4 A Narrative...
=================

The initial version of the game was designed and
implemented in about two weeks.
-- P. David Lebling, Marc S. Blank, Timothy A. Anderson, of `Zork'

It was started in May of '85 and finished in June '86.
-- Brian Moriarty, of `Trinity' (from earlier ideas)

--- Away in a Genre ---

The days of wandering around doing unrelated things to get treasures are
long passed, if they ever were. Even `Adventure' went to some effort to
avoid this.

Its many imitators, in the early years of small computers, often took no
such trouble. The effect was quite surreal. One would walk across the
drawbridge of a medieval castle and find a pot plant, a vat of acid, a copy
of Playboy magazine and an electric drill. There were puzzles without
rhyme or reason. The player was a characterless magpie always on the
lookout for something cute to do. The crossword had won without a fight.

It tends to be forgotten that `Adventure' was quite clean in this respect:
at its best it had an austere, Tolkienesque feel, in which magic was scarce,
and its atmosphere and geography was well-judged, especially around the
edges of the map: the outside forests and gullies, the early rubble-strewn
caves, the Orange River Rock room and the rim of the volcano.
Knife-throwing dwarves would appear from time to time, but joky town council
officers with clipboards never would. `Zork' was condensed, less spacious
and never quite so consistent in style: machines with buttons lay side by
side with trolls and vampire bats. Nonetheless, even `Zork' has a certain
`house style', and the best of even the tiniest games, those by Scott
Adams, make up a variety of genres (not always worked through but often
interesting): vampire film, comic-book, Voodoo, ghost story.

By the mid-1980s better games had settled the point. Any player dumped in
the middle of one of `The Lurking Horror' (H. P. Lovecraft horror), `Leather
Goddesses of Phobos' (30s racy space opera) or `Ballyhoo' (mournfully
cynical circus mystery) would immediately be able to say which it was.

The essential flavour that makes your game distinctive and yours is genre.
And so the first decision to be made, when beginning a design, is the style
of the game. Major or minor key, basically cheerful or nightmarish, or
somewhere in between? Exploration, romance, mystery, historical
reconstruction, adaptation of a book, film noir, horror? In the style of
Terry Pratchett, Edgar Allen Poe, Thomas Hardy, Philip K. Dick? Icelandic,
Greek, Chaucerian, Hopi Indian, Aztec, Australian myth?

If the chosen genre isn't fresh and relatively new, then the game had better
be very good. It's a fateful decision: the only irreversible one.

--- Adapting Books ---

Two words of warning about adapting books. First, remember copyright,
which has broader implications than many non-authors realise. For instance,
fans of Anne McCaffrey's "Dragon" series of novels are allowed to play
network games set on imaginary planets which do not appear in McCaffrey's
works, and to adopt characters of their own invention, but not to use or
refer to hers. This is a relatively tolerant position on the part of her
publishers.

Even if no money changes hands, copyright law is enforceable, usually
until fifty years after the author's death (but in some countries seventy).
Moreover some classics are written by young authors (the most extreme case
I've found is a copyright life of 115 years after publication). Most of
twentieth-century literature, even much predating World War I, is still
covered: and some literary estates (that of Tintin, for instance) are highly
protective. (The playwright Alan Bennett recently commented on the trouble
he had over a brief parody of the 1930s school of adventure yarns - Sapper,
Dornford Yates, and so on - just because of an automatic hostile response
by publishers.) The quotations from games in this article are legal only
because brief excerpts are permitted for critical or review purposes.

Secondly, a direct linear plot is very hard to successfully implement in
an adventure game. It will be too long (just as a novel is usually too much
for a film, which is nearer to a longish short story in scope) and it will
involve the central character making crucial and perhaps unlikely decisions
at the right moment. If the player decides to have tea outside and not to
go into those ancient caves after all, the result is not "A Passage to
India". (A book, incidentally, which E. M. Forster published in 1924, and
on which British copyright will expire in 2020.)

Pastiche is legally safer and usually works better in any case: steal a
milieu rather than a plot. In this (indeed, perhaps only this) respect,
McCaffrey's works are superior to Forster's: then again, Chaucer or Rabelais
have more to offer than either, and with no executors waiting to pounce.

--- Magic and Mythology ---

Whether or not there is "magic" (and it might not be called such, for
example in the case of science fiction) there is always myth. This is the
imaginary fabric of the game: landscape is more than just buildings and
trees.

The commonest `mythology' is what might be called `lazy medieval', where
anything prior to the invention of gunpowder goes, all at once, everything
from Greek gods to the longbow (a span of about two thousand years). In
fact, anything an average reader might think of as `old world' will do, the
Western idea of antiquity being a huge collage. This was so even in the
time of the Renaissance:

One is tempted to call the medieval habit of life mathematical
or to compare it with a gigantic game where everything is
included and every act is conducted under the most complicated
system of rules. Ultimately the game grew over-complicated
and was too much for people...

(In some ways, the historical counterparts of the characters in a medieval
adventure game saw the real world as if it were such a game.)

That last quotation was from E. M. W. Tillyard's book `The Elizabethan
World Picture', exactly the stuff of which game-settings are made.
Tillyard's main claim is that

The Elizabethans pictured the universal order under three main
forms: a chain, a series of corresponding planes and a dance.

Throw all that together with Hampton Court, boats on the Thames by night
and an expedition or two to the Azores and the game is afoot.

Most games do have "magic", some way of allowing the player to transform
her surroundings in a wholly unexpected and dramatic way which would not be
possible in real life. There are two dangers: firstly, many systems have
already been tried - and naturally a designer wants to find a new one.
Sometimes spells take place in the mind (the `Enchanter' trilogy), sometimes
with the aid of certain objects (`Curses'); sometimes half-way between the
two (Level 9's `Magik' trilogy).

Secondly, magic is surreal almost by definition and surrealism is dangerous
(unless it is deliberate, something only really attempted once, in `Nord 'n'
Burt Couldn't Make Head Nor Tail Of It'). The T-Removing Machine of
`Leather Goddesses of Phobos' (which can, for instance, transform a rabbit
to a rabbi) is a stroke of genius but a risky one. The adventure game is
centred on words and descriptions, but the world it incarnates is supposed
to be solid and real, surely, and not dependent on how it is described? To
prevent magic from derailing the illusion, it must have a coherent
rationale. This is perhaps the definition of mystic religion, and there are
plenty around to steal from.

What can magic do? Chambers English Dictionary defines it as

the art of producing marvellous results by compelling the
aid of spirits, or by using the secret forces of nature, such as
the power supposed to reside in certain objects as `givers of life':
enchantment: sorcery: art of producing illusions by legerdemain:
a secret or mysterious power over the imagination or will.

It is now a commonplace that this is really the same as unexplained
science, that a tricorder and a rusty iron rod with a star on the end are
basically the same myth. As C. S. Lewis, in `The Abolition of Man',
defined it,

For magic and applied science alike the problem is how to subdue
reality to the wishes of man.

Role-playing games tend to have elaborately worked-out theories about magic,
but these aren't always suitable. Here are two (slightly simplified)
excerpts from the spell book of `Tunnels and Trolls', which has my favourite
magic system:

Magic Fangs Change a belt or staff into a small poisonous
serpent. Cannot "communicate" with mage, but does obey mage's
commands. Lasts as long as mage puts strength into it at time
of creation.

Bog and Mire Converts rock to mud or quicksand for 2 turns,
up to 1000 cubic feet. Can adjust dimensions as required, but must
be a regular geometric solid.

Magic Fangs is an ideal spell for an adventure game, whereas Bog and Mire
is a nightmare to implement and impossible for the player to describe.

If there are spells (or things which come down to spells, such as alien
artifacts) then each should be used at least twice in the game, preferably
in different contexts, and some many times. But, and this is a big `but',
the majority of puzzles should be soluble by hand - or else the player will
start to feel that it would save a good deal of time and effort just to
find the "win game" spell and be done with it. In similar vein, using
an "open even locked or enchanted object" spell on a shut door is less
satisfying than casting a "cause to rust" spell on its hinges, or
something even more indirect.

Magic has to be part of the mythology of a game to work. Alien artifacts
would only make sense found on, say, an adrift alien spaceship, and the
player will certainly expect to have more about the `aliens' revealed in
play. Even the traditional magic word "xyzzy", written on the cave's
walls, is in keeping with the centuries of initials carved by the first
explorers of the Mammoth cave.

--- Research ---

Design usually begins with, and is periodically interrupted by, research.
This can be the most entertaining part of the project and is certainly the
most rewarding, not so much because factual accuracy matters (it doesn't)
but because it continually sparks off ideas.

A decent town library, for instance, contains thousands of maps of one kind
or another if one knows where to look: deck plans of Napoleonic warships,
small-scale contour maps of mountain passes, city plans of New York and
ancient Thebes, the layout of the U.S. Congress. There will be photographs
of every conceivable kind of terrain, of most species of animals and plants;
cutaway drawings of a 747 airliner and a domestic fridge; shelves full of
the collected paintings of every great artist from the Renaissance onwards.
Data is available on the melting point of tungsten, the distances and
spectral types of the nearest two dozen stars, journey times by rail and
road across France.

History crowds with fugitive tales. Finding an eyewitness account is
always a pleasure: for instance,

As we ranged by Gratiosa, on the tenth of September, about twelve a
clocke at night, we saw a large and perfect Rainbow by the Moone light,
in the bignesse and forme of all other Rainbows, but in colour much
differing, for it was more whitish, but chiefly inclining to the colour
of the flame of fire.

(Described by the ordinary seaman Arthur Gorges aboard Sir Walter
Raleigh's expedition of 1597.)

Then, too, useful raw materials come to hand. A book about Tibet may
mention, in passing, the way to make tea with a charcoal-burning samovar.
So, why not a tea-making puzzle somewhere? It doesn't matter that there
is as yet no plot to fit it into: if it's in keeping with the genre, it
will fit somewhere.

Research also usefully fills in gaps. Suppose a fire station is to be
created: what are the rooms? A garage, a lounge, a room full of uniforms,
yes: but what else? Here is Stu Galley, on writing the Chandleresque murder
mystery `Witness':

Soon my office bookshelf had an old Sears catalogue and a pictorial
history of advertising (to help me furnish the house and clothe the
characters), the "Dictionary of American Slang" (to add colour to the
text) and a 1937 desk encyclopaedia (to weed out anachronisms).

The result (overdone but hugely amusing) is that one proceeds up the
peastone drive of the Linder house to meet (for instance) Monica, who has
dark waved hair and wears a navy Rayon blouse, tan slacks and tan pumps with
Cuban heels. She then treats you like a masher who just gave her a whistle.

On the other hand, the peril of research is that it piles up fact without
end. It is essential to condense. Here Brian Moriarty, on research for
`Trinity', which went as far as geological surveys:

The first thing I did was sit down and make a map of the Trinity site. It
was changed about 50 times trying to simplify it and get it down from over
100 rooms to the 40 or so rooms that now comprise it. It was a lot more
accurate and very detailed, but a lot of that detail was totally useless.

There is no need to implement ten side-chapels when coding, say, Chartres
cathedral, merely because the real one has ten.

--- The Overture ---

At this point the designer has a few photocopied sheets, some scribbled
ideas and perhaps even a little code - the implementation of a samovar, for
instance - but nothing else. (There's no harm in sketching details before
having the whole design worked out: painters often do. Besides, it can be
very disspiriting looking at a huge paper plan of which nothing whatever is
yet programmed.) It is time for a plot.

Plot begins with the opening message, rather the way an episode of Star Trek
begins before the credits come up. Write it now. It ought to be striking
and concise (not an effort to sit through, like the title page of `Beyond
Zork'). By and large Infocom were good at this, and a fine example is Brian
Moriarty's overture to `Trinity':

Sharp words between the superpowers. Tanks in East Berlin. And now,
reports the BBC, rumors of a satellite blackout. It's enough to spoil your
continental breakfast.

But the world will have to wait. This is the last day of your $599 London
Getaway Package, and you're determined to soak up as much of that
authentic English ambience as you can. So you've left the tour bus behind,
ditched the camera and escaped to Hyde Park for a contemplative stroll
through the Kensington Gardens.

Already you know: who you are (an unadventurous American tourist, of no
consequence to the world); exactly where you are (Kensington Gardens, Hyde
Park, London, England); and what is going on (bad news, I'm afraid: World
War III is about to break out). Notice the careful details: mention of the
BBC, of continental breakfasts, of the camera and the tour bus. In style,
the opening of `Trinity' is escapism from a disastrous world out of control:
notice the way the first paragraph is in tense, blunt, headline-like
sentences, whereas the second is much more relaxed. So a good deal has been
achieved in two paragraphs.

The point about telling the player who to be is more subtle than first
appears. "What should you, the detective, do now?" asks `Witness'
pointedly on the first turn. Gender is an especially awkward point. In
some games the player's character is exactly prescribed: in `Plundered
Hearts' you are a particular girl whisked away by pirates, and have to act
in character. Other games take the attitude that anyone who turns up can
play, as themselves, with whatever gender or attitudes (and in a dull
enough game with no other characters, these don't even matter).

--- An Aim in Life ---

Once the player knows who he is, what is he to do? Even if you don't want
him to know everything yet, he has to have some initial task.

Games vary in how much they reveal at once. `Trinity' is foreboding but
really only tells the player to go for a walk. `Curses' gives the player an
initial task which appears easy - look through some attics for a tourist map
of Paris - the significance of which is only gradually revealed, in stages,
as the game proceeds. (Not everyone likes this, and some players have told
me it took them a while to motivate themselves because of it, but on balance
I disagree.) Whereas even the best of "magic realm" type games (such as
`Enchanter') tends to begin with something like:

You, a novice Enchanter with but a few simple spells in your Book,
must seek out Krill, explore the Castle he has overthrown, and learn
his secrets. Only then may his vast evil...

A play is nowadays sometimes said to be `a journey for the main character',
and there's something in this. There's a tendency in most games to make the
protagonist terribly, terribly important, albeit initially ordinary - the
player sits down as Clark Kent, and by the time the prologue has ended is
wearing Superman's gown. Presumably the idea is that it's more fun being
Superman than Kent (though I'm not so sure about this).

Anyway, the most common plots boil down to saving the world, by exploring
until eventually you vanquish something (`Lurking Horror' again, for
instance) or collecting some number of objects hidden in awkward places
(`Leather Goddesses' again, say). The latter can get very hackneyed (find
the nine magic spoons of Zenda to reunite the Kingdom...), so much so that
it becomes a bit of a joke (`Hollywood Hijinx') but still it isn't a bad
idea, because it enables many different problems to be open at once.

As an aside on saving the world, with which I suspect many fans of `Dr Who'
would agree: it's more interesting and dramatic to save a small number of
people (the mud-slide will wipe out the whole village!) than the whole
impersonal world (but Doctor, the instability could blow up every star in
the universe!).

In the same way, a game which involves really fleshed-out characters other
than the player will involve them in the plot and the player's motives,
which obviously opens many more possibilities.

The ultimate aim at this stage is to be able to write a one-page synopsis of
what will happen in the full game (as is done when pitching a film, and as
Infocom did internally, according to several sources): and this ought to
have a clear structure.

--- Size and Density ---

Once upon a time, the sole measure of quality in advertisements for
adventure games was the number of rooms. Even quite small programs would
have 200 rooms, which meant only minimal room descriptions and simple
puzzles which were scattered thinly over the map. (The Level 9 game
`Snowball' - perhaps their best, and now perhaps almost lost - cheekily
advertised itself as having 2,000,000 rooms... though 1,999,800 of them
were quite similar to each other.)

Nowadays a healthier principle has been adopted: that (barring a few
junctions and corridors) there should be something out of the ordinary about
every room.

One reason for the quality of the Infocom games is that their roots were
in a format which enforced a high density. In their formative years there
was an absolute ceiling of 255 objects, which needs to cover rooms, objects
and many other things (e.g., compass directions and spells). Some writers
were slacker than others (Steve Meretzky, for example) but there simply
wasn't room for great boring stretches. An object limit can be a blessing as
well as a curse. (And the same applies to some extent to the Scott Adams
games, whose format obliged extreme economy on number of rooms and objects
but coded rules and what we would now call daemons so efficiently that the
resulting games tend to have very tightly interlinked puzzles and objects,
full of side-effects and multiple uses.)

Let us consider the earlier Infocom format as an example of setting a
budget. Many `objects' are not portable: walls, tapestries, thrones,
control panels, coal-grinding machines. As a rule of thumb, four objects to
one room is to be expected: so we might allocate, say, 60 rooms. Of the
remaining 200 objects, one can expect 15-20 to be used up by the game's
administration (e.g., in an Infocom game these might be a "Darkness" room,
12 compass directions, the player and so on). Another 50-75 or so objects
may be portable but the largest number, at least 100, will be furniture.

Similarly there used to be room for at most 150K of text. This is the
equivalent of about a quarter of a modern novel, or, put another way, enough
bytes to store a very substantial book of poetry. Roughly, it meant
spending 2K of text (about 350 words) in each room - ten times the level of
detail of the original mainframe Adventure.

Most adventure-compilers are fairly flexible about resources nowadays
(certainly TADS and Inform are), and this means that a rigorous budget is
not absolutely needed. Nonetheless, a plan can be helpful and can help to
keep a game in proportion. If a game of 60 rooms is intended, how will they
be divided up among the stages of the game? Is the plan too ambitious, or
too meek?

--- The Prologue ---

Just as most Hollywood films are three-act plays (following a convention
abandoned decades ago by the theatre), so there is a conventional game
structure.

Most games have a prologue, a middle game and an end game, usually quite
closed off from each other. Once one of these phases has been left, it
generally cannot be returned to (though there is sometimes a reprise at the
end, or a premonition at the beginning): the player is always going `further
up, and further in', like the children entering Narnia.

The prologue has two vital duties. Firstly, it has to establish an
atmosphere, and give out a little background information.

To this end the original `Adventure' had the above-ground landscape; the
fact that it was there gave a much greater sense of claustrophobia and depth
to the underground bulk of the game. Similarly, most games begin with
something relatively mundane (the guild-house in `Sorcerer', Kensington
Gardens in `Trinity') or else they include the exotic with dream-sequences
(`The Lurking Horror'). Seldom is a player dropped in at the deep end (as
`Plundered Hearts', which splendidly begins amid a sea battle).

The other duty is to attract a player enough to make her carry on playing.
It's worth imagining that the player is only toying with the game at this
stage, and isn't drawing a map or being at all careful. If the prologue is
big, the player will quickly get lost and give up. If it is too hard, then
many players simply won't reach the middle game.

Perhaps eight to ten rooms is the largest a prologue ought to be, and even
then it should have a simple (easily remembered) map layout. The player can
pick up a few useful items - the traditional bottle, lamp and key, whatever
they may be in this game - and set out on the journey by one means or
another.

--- The Middle Game ---

The middle game is both the largest and the one which least needs detailed
planning in advance, oddly enough, because it is the one which comes nearest
to being a collection of puzzles.

There may be 50 or so locations in the middle game. How are they to be
divided up? Will there be one huge landscape, or will it divide into zones?
Here, designers often try to impose some coherency by making symmetrical
patterns: areas corresponding to the four winds, or the twelve signs of the
Zodiac, for instance. Gaining access to these areas, one by one, provides
a sequence of problems and rewards for the player.

Perhaps the fundamental question is: wide or narrow? How much will be
visible at once?

Some games, such as the original Adventure, are very wide: there are thirty or
so puzzles, all easily available, none leading to each other. Others, such as
`Spellbreaker', are very narrow: a long sequence of puzzles, each of which
leads only to a chance to solve the next.

A compromise is probably best. Wide games are not very interesting (and
annoyingly unrewarding since one knows that a problem solved cannot
transform the landscape), while narrow ones can in a way be easy: if only
one puzzle is available at a time, the player will just concentrate on it,
and will not be held up by trying to use objects which are provided for
different puzzles.

Just as the number of locations can be divided into rough classes at this
stage, so can the number of (portable) objects. In most games, there are
a few families of objects: the cubes and scrolls in `Spellbreaker', the rods
and Tarot cards in `Curses' and so on. These are to be scattered about the
map, of course, and found one by one by a player who will come to value them
highly. The really important rules of the game to work out at this stage
are those to do with these families of objects. What are they for? Is
there a special way to use them? And these are the first puzzles to
implement.

So a first-draft design of the middle game may just consist of a rough
sketch of a map divided into zones, with an idea for some event or meeting
to take place in each, together with some general ideas for objects.
Slotting actual puzzles in can come later.

--- The End Game ---

Some end games are small (`The Lurking Horror' or `Sorcerer' for instance),
others huge (the master game in `Zork', now called `Zork III'). Almost all
games have one.

End games serve two purposes. Firstly they give the player a sense of being
near to success, and can be used to culminate the plot, to reveal the game's
secrets. This is obvious enough. They also serve to stop the final stage
of the game from being too hard.

As a designer, you don't usually want the last step to be too difficult; you
want to give the player the satisfaction of finishing, as a reward for
having got through the game. (But of course you want to make him work for
it.) An end game helps by narrowing the game, so that only a few rooms and
objects are accessible.

In a novelist's last chapter, ends are always tied up (suspiciously neatly
compared with real life - Jane Austen being a particular offender, though
always in the interests of humour). The characters are all sent off with
their fates worked out and issues which cropped up from time to time are
settled. So should the end game be. Looking back, as if you were a winning
player, do you understand why everything that happened did? (Of course,
some questions will forever remain dark. Who did kill the chauffeur in `The
Big Sleep'?)

Most stories have a decisive end. The old Gothic manor house burns down,
the alien invaders are poisoned, the evil warlord is deposed. If the end
game lacks such an event, perhaps it is insufficiently final.

Above all, what happens to the player's character, when the adventure ends?

The final message is also an important one to write carefully, and, like the
overture, the coda should be brief. To quote examples here would only spoil
their games. But a good rule of thumb, as any film screenplay writer will
testify, seems to be to make the two scenes which open and close the story
"book-ends" for each other: in some way symmetrical and matching.

5 ...At War With a Crossword
=============================

Forest sways,
rocks press heavily,
roots grip,
tree-trunk close to tree-trunk.
Wave upon wave breaks, foaming,
deepest cavern provides shelter.

-- Goethe, Faust

His building is a palace without design; the passages are tortuous, the
rooms disfigured with senseless gilding, ill-ventilated, and horribly
crowded with knick-knacks. But the knick-knacks are very curious, very
strange; and who will say at what point strangeness begins to turn into
beauty? ... At every moment we are reminded of something in the far past
or something still to come. What is at hand may be dull; but we never
lose faith in the richness of the collection as a whole... We are
`pleased, like travellers, with seeing more', and we are not always
disappointed.

-- C.S. Lewis (of Martianus), The Allegory of Love

From the large to the small. The layout is sketched out; a rough synopsis
is written down; but none of the action of the game is yet clear. In short,
there are no puzzles. What are they to be? How will they link together?
This section runs through the possibilities but is full of question marks,
the intention being more to prod the designer about the consequences of
decisions than to suggest solutions.

--- Puzzles ---

Puzzles ought not to be simply a matter of typing one well-chosen line. The
hallmark of a good game is not to get any points for picking up an easily
available key and unlocking a door with it. This sort of low-level
achievement - wearing an overcoat found lying around, for instance - should
count for little. A memorable puzzle will need several different ideas to
solve (the Babel fish dispenser in `The Hitch-hiker's Guide to the Galaxy',
for instance). My personal rule with puzzles is never to allow one which I
can code up in less than five minutes.

Nonetheless, a good game mixes the easy with the hard, especially early on.
The player should be able to score a few points (not many) on the very first
half-hearted attempt. (Fortunately, most authors' guesses about
which puzzles are easy and which hard are hopelessly wrong anyway. It
always amuses me, for instance, how late on players generally find the
golden key in `Curses': whereas they often puzzle out the slide-projector
far quicker than I intended.)

There are three big pitfalls in making puzzles:

The "Get-X-Use-X" syndrome
--------------------------
Here, the whole game involves wandering about picking up bicycle pumps and
then looking for a bicycle: picking up pins and looking for balloons to
burst, and so on. Every puzzle needs one object. As soon as it has been
used it can be dropped, for it surely will not be required again.

The "What's-The-Verb" syndrome
------------------------------
So you have your bicycle pump and bicycle: "use pump" doesn't work, "pump
bike" doesn't work... only "inflate tyre" does. There are games where this
linguistic challenge is most of the work for the player. An especially
tricky form of this problem is that in most games "examine", "search" and
"look inside" are different actions: it is easy to code a hidden treasure,
say, so that only one of these produces the treasure.

The "In-Joke" syndrome
----------------------
In which the player has to play a parody of your company office, high school
class, etc., or finds an entirely inexplicable object (say, a coat with a
mysterious slogan on) which is only there because your sister has a very
funny one like it, or meets endless bizarre characters modelled on your best
friends and enemies.

Then again, a few puzzles will always be in the get-x-use-x style, and that
does no harm: while pursuing tolerance of verbs to extremes leads to
everything being "moved", not "pushed", "pulled", "rotated" and so on:
and what artist has not immortalised his madder friends at one time or
another?

Variety in style is very important, but logic is paramount. Often the
designer begins knowing only that in a given place, the player is to put out
a fire. How is this to be done? Will the means be found nearby? Will the
fire have other consequences? Will there be partial solutions to the
problem, which put the fire out but leave vital equipment damaged? If the
player takes a long time not solving the problem, will the place burn down
so that the game becomes unwinnable? Will this be obvious, if so?

--- Machinery ---

In some ways the easiest puzzles to write sensibly are machines, which need
to be manipulated: levers to pull, switches to press, cogs to turn, ropes to
pull. They need not make conversation. They often require tools, which
brings in objects. They can transform things in a semi-magical way (coal to
diamonds being the cliche) and can plausibly do almost anything if
sufficiently mysterious and strange: time travel, for instance.

They can also connect together different locations with machinery: chains,
swinging arms, chutes may run across the map, and help to glue it together.

A special kind of machine is the kind to be travelled in. Many Infocom
games have such a vehicle (for the ignoble reason that the code was already
in the `Zork I' kernel, but never mind) and cars, tractors, fork-lift trucks,
boats, hot-air balloons have all made appearances. The coding needs a
little care (for instance, not being able to drive upstairs, or through a
narrow crevice) but a whole range of new puzzles is made possible: petrol,
ignition keys, a car radio perhaps. And travelling in new ways adds to the
realism of the landscape, which thereby becomes more than a set of rules
about walking.

--- Keys and Doors ---

Almost invariably games close off sections of the map (temporarily) by
putting them behind locked doors, which the player can see and gnash her
teeth over, but cannot yet open. And almost every variation on this theme
has been tried: coded messages on the door, illusory defences, gate-keepers,
the key being in the lock on the wrong side, and so on. Still, the usual
thing is simply to find a key in some fairly remote place, bring it to the
door and open it.

If there are people just inside, do they react when the player knocks on the
door, or tries to break it down or ram it? If not, why not?

In some situations doors should be lockable (and open- and closeable) on
both sides. Though irritating to implement, this adds considerably to the
effect.

In a large game there may be several, perhaps five or six, keys of one kind
or another: it's essential not to make these too similar in appearance.
Some games have "master keys" which open several different locks in a
building, for instance, or "skeleton keys", or a magic spell to get around
this.

--- Air, Earth, Fire and Water ---

The elements all tangle up code but add to the illusion. Fire has many
useful properties - it makes light, it destroys things, it can cause
explosions and chemical reactions, it cooks food, it softens materials, it
can be passed from one object to another - but in the end it spreads,
whereas code doesn't. If the player is allowed to carry a naked flame
around (a burning torch, for instance), then suddenly the game needs to know
whether or not each item in the game (a curtain, a pot plant, a book) is
flammable. Even the classic matchbook of matches can make for grisly
implementation.

As in Robert Redford's film, so in the best game landscaping: a river runs
through it. But in any room where water is available, players will try
drinking, swimming, washing, diving. They will try to walk away with the
water. (And of course this applies to acid pools, natural oil pits and the
like.)

Liquids make poor objects, because they need to be carried in some container
yet can be poured from one to another, and because they are endlessly
divisible. "Some water" can easily be made into "some water" and "some
water". If there's more than one liquid in the game, can they be mixed?
Pouring liquid over something is likely to make a mess of it: yet why should
it be impossible? And so on.

The compromise solution is usually to have a bottle with a `capacity' of,
say, 5 units of water, which can be refilled in any room where there is
water (there is a flag for this, say) with 1 unit drunk at a time. The
player who tries to pour water over (most) things is simply admonished and
told not to.

Implementing swimming, or being underwater, is a different order of
difficulty again. What happens to the objects being held? Can a player
swim while wearing heavy clothes, or carrying many things? Is it possible
to dive?

Moreover, does the player run out of air? In many games there is some such
puzzle: a room where the air is poor, or open space, or underwater: and a
scuba mask or a space helmet is called for. One should not kill the player
at once when he enters such a hostile environment unprotected, since he will
probably not have had fair warning. Some games even implement gases:
helium, explosive hydrogen, laughing gas.

And so to earth. One of the oldest puzzles around is digging for buried
treasure. The shovel can be found in just about every traditional-style
game and a good many others which ought to know better besides. Of course
in real life one can dig very nearly anywhere outdoors: there's simply
little cause to. Games really can't afford to allow this. It's quite
difficult to think of a persuasive way of breaking the news to the player,
though.

Still, digging in some form makes a good puzzle: it artificially creates a
new location, or a new map connection, or a new container (the hole left
behind).

--- Animals and Plants ---

Vegetation fits into almost any landscape, and in most games plays some part
in it. This is good for variety, since by and large one deals with plants
differently from machines and people. One pulls the undergrowth away from
ruins, for instance, or picks flowers. Trees and creeping plants (wistaria
or ivy, for instance) ought to be climbable. The overgrown-schoolboy
element in players expects this sort of thing.

A plant which can be grown into a beanstalk is now, perhaps, rather a
cliche. So naturally no self-respecting author would write one.

Animals are even more useful, for several reasons: they move, they behave in
curious and obsessive ways: they have amusingly human characteristics, but
do not generally react to conversation and need not be particularly
surprised by the player doing something very shocking nearby, so they are
relatively easy to code: and they add a splash of colour. What would the
Garden of Eden have been without turtles, elephants, rabbits, leopards and
guinea pigs?

The classic, rather predictable puzzle with animals is solved by feeding
them some apposite food to make them obedient, then getting them to do
something. Good games find something better. (Significantly, the animal
puzzles in `Adventure' - the bear, the bird and the snake - are better
characterised than most of those in later games.)

--- People ---

So dawns the sixth day of creation: we have the mountains, rivers, plants
and animals, but as yet no people.

The trap with "people" puzzles should perhaps be called the Get-X-Give-X
syndrome. People are a little more complicated than that. The nightmare of
coding real characters is illustrated well by one of Dave Lebling's example
bugs from "Suspect":

&gt; SHOW CORPSE TO MICHAEL
Michael doesn't appear interested.

Of course, Michael is only Veronica's husband; why would he be
interested?

People are the hardest elements of any game to code up. They can take five
times the amount of code attached to even a complicated room. They have to:
-- react to events (as above!);
-- make conversation of some kind or another;
-- understand and sometimes obey instructions ("robot, go south");
-- wander around the map in a way consistent with the way the player does;
-- have some attitude to the player, and some personality.

They often have possessions of their own and can expect to be attacked, have
things given to or thrown at them, or even seduced by a desperate player.
All this requires code. Good player characters also do surprising things
from time to time, in a random way. In some games they have a vast stock of
knowledge and replies. The woman selling bread-crumbs at the very beginning
of `Trinity' (who does not play a huge role in the game) can say over 50
different things.

Most conversation is added to the code in play-testing. If the play-testers
complain that "ask waiter about apples" does nothing, then add some reply,
even if not a terribly useful one.

Good player-characters may come and go, turning up at different times during
the game: they are part of the larger plot. But there is also room for the
humble door-keeper who has nothing to do but check passes.

--- Mazes... ---

Almost every game contains a maze. Nothing nowadays will ever equal the
immortal

You are in a maze of twisty little passages, all alike.

But now we are all jaded. A maze should offer some twist which hasn't
been done before (the ones in `Enchanter' and `Sorcerer' being fine
examples).

The point is not to make it hard and boring. The standard maze solution is
to litter the rooms with objects in order to make the rooms distinguishable.
It's easy enough to obstruct this, the thief in `Zork I' being about the
wittiest way of doing so. But that only makes a maze tediously difficult.

Instead there should be an elegant quick solution: for instance a guide who
needs to be bribed, or fluorescent arrows painted on the floor which can
only be seen in darkness (plus a hint about darkness, of course).

There is much to be said for David Baggett's recent answer to the question
"How do I make my maze so that it doesn't have the standard solution?":
omit it altogether.

Above all, don't design a maze which appears to be a standard impossibly
hard one: even if it isn't, a player may lose heart and give up rather than
go to the trouble of mapping it.

--- ...and Other Old Cliches ---

There are a few games which do not have "light source" puzzles, but it's
hard to think of many. The two standards reduce to:
-- the player's lamp slowly runs down and will need new oil at least once;
-- a dark room, full of treasure, can apparently only be reached through
a very narrow passage, one which cannot be passed by a player carrying
anything (including the lamp).

Most games contain both, and perhaps most always will, but variations are
welcome. (There is a superbly clever one in `Zork III', for instance,
perhaps the best thing in it.)

Similarly, unless there are very few portable objects, it becomes ridiculous
that a player can carry hundreds of bulky and fiddly things around all the
time: so most games impose a limit on how much can be carried, by convention
four (i.e., because that's what (some versions of) `Adventure' did). It is
bad form to set puzzles making life difficult because the limit is four and
not five (after all, in case of emergency, a player could always carry
something else). Of course the norm is to provide a bag for carrying
things.

Sophisticated games also quietly work out the total weight being carried.
(One of the Infocom games contains a marvellously heavy red herring which
can be carried anywhere, but is terribly exhausting to move.)

Mention of exhaustion raises the question of the player's state of health.
Some games take a quite role-playing-style view of this, with (perhaps
hidden) attributes of "strength" and "constitution". The player grows
weary and needs food, tired and needs sleep, wounded and needs recuperation.
A puzzle which really exploits this would be difficult to make fair.
Consequently all rules like this make nuisance for the player (who will be
obliged to go back to the orchard for more fruit every few dozen turns, that
kind of thing) and should be watched carefully.

--- Rewards and Penalties ---

There are two kinds of reward which need to be given to a player in return
for solving a puzzle. One is obvious: the game advances a little. But the
player at the keyboard needs a reward as well, that the game should offer
something new to look at. In the old days, when a puzzle was solved, the
player simply got a bar of gold and had one less puzzle to solve.

Much better is to offer the player some new rooms and objects to play
with, as this is a real incentive. If no new rooms are on offer, at least
the "treasure" objects can be made interesting, like the spells in the
`Enchanter' trilogy or the cubes in `Spellbreaker'.

In olden days, games killed the player in some way for almost every wrong
guess (or altered the state of the game so that it had become unwinnable).
This was annoying and meant that virtually all players were so paranoid
as to save the game before, say, picking up any new object. Nowadays
it is thought polite not to kill the player without due warning, and to
make smaller mistakes recoverable-from. A good alternative to the death
sentence is exile (i.e., in some way moving the player somewhere
inconvenient but returnable-from).

--- Writing Room Descriptions ---

First, a warning: it is tempting, when beginning to code, to give rooms
"temporary" descriptions ("Slab room." "Cloister."), and leave the
writing for later. There is no more depressing point than when facing a
pile of 50 room descriptions to write, all at once, and feeling that one's
enthusiasm has altogether gone. (The same warning applies to making an
over-detailed design before doing any coding.) Besides, when testing the
rooms concerned, one has no feeling of what the game will look like except
tatty, and this is also depressing. Also, writing room descriptions forces
the author to think about what the room is ultimately for, which is no bad
thing. So write a few at a time, as coding goes on, but write them
properly: and edit later if necessary (it will be).

Size doesn't matter. It is all too easy to write a huge room description,
rambling with irrelevant details: there are usually one to three essentials
to get across, and the rest should be cut. (This is admittedly a hard-line
view on my part, and opinions vary.)

But even the most tedious junctions deserve description, and description is
more than a list of exits. Here is `Adventure' at its most graceful:

You're in a large room carved out of sedimentary rock. The floor and
walls are littered with bits of shells embedded in the stone. A shallow
passage proceeds downward, and a somewhat steeper one leads up. A low
hands and knees passage enters from the south.

You are walking along a gently sloping north/south passage lined with
oddly shaped limestone formations.

Note the geology, the slight unevenness of the ground and the variation in
the size of the tunnels. Even if nothing happens here, these are real
places.

Flippant, joky room descriptions are best avoided if they will be often
revisited. About once in a game an author can get away with:

Observation Room
Calvin Coolidge once described windows as "rectangles of glass." If so,
he may have been thinking about the window which fills the western wall
of this room. A tiny closet lies to the north. A sign is posted next to
the stairs which lead both upwards and downwards.

a characteristic piece of Steve Meretzky from `Leather Goddesses of Phobos',
which demonstrates the lengths one has to go to when faced with a
relentlessly ordinary junction-with-window. The sentence which the whole
description has been written to avoid is "You can go up, down or north."

Room descriptions are obliged to mention the obvious exits - and it is
certainly poor form to fail to mention a particular one unless there is good
reason - but there are ways to avoid what can be a tiresomely repetitive
business. For instance,

Dark Cave
Little light seeps into this muddy, bone-scattered cave and already
you long for fresh air. Strange bubbles, pulsing and shifting as if
alive, hang upon the rock at crazy, irregular angles.

Black crabs scuttle about your feet.

&gt; SOUTH
The only exit is back out north to the sea-shore.

In other words, the "You can't go that way" message is tailored to each
individual room.

Avoiding repetition is well-nigh impossible, and experienced players will
know all the various formulae by heart: "You're in", "You are in", "This
is", "You have come to" and so forth. I usually prefer impersonal room
descriptions (not mentioning "you" unless to say something other than the
obvious fact of being present).

As in all writing, vocabulary counts (another respect in which Scott Adams'
games, despite awful grammar, score). If there is a tree, what kind is it,
oak, juniper, hawthorn, ash? Then, too, don't make all room descriptions
static, and try to invoke more than just sight at times: smell, touch and
sound are powerfully evocative. Purity and corruption, movement and
stillness, light and dark have obsessed writers through the ages.

Above all, avoid the plainness of:

You are in the Great Hall. You can go north to the Minstrel's Gallery,
east to the fireplace and down to the kitchens.

There is a sword here.

So much for bad room descriptions. The following example (which I have not
invented) is something much more dangerous, the mediocre room description:

Whirlpool Room
You are in a magnificent cavern with a rushing stream, which cascades
over a sparkling waterfall into a roaring whirlpool which disappears
through a hole in the floor. Passages exit to the south and west.

...seems a decent enough try. But no novelist would write such sentences.
Each important noun - "cavern", "stream", "waterfall", "whirlpool" - has
its own adjective - "magnificent", "rushing", "sparkling", "roaring".
The two "which" clauses in a row are a little unhappy. "Cascades" is
good, but does a stream cascade "over" a waterfall? Does a whirlpool
itself disappear? The "hole in the floor" seems incongruous. Surely it
must be underwater, indeed deep underwater?

Come to that, the geography could be better used, which would also help to
place the whirlpool within the cave (in the middle? on one edge?). And why
"Whirlpool Room", which sounds like part of a health club? As a second
draft, then, following the original:

Whirlpool Ledge
The path runs a quarter-circle from south to west around a broken ledge
of this funnel cavern. A waterfall drops out of the darkness, catching
the lamplight as it cascades into the basin. Sinister, rapid currents
whip into a roaring whirlpool below.

Even so: there is nothing man-made, nothing alive, no colour and besides it
seems to miss the essential feature of all the mountain water-caves I've
ever been to, so let us add a second paragraph (with a line break, which is
much easier on the eye):

Blue-green algae hangs in clusters from the old guard-railing, which has
almost rusted clean through in the frigid, soaking air.

The algae and the guard-rail offer distinct possibilities of a puzzle or
two... Perhaps there are frogs who could eat the algae; perhaps the player
might find a use for iron oxide, and could scrape rust from the railing.
(Herbalists probably used to use rust for something, and an encyclopaedia or
a chemistry text book might know.) Certainly the railing should break if a
rope is tied to it. Is it safe to dive in? Does the water have a hypnotic
effect on someone who stares into it? Is there anything dry which would
become damp if the player brought it through here? Might there be a second
ledge higher up where the stream falls into the cave? - And so a location
is made.

--- The Map ---

Puzzles and objects are inextricably linked to the map, which means that the
final state of the map only gradually emerges and the author should expect
to have to keep changing it to get it right - rather than to devise an
enormous empty landscape at first and then fill it with material.

Back to atmosphere, then, because throughout it's vital that the map should
be continuous. The mark of a poor game is a map like:

Glacier
|
Dungeon --- Oriental Room --- Fire Station
(fish) (megaphone) (tulips)
|
Cheese Room

in which nothing relates to anything else, so that the game ends up with no
overall geography at all. Much more believable is something like:

Snowy Mountainside
\
Carved Tunnel
|
Oriental Room --- Jade Passage --- Fire Dragon
(buddha) (bonsai tree) Room
|
Blossom Room

The geography should also extend to a larger scale: the mountainside
should run across the map in both directions. If there is a stream
passing through a given location, what happens to it? And so on. Maps
of real mountain ranges and real cave systems, invariably more convoluted
and narrow than in fiction, can be quite helpful when trying to work
this out.

A vexed question is just how much land occupies a single location. Usually
a location represents a `room', perhaps ten yards across at the most.
Really large underground chambers - the legendary "Hall of Mists" in
Adventure, the barge chamber in `Infidel' - are usually implemented with
several locations, something like:

This does give some impression of space but it can also waste locations in a
quite dull way, unless there are genuinely different things at some of the
corners: a bust of George III, perhaps, a harpsichord.

On the other hand, in some stretches, drawing the map leaves one with the
same frustration as the set-designer for a Wagnerian opera: everything is
set outdoors, indistinct and without edges. Sometimes an entire meadow, or
valley, might be one single location, but then its description will have to
be written carefully to make this clear.

In designing a map, it adds to the interest to make a few connections in the
rarer compass directions (NE, NW, SE, SW) to prevent the player from a
feeling that the game has a square grid. There should also be a few
(possibly long) loops which can be walked around, to prevent endless
retracing of steps and to avoid the appearance of a bus service map,
half a dozen lines with only one exchange.

If the map is very large, or if a good deal of moving to-and-fro is called
for, there should be some rapid means of getting across it, such as the
magic words in `Adventure', or the cubes in `Spellbreaker'. This can be a
puzzle in itself - one that players do not have to solve, but will reward
them if they do.

--- Looking Back at the Shape ---

A useful exercise, towards the end of the design stage, is to draw out a
tree (or more accurately a lattice) of all the puzzles in a game. At the
top is a node representing the start of the game, and then lower nodes
represent solved puzzles. An arrow is drawn between two puzzles if one has
to be solved before the other can be. For instance, a simple portion might
look like:

Start
/ \
Find key Enter garage
\ /
Start car
|
Motorway

This is useful because it checks that the game is soluble (for example, if
the ignition key had been kept in a phone box on the motorway, it wouldn't
have been) and also because it shows the overall structure of the game.
Ask:
-- Do large parts of the game depend on one difficult puzzle?
-- How many steps does a typical problem need?
-- How wide is the game at any given time?

Bottlenecks should be avoided unless they are reasonably guessable: otherwise
many players will simply get no further. Unless, of course, they are
intended for exactly that, to divide an area of the game into `earlier' and
`later'.

Just as some puzzles should have more than one solution, some objects should
have more than one purpose. In bad old games, players automatically threw
away everything as soon as they'd used them. In better designed games,
obviously useful things (like the crowbar and the gloves in `Lurking
Horror') should be hung on to by the player throughout.

A final word on shape: one of the most annoying things for players is to
find, at the extreme end of the game (in the master game, perhaps) that
a few otherwise useless objects ought to have been brought along, but that
it is now too late. The player should not be thinking that the reason for
being stuck on the master game is that something very obscure should have
been done 500 turns before.

6 Varnish and Veneer
=====================

So you have a game: the wood is rough and splintered, but it's recognisably
a game. There's still a good month's work to do (and several centuries'
worth of debugging), though it is easier work than before and feels more
rewarding.

--- Scoring ---

The traditional way to score an adventure game is to give a points score out
of some large and pleasing number (say, 400) and a rank. There are usually
ten to fifteen ranks. A genuine example (which shall remain nameless):

Beginner (0), Amateur Adventurer (40), Novice Adventurer (80), Junior
Adventurer (160), Adventurer (240), Master (320), Wizard (360),
Master Adventurer (400)

in which, although ranks correspond to round numbers, still they have
perhaps been rigged to fit the game. Another amusing touch is that ranks
tend to be named for the player's profession in the game - so, a musician
might begin as "Novice" and rise through "Second Violinist" to
"Conductor". One of the wittiest is in the detective game `Sherlock',
where the lowest rank - of zero achievement - is "Chief Superintendent
of Scotland Yard".

Among the questions to ask are: will every winner of the game necessarily
score exactly 400 out of 400? (This is very difficult to arrange if even
small acts are scored.) Will everyone entering the end game already have a
score of 360, and so have earned the title "Wizard"? Will the rank
"Amateur" correspond exactly to having got out of the prologue and into the
middle game?

So what deserves points? Clearly solving the major puzzles does. But do
the minor, only halfway-there-yet puzzles? Here, as ever, games vary
greatly. In `Zork III', the scoring is out of 7 and corresponds to seven
vital puzzles (though a score of 7 does not mean the game is over). In `The
Lurking Horror', 20 major puzzles are awarded 5 points each, making a
maximum of 100.

Alternatively, there is the complicated approach. Points are awarded in
twos and threes for small acts, and then in larger doses for treasures -
silver bars 5, gold amulets 10, platinum pendants 20. Treasures are scored
twice, once when found, once when removed to safety - to the trophy case in
`Zork I', or inside the packing case of Level 9's game `Dungeon' (no
relation to the port of `Zork' of the same name). Furthermore, 1 point is
awarded for each room visited for the first time, and 1 for never having
saved the game - a particularly evil trick.

In some games (such as `Acheton') score actually falls back when the player
is wasting time and nothing is being achieved: the player's mana gradually
fades. This annoys some players intensely (no bad thing, some might say).

Games used to have a "Last Lousy Point" by custom - a single point which
could only be won by doing something hugely unlikely, such as going to a
particular area of the Pirate's Maze and dropping a key. This custom,
happily, has fallen into disuse.

--- Wrong Guesses ---

For some puzzles, a perfectly good alternative solution will occur to
players. It's good style to code two or more solutions to the same puzzle,
if that doesn't upset the rest of the game. But even if it does, at least
a game should say something when a good guess is made. (Trying to cross the
volcano on the magic carpet in `Spellbreaker' is a case in point.)

For example, in `Curses' there are (at time of writing) six different ways
to open the child-proof medicine bottle. They are all quite hard to guess,
they are all logically reasonable and most players get one of them.

One reason why `Zork' held the player's attention so firmly (and why it took
about ten times the code size, despite being rather smaller than the
original mainframe `Adventure') was that it had a huge stock of usually
funny responses to reasonable things which might be tried.

My favourite funny response, which I can't resist reprinting here, is:

You are falling towards the ground, wind whipping around you.
&gt;east
Down seems more likely.

(`Spellbreaker'. Though I also recommend trying to take the sea serpent
in `Zork II'.) This is a good example because it's exactly the sort of
boring rule (can't move from the midair position) which most designers
usually want to code as fast as possible, and don't write with any
imagination.

Another form of wrong guess is in vocabulary. Unless exceptionally large, a
good game ought to have about a 1000-word vocabulary: too much less than
that and it is probably missing reasonable synonyms; too much more and it is
overdoing it. Remember too that players do not know at first what the
relevant and irrelevant objects in a room are. For instance:

Old Winery
This small cavity at the north end of the attic once housed all manner of
home-made wine paraphernalia, now lost and unlamented. Steps, provided
with a good strong banister-rail, lead down and to the west, and the
banister rail continues along a passage east.

This clearly mentions a banister, which (as it happens) plays no part in the
game, but merely reinforces the idea of an east-west passage including a
staircase which (as it happens) is partly for the use of a frail relative.
But the player may well try tieing thing to the rail, pulling at it and so
on. So the game knows "banister", "rail" and (not entirely logically, but
players are not entirely logical) "paraphernalia" as names of irrelevant
things. An attempt to toy with them results in the reply

That's not something you need to refer to in the course of this game.

which most players appreciate as fair, and is better than the parser
either being ignorant or, worse, pretending not to be.

A feature which some games go to a great deal of trouble to provide, but is
of arguable merit (so think I), is to name every room, so that "search
winery" would be understood (though of course it would do nothing almost
everywhere... and a player would have to try something similar everywhere on
the off chance). Some games would even provide "go to winery" from nearby
places. These are impressive features but need to be coded carefully not to
give the player information she may not yet have earned.

--- Hints and Prizes ---

A good game (unless written for a competition) will often contain a hints
service, as the Infocom games did in latter days. Most players will only
really badly be stuck about once in the course of a game (and they vary
widely in which puzzle to be really badly stuck on) and it is only fair
to rescue them. (If nothing else, this cuts down on the volume of email
cries for help which may arrive.) There are two ways to provide hints:
-- in the game itself, by having some sage old worthy to ask;
-- properly separated from the game, with a "hint" command which
offers one or more menus full of possible questions.

Of course, a hint should not be an explicit answer. The classic approach
is to offer a sequence of hints, each more helpful than the last, until
finally the solution is openly confessed. Perhaps surprisingly, not all
players like this, and some complain that it makes play too easy to be
challenging. It is difficult to construct a hints system in such a way that
it doesn't reveal later information (in its lists of questions to which
answers are provided, for instance): but worth it.

At the end of the game, when it has been won, is there anything else to be
said? In some games, there is. In its final incarnations (alas, not the
one included in the `Lost Treasures of Infocom' package), `Zork I' offered
winners access to the hints system at the RESTART, RESTORE or QUIT prompt.
`Curses' goes so far as to have a trivia quiz, really to tell the player
about some of the stranger things which can be done in the game. (If
nothing else, this is a good chance for the game's author to boast.)

--- User Interface, and all that jazz ---

No, not windows and pull-down menus, but the few meta-commands which go to
the game program and do not represent actions of the player's character in
the game. Of course,

SAVE, RESTORE, RESTART, QUIT

are essential. Games should also provide commands to allow the player to
choose whether room descriptions are abbreviated on second visits or not.
Other such options might be commands to control whether the game prints out
messages like

[Your score has just gone up by ten points.]

and commands to transcribe to the printer or to a file - these are
extremely useful when receiving comments from play-testers.

UNDO is difficult to code but worth it. In `Curses', UNDO can even restore
the player posthumously (though this is not advertised in the game: death,
where is thy sting?).

Abbreviations (especially "g" for again, "z" for wait, "x" for examine)
must now be considered essential.

Some games produce quotations or jokes from time to time in little windows
away from the main text of the game. Care is needed to avoid these
overlying vital text. It ought to possible to turn this feature off.

The author's only innovations in this line are to provide a "full score"
feature, which accounts exactly for where the player's score has come from
and lists achievements so far; to provide a choice of "inventory wide"
or "inventory tall", which is helpful for players on screens with few
lines; and to provide "objects" and "places"
commands:

&gt;places
You have visited: Attic and Old Furniture.

&gt;objects
Objects you have handled:
the crumpled piece of paper (held)
the electric torch (held)
the chocolate biscuit (held)
the bird whistle (in Old Furniture)
the gift-wrapped parcel (lost)

These features may or may not catch on.

--- Debugging and Testing ---

Every author will need a few "secret" debugging commands (still present in
several of the Infocom games, for instance) to transport the player across
the map, or get any object by remote control. Since debugging never ends,
it's never wise to remove these commands: you might instead protect them with
a password in released editions. (The Inform system gets around this by
providing a suite of debugging verbs which is only included if a particular
setting is made at compile-time.)

An unobvious but useful feature is a command to make the game non-random.
That is, if there is a doorway which randomly leads to one of three places,
then this command will make it predictable. This is essential when testing
the game against a transcript.

During design, it's helpful to keep such a script of commands which wins the
game from the start position. Ideally, your game ought to be able to accept
input from a file of commands as well as from the keyboard, so that this
script can be run automatically through.

This means that when it comes to adding a new feature towards the end, it is
easy to check whether or not it upsets features earlier on.

Bugs are usually easy to fix: they are mostly small oversights. Very few
take more than five minutes to fix. Especially common are:

-- slips of punctuation, spelling or grammar (for instance, "a orange");
-- rooms being dark when they ought to be light (this tends not to show
if the player habitually carries a lamp anyway), or not changing their
state of light/darkness when they should, as for instance when a
skylight opens or closes;
-- other object flags having been forgotten, such as a fish not being
flagged as edible;
-- map connections being very slightly out, e.g. west in one direction
and northeast in the other, by accident;
-- something which logically can only happen once, such as a window being
broken, actually being possible more than once, with strange consequences;
-- general messages being unfortunate in particular cases, such as "The ball
bounces on the ground and returns to your hand." in mid-air or while
wading through a ford;
-- small illogicalities: being able to swim with a suit of armour on, or
wave the coat you're wearing, or eat while wearing a gas mask;
-- parser accidents and misnamings.

Do not go into play-testing until the scoring system is worked out and
the game passes the entire transcript of the "winning" solution without
crashing or giving absurd replies.

--- Playtesting ---

The days of play-testing are harrowing. The first thing to do is to
get a few "friends" and make them play for a while. Look over their
shoulders, scribble furiously on a piece of paper, moan with despair and
frustration, but do not speak. Force yourself not to explain or defend,
whatever the provocation. Expect to have abuse heaped on you, and bear up
nobly under the strain. To quote Dave Lebling (on testing `Suspect', from
an article in the "New Zork Times"):

&gt; BARTENDER, GIVE ME A DRINK
"Sorry, I've been hired to mix drinks and that's all."

&gt; DANCE WITH ALICIA
Which Alicia do you mean, Alicia or the overcoat?

Veronica's body is slumped behind the desk, strangled with a lariat.
&gt; TALK TO VERONICA
Veronica's body is listening.

Little bugs, you know? Things no one would notice. At this point the
tester's job is fairly easy. The story is like a house of cards -- it
looks pretty solid but the slightest touch collapses it...

After a cleaning-up exercise (and there's still time to rethink and
redraft), give the game to a few brave beta-testers. Insist on reports in
writing or email, or some concrete form, and if you can persuade the testers
then try to get a series of reports, one at a time, rather than waiting a
month for an epic list of bugs. Keep in touch to make sure the testers are
not utterly stuck because a puzzle is impossible due to a bug, or due to it
just being far too hard. Don't give hints unless they are asked for.

Play-testing will produce a good 100 or so bugs, mostly awesomely trivial
and easily fixed. Still, expect a few catastrophes.

Good play-testers are worth their weight in gold. They try things in a
systematically perverse way. To quote Michael Kinyon, whose effect may be
felt almost everywhere in `Curses',

A tester with a new verb is like a kid with a hammer; every problem
seems like a nail.

And how else would you know whether "scrape parrot" produced a sensible
reply or not?

Unless there is reason not to (because you know more than they do about how
the plot will work out), listen to what the play-testers say about style and
consistency too. Be sure also to credit them somewhere in the game.

--- It's Never Finished ---

Games are never finished. There's always one more bug, or one more message
which could be improved, or one more little cute reply to put in. Debugging
is a creative process and adds to the life of the game. The play-testing
process has increased the code size of `Curses' by about 50%: in other
words, over a third of a game is devoted to "irrelevant" features, blind
alleys, flippant replies and the like.

Roughly 300 bugs in `Curses' have been spotted since it was released
publically two years ago (I have received well over a thousand email messages
on the subject), and that was after play-testing had been "finished". About
once a week I make this week's corrections, and about once every three
months I re-issue the mended version. Thus, many people who suggested
little extensions and repairs have greatly contributed to the game, and
that's why there are so many names in the credits.

--- ...Afterword ---

Bob Newell recently asked why the old, crude, simplistic Scott Adams games
still had such fascination to many people: partly nostalgia of the
`favourite childhood books' kind, of course. But also the feeling of
holding a well-made miniature, a Chinese puzzle box with exactly-cut pieces.

An adventure game, curiously, is one of the most satisfying of works to have
written: perhaps because one can always polish it a little further, perhaps
because it has so many hidden and secret possibilities, perhaps because
something is made as well as written.

For myself, though, perhaps also because each day somebody new may wander
into its world, as I did when occasionally taken to a Digital mainframe in
the 1970s, through a dark warren of passages untidier even than my bedroom:
so that the glow of the words has not quite faded from my eyes.

------------------------------------------------------------------------------

--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

</PRE>

<HR>




<UL>
<LI>Prev by Date:
<A HREF="msg00706.html">Re: [MUD-Dev] Magic as Metaphor</A>
</LI>
<LI>Next by Date:
<A HREF="msg00708.html">Re: [MUD-Dev] What in THE Hell was that?</A>
</LI>
<LI>Prev by thread:
<A HREF="msg00711.html">(fwd) Varying Time Commitment Levels: what's an admin to do?</A>
</LI>
<LI>Next by thread:
<A HREF="msg00705.html">DarkWhole test Identity Crisis</A>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00707">Date</A></LI>
<LI><A HREF="thread.html#00707">Thread</A></LI>
</UL>
</LI>
</UL>

<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI>RE: [MUD-Dev] (no title) Time limits?, (continued)
<ul compact>
<LI><A NAME="00718" HREF="msg00718.html">RE: [MUD-Dev] (no title) Time limits?</A>,
Justin McKinnerney <a href="mailto:xymox#toon,org">xymox#toon,org</a>, Sat 14 Mar 1998, 18:00 GMT
</LI>
</ul>
</LI>
<LI><A NAME="00712" HREF="msg00712.html">Hello, and a brief intro</A>,
cimri <a href="mailto:cimri1#gte,net">cimri1#gte,net</a>, Sat 14 Mar 1998, 01:44 GMT
<UL>
<LI><A NAME="00717" HREF="msg00717.html">Re: [MUD-Dev] Hello, and a brief intro</A>,
Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Sat 14 Mar 1998, 17:42 GMT
</LI>
</UL>
</LI>
<LI><A NAME="00711" HREF="msg00711.html">(fwd) Varying Time Commitment Levels: what's an admin to do?</A>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Sat 14 Mar 1998, 00:42 GMT
<LI><A NAME="00707" HREF="msg00707.html">The Craft of Adventure</A>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 13 Mar 1998, 03:37 GMT
<LI><A NAME="00705" HREF="msg00705.html">DarkWhole test Identity Crisis</A>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 13 Mar 1998, 03:17 GMT
<LI><A NAME="00703" HREF="msg00703.html">DarkWhole test #4</A>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 13 Mar 1998, 03:15 GMT
<LI><A NAME="00702" HREF="msg00702.html">DarkWhole test #3</A>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 13 Mar 1998, 03:15 GMT
<LI><A NAME="00701" HREF="msg00701.html">DarkWhole Test #2</A>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 13 Mar 1998, 03:14 GMT
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>