I thought I'd add a few comments for readers of the rec.arts.int-fiction
newsgroup, partly because like everyone else I like to talk about my own
work, and partly because I genuinely think that some aspects of
"Christminster" might be of interest to IF writers.
1. Characters
"Christminster" has more interaction with human characters than most
non-commercial games, and more even than many Infocom games. Although
the game isn't as tightly-plotted as Infocom's mysteries, or even as
much as "Plundered Hearts", it does have a handful of characters with a
reasonable range of actions (Edward has about 150 things he can do).
Lots of the puzzles are built around these characters and their
interactions with each other.
When David Baggett's "Legend" came out (about halfway though the writing
of "Christminster") I thought seriously about using David's method of
delineating characters through "cut scenes" - long passages of prose
that establish new relationships, or take the game through areas that
would involve a lot of difficult programming to allow interaction. But
I decided not to use this technique, partly because I think it's an
admission of defeat, a statement that the medium of adventure games is
too inflexible to write the kind of character interaction we want to,
and partly because I don't think my prose is good enough to sustain the
reader's interest for long enough.
I've used various techniques to try to make the interaction with the
characters more realistic. One idea I used, following Legend's
"Gateway" and some Infocom games, was to split up long interactions over
a number of turns, with some mechanism to keep the player sitting still
while the interaction was going on. In one case I want to player to
feel trapped, so they are prevented from getting away by main force; in
others there is a puzzle to solve while the incidental conversation goes
on.
Inevitably, interaction with characters is very limited: you can ask
them about things, you can order them to do things (when this suits the
solution to a puzzle), you can give and show them objects. I've tried
to make the puzzles a little more wide-ranging than usual, with
co-operation and trickery being necessary as well as the more
straightforward mechanisms of interaction.
If I write another adventure game, I'll work harder on the
characterisation of the NPCs. This seems likely to be very hard,
though: I've been reading some of the Oz project papers, and the message
I'm getting from them seems to be that the approach that works best is
to program by hand lots of individual aspects of behaviour, and that the
application of sophisticated AI techniques of knowledge representation,
planning and reasoning does not provide a magic bullet (for example, the
simulation of Lyotard the cat requires 10 emotions and 23 specifically
programmed behaviours - about 2000 lines of code).
2. Handling time
"Christminster" has a novel method of allowing time to pass. The action
takes place over a fairly short period of time (one day), with events
happening at particular times of day. My experience of playing games
with timed events (such as Infocom's mysteries) is that I spend so long
wandering around examining things and getting my bearings that all the
events go on before I figure when I have to be where. So I've tried to
avoid this happening in "Christminster": although there are timed
events, time does not pass at a constant rate, but advances with the
solution of the major puzzles. This means that it's very hard to miss
events by being in the wrong place at the wong time, and impossible to
get to a particular event but discover that you're powerless to solve a
puzzle because there's something you should have done earlier in the
day.
I don't know if this idea is entirely successful. Some of my
playtesters said that they didn't like timed games in general, but
enjoyed "Christminster"'s approach. Others were I think frustrated by
being prevented from waiting for events to happen ("why can't I wait
until seven o'oclock?" was an appeal I heard several times).
3. Experience of writing a complicated program
My major feeling, as I approached the end of the game, was of being
somewhat overwhelmed by the complexity of it all. I only had a little
over 50 rooms, and about 380 objects altogether (fewer of each than
"Theatre"), but with NPCs who can wander all over the map, a complex
system of timed events, many short scripted sequences lasting from a few
turns to several dozen turns, and 37,000 words of prose, I found it very
difficult to keep it under control and internally consistent. Quite a
few bugs of the form "If the player gets to location X before character
Y does, then strange things happen" (reminiscent of the bug in some
released versions of "Suspect" whereby you can reach the murder scene
before the murder happens) or "If the player abandons such-and-such a
sequence of interactions halfway through, it goes wrong" turned up in
playtesting.
It seemed to me that various factors contributed to the complexity
getting out of control.
First was my development method, which was to gradually add code to the
program as I thought of interesting ideas, and then use the results of
each addition to help me generate new ideas. Software engineering
theory says that this is a guaranteed way of producing a buggy program,
and the theory was correct (getting on for 400 bugs fixed and
improvements made since I started testing). From a software engineering
perspective, the thing to do now would be to treat "Christminster" as a
prototype and use it to write a specification from which I could develop
a production version by a more traditional and safe top-down approach.
But life is too short, and in any case I think a release now with many
bugs is better than a release in six months or a year with fewer.
Secondly, some of the most complicated code (that for moving Edward
around) was added very late in the testing process, and the architecture
to support that functionality wasn't present, so a lot of the rest of
the game needed changing (the example program
<http://www.cl.cam.ac.uk/users/gdr11/inform/thief.inf> contains some of
this code and discusses the problems inherent in Inform in trying to use
code that's oriented to moving the player around to move NPCs around).
If you have a copy of release 1, you can see some examples of the
problems by asking Edward to go down from "Outside the Kitchens", or by
waiting for him to reach the Arboretum before you get there.
Thirdly, I found it necessary to distribute code between objects for
certain interactions. In Inform (and TADS) the code for an interaction
with an object must be stored in that object, or in a global routine.
There isn't an easy way for object B to get a chance to intervene when
the player manipulates object A, except by adding code to object A. So
for example, the code for Edward is distributed among ten source files
in a way that's difficult to manage.
Regression testing was a technique that helped. I kept a script of
commands that exercised the solutions to all of the puzzles and which
tested lots of other features of the game too. By keeping the
transcript that resulted from this script before making a change, and
comparing it with the transcript that resulted after making the change,
I was able to track the effects of the bug fixes I made. In this way I
caught many errors that would otherwise have crept in as a result of
fixing other errors.
4. A couple of questions
(1) What hope is there for interesting interaction with other characters
in a game? (2) How do other IF authors manage to cope with the
complexity of plotting, writing and programming something as large and
interlocking as an adventure game?
-- Gareth Rees