LAST CHANGE
2000-12-16
TOPIC
NAME
development -
DESCRIPTION
+++++++++++++++++++++++++++++++++++++++++++++
Distinguishing Between Game Design
and Analysis: One View
+++++++++++++++++++++++++++++++++++++++++++++
by Gareth Rees (Gareth.Rees@cl.cam.ac.uk)
--------------------
Introduction
--------------------
I wrote this essay in response to "Game Design at the Drawing Board"
by Christopher Forman (XYZZYnews #4). When I read that essay, I
felt that it didn't really correspond well with the way I work on
adventure games. For me, maps, puzzle graphs, walkthroughs and
scoring tables are all tools of game analysis, not game design. Design,
in the creative sense, lies elsewhere.
I will attempt to outline a set of concepts which can be used to
describe the design of a game and also to assist the generation of
ideas. These concepts describe my own thought processes while I
wrote my game Christminster. The design proceeded on four levels:
--------------------
Level One: Plot
--------------------
At the top is the game's plot. The plot is the set of elements of the
game that might be used to make a story: what the background is,
what happened before the game started, who the characters are, the
major events that form the course of the story, and how the story
will end. The plot is a map that shows how the characters interact
and change as they go from the beginning of the story to the end (or
ends, if the plot is branching).
--------------------
Level Two: Scenes
--------------------
A plot is too constraining to implement directly as an adventure
game and still end up with a satisfying result. In a conventional work
of fiction, the freedom of the viewpoint character is never an issue:
the author can move all the characters through their various
interactions and emotional states until they reach the end without
much difficulty. In an interactive work, this is much more tricky to
do. What is necessary is to divide the elements and events of the plot
into their smallest constituent parts, and so arrive at a set of atoms
which may be reconstructed by the player into a decent plot. In
Christminster, I identified a set of key scenes , each of which was an
event or experience that affected the player character, and moved
the story forwards towards the conclusion, and yet could plausibly
be implemented as a section of an adventure game.
A scene is a single dramatic event that typically brings together
several components: interaction between the player character and
other characters in the game; a strong effect on the player character;
and preferably a strong effect on the reader herself.
It's probably easiest to explain what I mean by giving examples from
Christminster. I needed to introduce Jarboe and Bungay as
characters, and I needed to make it clear that they were the villains
of the game. I also wanted the reader, playing Christabel, a woman in
a milieu dominated by men, to feel scared and intimidated by the
two men. Out of these goals arose the scene in which Christabel is
trapped in Malcolm's bedroom and forced to endure a succession of
insults and threats. Another example is that I wanted to establish
Wilderspin as a friend of Christabel's. I've also always liked the
(admittedly rather cheap) dramatic effect of being plunged into
darkness underground by the closing of a secret door. These two
goals came together in the scene in the darkness of the secret
passage in which Wilderspin relates a crucial piece of information as
part of a story about Isis and Osiris.
These two scenes were carefully scripted: I began by writing them
down on paper in the form of a game transcript; neither was changed
much when I came to implement them. I went to some trouble in the
secret passage scene to avoid unnecessary complications. Christabel
drops all her possessions as she trips over the step on her way into
the passage so that (hopefully) the reader won't be distracted by
thinking "Which of my possessions do I need to use to get out of
here?"
A scene doesn't have to map directly to a sequence in the game.
Another effect I wanted to achieve was for the reader to experience
a sense of wonder at the myriad glimpses of the history of the
college, and to feel a sense of achievement at the success of her
researches (Curses had these effects on me, and I wanted to return
the favor if I could). There's no one sequence in the game which
represents this, but instead it's a cumulative effect.
--------------------
Level Three: Puzzles
--------------------
The third level of design is that of puzzles. A few puzzles in a game
will be integral parts of the plot, thought up at the earliest stages.
But most puzzles aren't part of the plot, but are instead added on
later for a variety of reasons. The most important reason for the
existence of puzzles in a game is to force the reader to experience the
scenes. It would be a waste of all that careful planning if the reader
could go from the start to the finish directly, without experiencing
any emotional development and character interaction! One way to
do this is to have puzzles that require for their solution that the
player has experienced the relevant scene or scenes. Another way is
to have puzzles that are an inducement to sit still while a scene is
taking place. For example, in Christminster, the puzzle in which
Christabel must escape from the secret passage is there to make the
reader stay around and listen to Wilderspin (not vice versa, as the
naive reader might expect!). The various puzzles that take place
during the dinner scene are an inducement to stay there and listen to
the conversation, without feeling that the game is too boring and
linear (which it otherwise would be).
Since puzzles aren't the main point of the game, I think their exact
nature doesn't really matter. However, to act as good inducements to
take part in the scenes, the puzzles should arise integrally from the
milieu of the game and be intriguing and challenging. In an ideal
world every puzzle would have a very satisfying and elegant
solution, but alas, this is very difficult to arrange.
A few puzzles are left over and are just there for the sake of having
interesting puzzles to solve, or to demonstrate the cleverness of the
programming, or to impede the progress of the reader so that she
doesn't reach the end without savoring the middle.
-------------------------
Level Four: Code and Text
-------------------------
Having planned a scene and possibly written a transcript of how it
should look, and having designed a puzzle or two to go along with it,
there's a lot of programming to do. My intuition here is that the first
thing to do before writing anything to do with plot or puzzles, is to
set up the basic definitions of the objects involved. For each object
whose existence is implied by these plans, I try to think about it as a
player: what kind of interactions can I attempt with this object? It
can be helpful during this process to have a list of verbs by their side
and to consider each verb against each object. Only when I have the
basic definition do I add the code to make it a part of the puzzle. I
think it's easier to work this way round, starting with the object as
part of simulated world and progressing to its role in the story, than
to code the puzzle first and add the boring behavior afterwards (I
find there's always a temptation to skimp on the boring behavior if I
do that).
-----------------------------
Putting The Levels Together
-----------------------------
Typically development takes place on all four levels at the same
time. A vague idea of the overall structure of a game is necessary to
get started, but very little (I started work on Christminster's initial
puzzle when I still thought that the game would involve the college
having been taken over by elves and a mountain range in the
gardens).
The author needs to be a bit farther ahead on each level than on the
level below, but not necessarily very far. When I was writing the
code in Christminster for First Court I had a good idea of what scenes
would take place in Second Court but only a vague idea about dinner
and the endgame. Sometimes an aspect of the game will prove tricky
to pin down; the only thing to do is leave it and come back later (for
example, I completed the gardens long before I thought of a good
way to turn getting into the gardens into a puzzle).
Obviously each level affects all the others; if a scene is too difficult to
be coded up (for example, if I wanted a scene in which the player
persuades the abbot to take a vow of poverty by force of theological
argument) then there is nothing for it but to go back and rethink the
plot. If you have a great idea for a scene but simply can't think of a
puzzle to motivate it, or a great idea for a puzzle but can't think of a
way to connect it to the plot, then you had better put your great idea
aside rather than try to squeeze the rest of the game out of shape.
After all, this feature can always appear in your next game.
--------------------
Tools for Analysis
--------------------
The standard tools of adventure development (maps, puzzle graphs,
walkthroughs and scoring) are useful tools to check that silly
mistakes haven't been made. I didn't find them of any help in the
creative process, though.
Maps are important for checking the realism of the landscape
(making sure that rivers don't change direction or run uphill, that
buildings have realistic shapes and sizes, that the topography is
geologically plausible), for checking that the player character has
enough freedom of action, and for checking that the map steers a
balance between being too grid-like and being too maze-like.
A puzzle graph (that is, a directed acyclic graph showing which
puzzles must be solved before which other puzzles) is a good way to
understand the game's constraints on the order of the player's action,
to check that the game is solvable, to make sure that the game steers
the right balance between being too linear and being too wide, and to
check that there are enough optional puzzles and alternate solutions.
Walkthroughs and transcripts are most useful in the debugging
process. A walkthrough makes it easy to check that a game is
solvable, and that old puzzles are broken by the coding of new ones
(this is especially important if there are timing constraints or other
complex interactions between puzzles). A transcript makes it possible
to check exactly what effect changes have on the course of a game.
When I was debugging Christminster, I had a walkthrough which
exercised all the puzzles and many of the game's interesting
responses, and I kept a transcript of the game produced by capturing
the output of the walkthrough. After making a batch of changes to
the code, I ran the walkthrough again to produce a new transcript,
and used the 'diff' program to examine the differences between the
old and new transcripts. In this way, I caught many, many bugs that
would otherwise have bee introduced during play-testing.
Scoring is for the player's benefit, not the author's, and is best added
as late as possible in the development process (otherwise you'll end
up spending lots of time fiddling with points here and there to make
it add up, and risk breaking the scoring system as you alter the code
for objects and change the assumptions under which the scoring
system worked). If you have a reasonably sophisticated hint system,
it's probably useful to link the scoring with the hints, because
otherwise you'll end up duplicating code since whenever the player
solves a puzzle you have to both update the score and update the list
of available hints.
--------------------
Conclusion
--------------------
This is a useful approach to the design and analysis of an adventure
game. I certainly don't claim that this is the full story, or that
everyone works in the same way. Each author goes about the
creative process differently, and the same author may work in
radically different ways on two games, or on two parts of the same
game. Not everyone will want to work in this way; all I can say is
that the process helped me to organize my ideas when writing
Christminster.
If you will permit a modicum of speculation, I think that some of the
ideas in this article may be useful when writing games which don't
have a pre-determined plot (in the linear or branching sense), but
instead try to assemble one dynamically from "plot fragments" or
using a "plot calculus." Such a game will be designed as a collection
of scenes embodying particular interactions or experiences, which
can be invoked according to the needs of the developing plot to
produce a satisfying story. Each scene will come with a set of
parameters describing the change of state which it causes (in terms
of the characters' emotions, beliefs and so on, as well as the state of
the world), and given a suitable collection of such scenes, the plot
generator can select the scene which has the most desirable effect on
the parameters of a game.