Copyright: ©1995-1998, Graham Nelson.
Citation: WinHelp version by Stuart Moore.


Contents

The Craft of Adventure

In the beginning

Bill of Player's Rights

A Narrative...

...At War With a Crossword

Varnish and Veneer

Afterword

This help file was created with HelpScribble.


The Craft of Adventure

Second Edition.

By Graham Nelson.

WinHelp version by Stuart Moore.

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

mailto:graham@gnelson.demon.co.uk

http://www.gnelson.demon.co.uk

Stuart Moore

West Malvern

November 1998

mailto:Stuart_Moore@my-dejanews.com

Written with Jan Goyvaerts' HelpScribble.

mailto:jg@ping.be

http://www.ping.be/jg

This help file was created with HelpScribble.


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.

This help file was created with HelpScribble.


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' Bert 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.

This help file was created with HelpScribble.


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 is 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'):

>unlock journal

(with the small key)

No spell would help with that!

>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.

This help file was created with HelpScribble.


...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":

> 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.

    > 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 Room

  (buddha)	 (bonsai tree)

      |

 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:

Ballroom NW ----- Ballroom NE

| \	  /	|

|  Dance Floor	|

| /	  \	|

Ballroom SW ----- Ballroom SE

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.

This help file was created with HelpScribble.


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.

    >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:

   >places

   You have visited: Attic and Old Furniture.

   >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"):

> BARTENDER, GIVE ME A DRINK

"Sorry, I've been hired to mix drinks and that's all."

> DANCE WITH ALICIA

Which Alicia do you mean, Alicia or the overcoat?

Veronica's body is slumped behind the desk, strangled with a lariat.

> 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.

This help file was created with HelpScribble.


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.

This help file was created with HelpScribble.


HelpScribble

HelpScribble is a help authoring tool written by Jan Goyvaerts. This help file was created with the unregistered version of HelpScribble, which is why you can read this ad. Once the author of this help file is so honest to register the shareware he uses, you will not see this ad again in his help files.

Recompiling the help project with the registered version is all it takes to get rid of this ad.

HelpScribble is a stand-alone help authoring tool. It does not require an expensive word processor. (Only a help compiler as Microsoft likes keeping the .hlp format secret. Not my fault.)

Here are some of HelpScribble's features:

•	The Setup program will properly install and uninstall HelpScribble and all of its components, including registry keys.

•	Create, edit and navigate through topics right in the main window. No need to mess with heaps of dialog boxes.

•	All topics are listed in a grid in the main window so you won't lose track in big help projects. You can even set bookmarks.

•	Use the built-in Browse Sequence Editor to easily create browse sequences.

•	Use the built-in Window Editor to change the look of your help window and create secondary windows.

•	Use the built-in Contents Editor to create Windows 95-style contents files. Works a lot better than Microsoft's HCW.

•	No need to mess with Microsoft's SHED: use the built-in SHG Editor to create hotspot bitmaps. Draw your hotspots on the bitmap and pick the topic to link to from the list.

•	With the built-in Macro Editor you can easily compose WinHelp macros whenever needed. It will tell you what the correct parameters are and provide information on them.

•	If you have a problem, just consult the online help. The help file was completely created with HelpScribble, of course.

•	HelpScribble is shareware. However, the unregistered version is not crippled in any way. It will only add a small note to your help topics to encourage you to be honest and to register the shareware you use.

These options are very interesting for Delphi and C++Builder developers:

•	If you are a component writer, use the Delphi Parser to build an outline help file for your component. Just fill in the spaces and you are done. HelpScribble can also extract the comments from your source file and use them as the default descriptions.

•	If you are an application writer, HelpScribble provides you with a property editor for the HelpContext property. You can select the topic you need from a list of topic titles or simply instruct to create a new topic. No need to remember obscure numbers.

•	The property editor also provides a tree view of all the components on your form and their HelpContext properties. This works very intuitively. (Much nicer than those help tools that simply mess with your .dfm files.)

•	HelpScribble can perform syntax highlighting on any Delphi source code in your help file.

HelpScribble is shareware, so feel free to grab your copy today from my web site at http://www.ping.be/jg/