+++++++++++++++++++++++++++++++++++++++++++++
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. 

Help topics available:

Bill_of_Rights	Craft_of_Adventure	DESIGN	Development	Fine_writing
Good_NPCs	Scripts