Gareth Rees, October 1995
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:
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).
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
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 favour if I could). There's no one sequence in the game which represents this, but instead it's a cumulative effect.
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 savouring the middle.
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 behaviour afterwards (I find there's always a temptation to skimp on the boring behaviour if I do that).
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 in order to accommodate this one feature. After all, it can always appear in your next game.
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.
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 organise 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.
(A new Z-machine)