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.