Game designers have tended to perceive an analogy between dramatic tension and gameplay tension, as if the two terms simply denoted the same feeling. However, the analogy is a false one. Dramatic tension depends on the reader’s identification with a character (or several of them) and curiosity about what will happen to that character. Gameplay tension does not require any characters. A darts player feels gameplay tension in wondering whether he can hit the bull’s-eye, but that situation provides dramatic tension only if the outcome matters to a character in the context of a story.
A key difference between dramatic tension and gameplay tension lies in the differ- ing abilities of these feelings to persist in the face of randomness and repetition.
Randomness means unpredictable and arbitrary changes in the course of events.
Repetition refers to identical (or extremely similar) events occurring at different times in the progress of the story or game.
ptg7947181 STORY TELLING AND NARRAT IVE 165
C H A P T E R 7
Dramatic tension, and reader interest in the dramatic subject, fades in the presence of both randomness and repetition. If the events in a story seem random—accidental and unrelated to one another—the reader wonders why he is bothering to read it.
Likewise, no story should include identical events that repeat themselves more than once or twice. If a police officer knocks on a potential witness’s door and there’s nobody home, he shouldn’t have to do it more than once or twice before he gets an answer. Having this happen again and again in a story would make it boring. In some circumstances repetition can be played for laughs, if not overdone—in The Secret of Monkey Island, every time the hero escapes from a hut in which he is con- fined, the natives put a bigger lock on the door until the door looks like a bank vault. But even this is not completely repetitive, because each lock the natives add looks different.
Gameplay tension, on the other hand, easily tolerates both randomness and repeti- tion for much longer. Poker and Tetris include a lot of randomness and repetition, yet they retain their gameplay tension.
Consider the following dialog from the British television science fiction comedy Red Dwarf. Arnold Rimmer, sitting around one evening with his roommate, Dave Lister, recounts every detail of a game of Risk, die-roll by die-roll, that he played 10 years earlier. Lister asks him repeatedly to shut up, and Rimmer can’t understand why.
RIMMER: But I thought that was because I hadn’t got to the really interesting bit.
LISTER: What really interesting bit?
RIMMER: Ah well, that was about two hours later, after he’d thrown a three and a two and I’d thrown a four and a one. I picked up the dice…
LISTER: Hang on Rimmer, hang on… the really interesting bit is exactly the same as the dull bit.
RIMMER: You don’t know what I did with the dice though, do you? For all you know, I could have jammed them up his nostrils, head-butted him on the nose and they could have blasted out of his ears. That would’ve been quite interesting.
LISTER: OK, Rimmer. What did you do with the dice?
RIMMER: I threw a five and a two.
LISTER: And that’s the really interesting bit?
RIMMER: Well, it was interesting to me, it got me into Irkutsk.
—RED DWARFSERIES 4, EPISODE 6, “MELTDOWN” Two lines in this exchange illustrate the point quite clearly. Lister says, “The really interesting bit is exactly the same as the dull bit,” and later Rimmer says, “Well, it was interesting to me, it got me into Irkutsk.” Like Tetris,Risk is full of repetition and randomness. Rimmer believes that it’s interesting because he confuses the gameplay tension that he felt—will I conquer Irkutsk?—with dramatic tension.
ptg7947181
DESIGN RULE Randomness and Repetition Destroy Dramatic Tension
The narrative events in a game’s story must not occur randomly or arbitrarily, nor should the narrative repeat itself, even if the play itself is repetitive.
The Storytelling Engine
To design a game that includes a story, you must interweave the gameplay—the actions taken to overcome the game’s challenges—with the narrative events of the story. Narrative events must be interspersed among the gameplay events in such a way that all events feel related to each other and part of a single sequence that entertains the player. If the gameplay concerns exactly the same subject matter as the narrative—and it should, in order to present a coherent and harmonious whole—then the entire experience, play and narrative together, will feel like one continuous story.
The storytelling engine does the weaving. Chapter 2, “Design Components and Processes,” introduced the storytelling engine briefly as the third major component of a video game along with the core mechanics and the user interface. Unlike the other two, the storytelling engine is optional; if the game doesn’t tell a story, it doesn’t have a storytelling engine.
Just as the core mechanics generate the gameplay, the storytelling engine manages the interweaving of narrative events into the game. The core mechanics oversee the player’s progress through the game’s challenges; the storytelling engine oversees the player’s progress through the game’s story. The storytelling engine and core mechanics must work together to create a single, seamless experience.
Figure 7.1 illustrates the relationship between the storytelling engine, core mechanics, user interface, and player. Notice that Figure 7.1 resembles Figure 2.1 from Chapter 2. Figure 2.1 showed how the core mechanics produce and manage gameplay. Figure 7.1 shows how both the core mechanics and storytelling engine together produce the experience of interacting with a story.
As the section “Interactive Stories” explained earlier, an interactive story contains three types of events: player events, in-game events, and narrative events. The core mechanics manage the player events and in-game events, as the figure shows. The storytelling engine manages the narrative events. However, the storytelling engine does more than just play movies or cut-scenes; it also keeps track of the progress of the story and determines what part of the plot should come next.
ptg7947181 STORY TELLING AND NARRAT IVE 167
C H A P T E R 7
Notice that a double-headed arrow labeled Triggers connects the storytelling engine to the core mechanics in Figure 7.1. At times, the core mechanics may determine that the interaction should stop and the storytelling engine should present some narrative—for instance, when a player completes a level. The core mechanics send a message to the storytelling engine saying that the player finished the level and the storytelling engine should now display any interlevel narrative events. Likewise, the storytelling engine can send a trigger back to the core mechanics when a narra- tive event finishes (or when the player interrupts a narrative event), telling the core mechanics to resume play.
The storytelling engine doesn’t sit idle during play, however. As the player pro- gresses, the mechanics continually send triggers to the storytelling engine—that way, the storytelling engine can keep up with what’s going on. If, for example, the player makes a key decision that will affect the story later on, the core mechanics inform the storytelling engine of the decision.
Similarly, during play the storytelling engine can determine that the story has reached a critical plot point and trigger the core mechanics to cause changes to the internal economy of the game. Suppose the story says, “When the avatar reaches the bridge, he will be attacked by a highwayman in a cut-scene and robbed of all his property.” The core mechanics, tracking the player’s progress through the game world, send a message to the storytelling engine, “The avatar has reached the bridge.”
The storytelling engine detects that this is a key point, halts play, and displays a cut-scene showing the robbery. Then it transmits a message back to the core mechan- ics saying, “Transfer the avatar’s inventory to the highwayman and resume play.”
Normally, the level designers do the work that actually implements such events in the game. Among the level designer’s tools for level-building will be a mechanism
FIGURE 7.1 The relationship between storytelling engine, core mechan- ics, and user interface
CORE MECHANICS STORYTELLING ENGINE
USER INTERFACE PLAYER
Outputs
Narrative Events In-Game Events
Triggers
Player Events Inputs
ptg7947181 for detecting the avatar’s position and for triggering both the cut-scene and the
transfer of the avatar’s property. At the moment, a development company cannot license a storytelling engine from a middleware company the way it can license a graphics engine or a physics engine, but that may change. Still, at a conceptual level it will help you to design the story and its interaction with the gameplay if you think of these events in terms of triggers sent between the two separate com- ponents, the core mechanics and the storytelling engine.
As you can see, the storytelling engine plays a critical role in weaving the gameplay and narrative together to create the whole experience. The rest of this chapter refers to the storytelling engine frequently.
Linear Stories
From the earliest days of computer gaming, designers have been intrigued by the idea of agency: letting the player influence the plot and change the outcome.
Game developers refer to stories that the player cannot change as linear stories and those that the player can change as nonlinear stories. The next section addresses nonlinear stories.
A linear story in a video game looks similar to a linear story in any other medium, in that the player cannot change the plot or the ending of the story. In a game, however, the player still faces challenges as she goes through the story, and in fact the challenges form part of the story itself. Thus, a linear story in a game is still an interactive story, but the player’s interactions are limited to contributing actions.
Still, many games use this format. Consider Half-Life and StarCraft: Both tell linear stories, the outcome of which the player cannot change, but the player performs many actions as part of the story along the way.
Creating linear stories offers many advantages, which explains why, after a flurry of experimentation with nonlinear ones in the 1990s, the game industry largely returned to this practice. Linear stories do have disadvantages as well, however.
Here are some of the pros and cons to consider when designing your own story.
■ Linear stories require less content than nonlinear ones. If a player can only ever experience one fixed sequence of events, you only need to create material for those events. Developing the game using a linear story requires less time and money.
■ The storytelling engine is simpler. The storytelling engine managing a linear story has to keep track of only a single sequence of plot events. Because the player cannot change the course of events, the storytelling engine doesn’t need to record critical decisions that the player makes: There aren’t any. The storytelling engine will be easier to implement in software if you use a linear story.
■ Linear stories are less prone to bugs and absurdities. If the sequence of events remains the same regardless of players’ actions, you can guarantee that the story makes sense. On the other hand, if you allow the sequence of events to vary—that
ptg7947181 STORY TELLING AND NARRAT IVE 169
C H A P T E R 7
is, you present a nonlinear story—you introduce the risk of error. The storytelling engine must guarantee that the events make sense. If the player wrecks a car during play in a game with a nonlinear story, the storytelling engine must ensure that the game does not present any subsequent gameplay or narrative material that shows the car undamaged. If you’re not careful, you can introduce what the film industry calls continuity errors: things that look different from the way they should look, given the events of preceding scenes, because narrative material can’t change to keep up with game events. Linear stories don’t incur this risk. If a car is wrecked as part of the story, it stays wrecked; if it mustn’t be wrecked, then you must not give the player any way to wreck it.
■ Linear stories deny the player agency. The player may have freedom to do a lot of things in the game, but none of it influences the story apart from causing it to progress. As the previous consideration said, if the story requires a functional car throughout, then the gameplay cannot allow the player to wreck the car. The sec- tion “Endings,” later in this chapter, discusses this issue in more depth.
■ Linear stories are capable of greater emotional power. From a creative stand- point, this is one of their greatest advantages. The section “Emotional Limits of Nonlinear Stories” explains this point in more detail later in this chapter.
Note that if you want to tell a strictly linear story, that decision will have conse- quences for any story you plan to treat as a journey (as many are). See the section
“The Story as a Journey” later in this chapter.
Nonlinear Stories
If you allow the player to influence future events and change the direction of the story, then the story is nonlinear. This chapter examines two of the most common structures for nonlinear stories—branching stories and foldback stories—in detail in the next two sections. A third approach, emergent narrative, is more of a research problem than a standard industry mechanism, and we’ll discuss it briefly. After that we’ll look at a new hybrid technique that shows great promise for the future of interactive storytelling. Finally, we’ll study an important issue for any teller of non- linear stories: How many endings should the story have?
Branching Stories
Abranching story allows the player to have a different experience each time he plays the game. The story offers not one plot line but many that split off from each other at different points. As the designer, you decide on the different possible plot lines and how they relate to each other. During play, the storytelling engine keeps track of which plot line the player is following at any given time. When the story reaches abranch point—a place where the current plot line subdivides—the core mechanics must send a trigger to the storytelling engine to tell it which of the possible branches of the story the player will follow next.
ptg7947181 Game events—either player events or in-game events generated by the core
mechanics (such as an action taken by an AI-driven NPC)—determine which branch the story will take. Player events that influence the direction of the story fall into two categories: efforts to overcome a challenge or decisions that the story asks the player to make. Branch points connected with player decisions have one branch for each option that you offer to the player. Typically, branch points associ- ated with challenges have only two branches leading on from the branch point, one for success and one for failure, though you can also create different numbers of branches for different degrees of success if you want to. We’ll consider the emo- tional consequences of branches based on challenges versus those based on choices in the later section “Endings.”