The Craft of Adventure - Varnish and Veneer
Tutorials Table of Contents
The Craft of Adventure Index
So you have a game: the wood is rough and splintered, but it's recognizably 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 favorite 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 tying 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 armor 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 publicly two years ago (I have received well over a thousand email messages on the subject), and that was after play-testing had been "finished". About once a week I make this week's corrections, and about once every three months I re-issue the mended version. Thus, many people who suggested little extensions and repairs have greatly contributed to the game, and that's why there are so many names in the credits.
...Afterword
Bob Newell recently asked why the old, crude, simplistic Scott Adams games still had such fascination to many people: partly nostalgia of the "favorite 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.
Tutorials Table of Contents
The Craft of Adventure Index
< Previous: At War With a Crossword Next: >
