Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
The Designer's Notebook: Three Problems for Interactive Storytellers, Resolved
View All     RSS
February 26, 2020
arrowPress Releases
February 26, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


The Designer's Notebook: Three Problems for Interactive Storytellers, Resolved

by  [Design]

April 8, 2013 Article Start Previous Page 3 of 3

The Problem of Narrative Flow

If a player has considerable freedom in an interactive storytelling experience, it may be possible for her to stall the plot of the story, evade its dramatic climax, or fail to perform the necessary actions required for the dramatic climax to be coherent when it occurs. (If Rick doesn't take his pistol to the airport in Casablanca, he can't prevent Major Strasser from stopping the plane.) This is the Problem of Narrative Flow. How do you make sure that everything is set and ready (including the player) when the dramatic climax occurs in an interactive story?

In my 1995 lecture, I outlined three traditional approaches that we use to deal with this problem, none of them ideal:

  • Make the plot linear or reduce player freedom. When the plot is linear, the player is guaranteed to arrive at the dramatic climax at an appropriate moment, because she must pass through all the necessary precursor events to get there. Or you simply don't give the player much control over anything (Rick can't leave his pistol behind; he has no way to put it down). At the time I thought this was a bad idea because, I claimed, the whole point of interactivity was to give the player freedom.
  • Use real-time plot advancement. Game time goes on in real time; if the player's not ready when something important is going to happen, she just loses. The trouble here is that she loses a lot. This is what happened in Night Trap and Dragon's Lair, both games based on streaming video.
  • Let the player's actions drive plot advancement. This is the classic solution for most adventure games and RPGs: the whole world waits until the player has done everything necessary for the dramatic climax to take place and the player is in the right location. Unfortunately, this creates a very stop-start, mechanistic feel to the experience. NPCs tell the player how urgent it is to do something, but in fact nothing happens if he doesn't; it's not really urgent at all, because the advancement of the plot is strictly connected to the player's own actions.

During the lecture I shot down these solutions as unacceptable, once again based on some unwarranted assumptions. Like the Problem of Internal Consistency, the Problem of Narrative Flow is caused, at least partially, by the assumption that the object of interactive storytelling is to give the player maximum freedom. In fact, there are several ways to avoid the problem:

  • Don't give the player maximum freedom. It's pretty evident that players don't all demand maximum freedom. Portal is very popular both as a story and a game, despite having a completely linear plot. Many games use the foldback structure, in which the player has a certain amount of freedom most of the time, but the precursor events that must occur before the dramatic climax takes place are inevitable, sometimes as scripted narration rather than acts of player choice. This is perfectly OK for a great many players. It's up to you to decide if those are the players you're going to serve.
  • Tell stories with more than one dramatic climax. I was assuming that stories would be like short stories or (most) novels, with one single dramatic climax. But soap operas don't work this way; they present an endless sequence of small stories. If one remains unresolved, it doesn't necessarily interfere with any of the others.
  • Use player-independent plot advancement, which doesn't necessarily mean that it takes place in real time, or that the player necessarily loses the game if she isn't ready. The plot can advance by other means that the player cannot stall.
  • Use procedurally-generated plots. The story's plot and dramatic climax are not predefined, but procedurally generated based upon the player's actions, i.e. the plot of the story is emergent. If done right, this will guarantee that the player can't obstruct the plot because the plot is generated on the fly. We still have a lot of work to do on procedural storytelling in order to guarantee that it produces credible plot events at an an acceptable pace. It's a hard problem and probably won't be solved by the commercial game industry, because it requires a lot of risky experimentation. Various people in the academic field of interactive drama are working on it.

Having eliminated those cases, what remain are interactive stories in which the player has a great deal of freedom in a story that does have a predefined plot and a single dramatic climax. In this situation, we're back to the designer-player contract again. If the player accidentally obstructs the plot, then it's undoubtedly the designer's fault; but if the player does it on purpose, then it's her own fault. The more freedom she has, the more responsibility she must take for her own experience of the story.


Now, at this point some of you are probably thinking, "That's it? You got a PhD for that?" No, not quite. First, my thesis is 409 pages long, counting all the work I've done in the past, and it addresses a great many other subjects as well. It's also more rigorously argued, obviously, and discusses the contributions of Brenda Laurel, Chris Crawford, Michael Mateas, Andrew Stern, and many other theorists at length.

As you can probably tell by now, I reject the notion that there's one right way to do interactive storytelling. Different players like different things. Different designers want to achieve different things. I don't prescribe anything, either in my thesis or my teaching or my consultancy; I encourage people to think about what they want to accomplish, and to understand what the trade-offs are. Many game storytelling projects go wrong because the designers are confused about why the story is even there in the first place. A good teacher or a good consultant doesn't drag you through unfamiliar territory in the direction that he thinks is right; he gives you a map and the benefit of his experience with the terrain.

My thesis's biggest contribution, which isn't even addressed here, is my Template and Guide to Writing a Requirements Specifications for Interactive Storytelling. That's my road map. It's an overview, not for designing an interactive story, but for thinking about what you want your interactive story to do. I introduced version 0.1 of the Template and Guide at the 2011 GDC, and version 1.0 is included in the thesis. I have standalone versions available for download in ODT format or in PDF format. It's copyright-free.

One of these days I hope to write a book that puts all this stuff together in a format that's accessible both to working professional game designers and students too.

Article Start Previous Page 3 of 3

Related Jobs

Guildhall at SMU
Guildhall at SMU — Plano, Texas, United States

Professor of Practice
Digital Extremes Ltd.
Digital Extremes Ltd. — London, Ontario, Canada

Senior Lighting Artist
Purdue University
Purdue University — West Lafayette, Indiana, United States

Assistant Professor in Game Development and Design
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Gameplay Programmer

Loading Comments

loader image