The Craft of Adventure
Five articles on the design of adventure games
Copyright © 1995-6 Graham Nelson. Second edition.
HTML conversion by N. K. Guy, tela design.
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 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?
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 cliché) 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.
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.
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).
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 cliché. 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.)
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:
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.
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.
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:
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.
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).
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:
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,
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.
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:
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:
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.
Puzzles and objects are inextricably linked to the map, which means that the final state of the map only gradually emerges and the author should expect to have to keep changing it to get it right - rather than to devise an enormous empty landscape at first and then fill it with material.
Back to atmosphere, then, because throughout it’s vital that the map should be continuous. The mark of a poor game is a map like:
Glacier | Dungeon --- Oriental Room --- Fire Station (fish) (megaphone) (tulips) | Cheese Room
in which nothing relates to anything else, so that the game ends up with no overall geography at all. Much more believable is something like:
Snowy Mountainside \ Carved Tunnel | Oriental Room --- Jade Passage --- Fire Dragon (buddha) (bonsai tree) Room | Blossom Room
The geography should also extend to a larger scale: the mountainside should run across the map in both directions. If there is a stream passing through a given location, what happens to it? And so on. Maps of real mountain ranges and real cave systems, invariably more convoluted and narrow than in fiction, can be quite helpful when trying to work this out.
A vexed question is just how much land occupies a single location. Usually a location represents a ‘room’, perhaps ten yards across at the most. Really large underground chambers - the legendary “Hall of Mists” in Adventure, the barge chamber in ‘Infidel’ - are usually implemented with several locations, something like:
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.
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:
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.