[Main page] [Overview] /theory /craft-of-adventure-4
6 Varnish and Veneer
=====================
So you have a game: the wood is rough and splintered, but it's recognisably
a game. There's still a good month's work to do (and several centuries'
worth of debugging), though it is easier work than before and feels more
rewarding.
--- Scoring ---
The traditional way to score an adventure game is to give a points score out
of some large and pleasing number (say, 400) and a rank. There are usually
ten to fifteen ranks. A genuine example (which shall remain nameless):
Beginner (0), Amateur Adventurer (40), Novice Adventurer (80), Junior
Adventurer (160), Adventurer (240), Master (320), Wizard (360),
Master Adventurer (400)
in which, although ranks correspond to round numbers, still they have
perhaps been rigged to fit the game. Another amusing touch is that ranks
tend to be named for the player's profession in the game - so, a musician
might begin as "Novice" and rise through "Second Violinist" to
"Conductor". One of the wittiest is in the detective game `Sherlock',
where the lowest rank - of zero achievement - is "Chief Superintendent
of Scotland Yard".
Among the questions to ask are: will every winner of the game necessarily
score exactly 400 out of 400? (This is very difficult to arrange if even
small acts are scored.) Will everyone entering the end game already have a
score of 360, and so have earned the title "Wizard"? Will the rank
"Amateur" correspond exactly to having got out of the prologue and into the
middle game?
So what deserves points? Clearly solving the major puzzles does. But do
the minor, only halfway-there-yet puzzles? Here, as ever, games vary
greatly. In `Zork III', the scoring is out of 7 and corresponds to seven
vital puzzles (though a score of 7 does not mean the game is over). In `The
Lurking Horror', 20 major puzzles are awarded 5 points each, making a
maximum of 100.
Alternatively, there is the complicated approach. Points are awarded in
twos and threes for small acts, and then in larger doses for treasures -
silver bars 5, gold amulets 10, platinum pendants 20. Treasures are scored
twice, once when found, once when removed to safety - to the trophy case in
`Zork I', or inside the packing case of Level 9's game `Dungeon' (no
relation to the port of `Zork' of the same name). Furthermore, 1 point is
awarded for each room visited for the first time, and 1 for never having
saved the game - a particularly evil trick.
In some games (such as `Acheton') score actually falls back when the player
is wasting time and nothing is being achieved: the player's mana gradually
fades. This annoys some players intensely (no bad thing, some might say).
Games used to have a "Last Lousy Point" by custom - a single point which
could only be won by doing something hugely unlikely, such as going to a
particular area of the Pirate's Maze and dropping a key. This custom,
happily, has fallen into disuse.
--- Wrong Guesses ---
For some puzzles, a perfectly good alternative solution will occur to
players. It's good style to code two or more solutions to the same puzzle,
if that doesn't upset the rest of the game. But even if it does, at least
a game should say something when a good guess is made. (Trying to cross the
volcano on the magic carpet in `Spellbreaker' is a case in point.)
For example, in `Curses' there are (at time of writing) six different ways
to open the child-proof medicine bottle. They are all quite hard to guess,
they are all logically reasonable and most players get one of them.
One reason why `Zork' held the player's attention so firmly (and why it took
about ten times the code size, despite being rather smaller than the
original mainframe `Adventure') was that it had a huge stock of usually
funny responses to reasonable things which might be tried.
My favourite funny response, which I can't resist reprinting here, is:
You are falling towards the ground, wind whipping around you.
>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.
--- ...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.
------------------------------------------------------------------------------