Sponsored By

Building on his PhD research, Gamasutra's longtime columnist explores the ways in which game narrative is still problematic, testing theories and solutions, and offering potential suggestions based on years of research and thought.

Game Developer, Staff

April 8, 2013

18 Min Read

In February, after nearly 18 years of thinking and writing about interactive storytelling (as well as a good many other topics), I received a Ph.D. in that subject from the University of Teesside in the UK. My thesis is called Resolutions to Some Problems in Interactive Storytelling, and it's a retrospective and analysis of the papers and lectures I've given over the years. In this month's column, I'm going to summarize a few of my conclusions. (If you want to read the whole thing, which covers a lot more than this column does, you can download it here.)

One disclaimer before I start: my thesis only covers single-player, avatar-based stories in which the player contributes actions to the events of the story. It doesn't address multiplayer storytelling, non-avatar-based games (like The Sims), or static hypertext in which the reader's only contribution is to choose what to read next.

My work began back in 1995, when I gave a lecture at the Game Developers' Conference called "The Challenge of the Interactive Movie." Interactive movies were the latest hip concept at the time, having taken off following the invention of the CD-ROM. The title of the lecture was meant to lure in people who were excited by the idea, but I concluded that the "challenge of the interactive movie" is to make a decent video game despite the fact that the marketing department will insist on slapping this stupid label on it.

In the course of the lecture, I introduced some of the key problems that face any interactive storyteller. A few years later I described them again in "Three Problems for Interactive Storytellers," an early Designer's Notebook column. I called them the Problem of Amnesia, the Problem of Internal Consistency, and the Problem of Narrative Flow.

I concluded that these problems were fundamental to the nature of the interactive medium and couldn't be resolved, only lived with. But in the years since then, I gained a better understanding of them, and I did in fact resolve them, at least to my own satisfaction.

We'll start with the easiest one.

The Problem of Amnesia

This is the well-known fact that the player enters the game world with amnesia: she doesn't know who she is, where she is, or what she is supposed to do there. In the game industry, we deal with this rather poorly. The earliest commercial computer games required the player to to read a manual; later we devised tutorial levels, long narrative passages (Okami), or long expository speeches from mentor characters (Planescape: Torment).

In the worst case of all, we give the player an avatar who is actually said to be suffering from amnesia -- I consider this to be a Twinkie Denial Condition because it's such a cheesy solution.

Eventually I came to realize that this isn't really an intractable problem, and it isn't by any means exclusive to video games. All stories have to introduce their audience to the setting and characters. Movies sometimes use opening narration, especially if the location is unfamiliar; you can see it from Casablanca to Star Wars to The Fellowship of the Ring.

In TV shows, where time is tight, characters will find a reason to use each others' names in the early dialog. Establishing shots tell us where the show is set by including a famous landmark (the Golden Gate Bridge, Sydney Opera House) or, in less familiar places, a look at a road sign that includes the town's name.

Skilled writers can introduce the player to a place and a cast of characters subtly, in such a way that nothing that she hears or sees seems unnatural. Of course, games have an additional problem that the presentational media don't have to deal with: we have to teach the player to use the controls, too; but there are better and worse ways to do it.

Any game in which the avatar has a particular profession -- football player, soldier, dancer -- can include a training camp or practice room that both belongs in the game world and brings the player up to speed without risking anything. Take a look at my column "Eight Ways to Make a Bad Tutorial" for further discussion.

In the end I concluded that it's simply a question of craftsmanship. The Problem of Amnesia can be solved by any competent writer. Games have more time than TV or movies to introduce their world, so there's no excuse for doing it badly.

The Problem of Internal Consistency

When people think about the challenges of interactive storytelling, this is the problem they think of most often: how to provide a consistent, well-formed story experience to the player if the player has great freedom of action? If you give the player a lot of freedom, he will have the power to subvert your story. There seems to be an inverse relationship between player freedom and story coherency.

There are three ways a player can destroy a game's story: violate the game world (by introducing things that don't belong there, often through speech); violate their own character (by acting in ways that are inconsistent with the way the avatar is defined -- in the lecture I used the example of Superman ignoring a baby crying in a burning building); and violating the plot itself, by doing something that results in an absurdity (e.g. destroying an object that reappears later in a predefined plot).

Of course, we usually prevent the player from doing these things by curtailing his freedom in various ways. Many games only offer pre-written lines of dialog, so the player can't talk about things that aren't part of the game world. Plots are designed so that the player cannot harm something that he will need later. (In the Grand Theft Auto games, you can't hurt the people who give you your missions, or even find them.) And if Superman ignores the baby, it's just a loss condition: game over.

Some designers, notably Chris Crawford and Andrew Stern, find this solution unacceptable; they feel that it is imperative to let the player do what he wants, and an interactive story must adapt to it. A few even think that we should never put a story in a video game at all, an absolutist point of view that I find ludicrous given their popularity.

The more I thought about it, the more I realized that we have constrained ourselves with some faulty and usually unstated assumptions about what interactive storytelling should be like. Here are the assumptions that we have made for years:

  • "Our goal is to create a sandbox that allows maximum freedom to the player." We have believed this ever since text adventures, which gave the player the illusion that he could type in any command and the game would execute it. Of course, it never really could, but in our heart of hearts we secretly believed that someday, games would offer that much power. Another name for this is the "go-anywhere-and-do-anything" ideal.

    This assumption, glorious fantasy though it is, is not only unrealistic but unnecessary. The protagonists of conventional fiction are not gods; dramatic tension arises from the conflict between their need to accomplish something and the obstacles or limitations that prevent them from doing it. Nor is conventional fiction about the protagonist doing anything he feels like; it would make no sense for James Bond to give up spying and become a chef. Or, as Michael Mateas put it, "Why do I have to give the player verbs that are completely unrelated to the dramatic context? ... In 'traditional' games the player has a limited set of verbs available as well." The degree of freedom and agency that an interactive storytelling experience offers should be a function of the designer's original premise for the experience, rather than based upon an unreasonable assumption that the designer should always maximize them.

  • "Interactive stories shouldn't be games," by which I mean that the player shouldn't necessarily try to "win" at something in an interactive story, because that doesn't feel storylike; nor should an interactive story include a lot of numerical mechanics. The assumption is that experiencing a true interactive story -- whatever that is -- won't feel like playing a game, or involve striving to optimize some value.

    I realized how limiting this is when I heard Ken Perlin propose that an interactive story could use mechanics to preserve its own believability. Perlin said, "The cost of an event in an interactive story should be directly proportional to its improbability," which I later dubbed "Ken Perlin's Law." You could give the player a wide range of actions, but the more unbelievable the action, the more it costs; do it too often and the action becomes unavailable. I called the account that the player actions should be charged against the story's credibility budget.

  • "The player shouldn't have to think about any rules." Thinking about rules, and obeying them, is a game-like activity that destroys narrative immersion. We have long assumed that the ideal interactive story won't have any explicit rules and the player won't have to voluntarily constrain his own behavior. The game will respond appropriately no matter what the player tries to do.

    This assumption is OK for the laws of physics or economics, but it's trickier when we enter the social and above all the dramatic domains. We can use the game's mechanics to limit the player to what is possible in a physical sense, and we can construct the user interface in such a way that the player can only execute physical actions that we approve of. But if we want players to interact socially with other characters, we have to give the players the power to speak (or type), and that means they have to think about what would make sense to say. Players are already used to thinking about and obeying rules in MMOGs; if you harass another player, you get kicked out.

  • "The designer is completely responsible for the player's experience." This assumption is a natural outgrowth of our expectations about books and movies: the author is in charge, and if the audience doesn't like the author's material, the author has only herself to blame. For the most part, we think the same thing about video game designers. They designed the game, so anything that goes wrong with it is their fault.

    But if you bring this viewpoint over to interactive stories, it means that the designer has to guarantee a well-formed story to any player who wants one, regardless of what the player does. That's a lot to ask -- too much, in fact.

Once you abandon these assumptions -- which, as I said, are deeply rooted but largely unstated -- then interesting things start to happen. Over the years, various commentators have asserted that the designer and the player collaborate to create the player's experience, but they've seldom explained what this really means. In 2006 I suddenly realized that this collaboration arises out of the player's role in the game, and particularly how that role is defined. Role-playing is the fulcrum of the balance between story consistency and player freedom. Not role-playing in the CRPG sense -- leveling up and buying weapons -- but role-playing in the dramatic sense.

When a player starts to play a game in which he enacts an avatar character, he agrees to play the role that goes with the character. It's up to the designer to decide how strictly that role is defined. Superman, for example, has no moral freedom at all; a player who wishes to enact Superman signs up to Superman's moral constraints.

MMORPGs, on the other hand, frequently allow the player to build the avatar character from the ground up, and to enact a very wide variety of roles -- one of which might be to just hang around the entrance and give advice to newbies, if that's what they want to do.

However the role is defined, when the player chooses to play, he enters into a contract with the designer. The contract is very simple, and these are its terms: The designer promises to provide a credible, coherent story if and only if the player promises to behave in credible, coherent ways.

To put it another way, with freedom comes responsibility. The more power the player has within the game world to contribute actions to a story, the more responsibility he must take for those actions.

This abandons the assumption that the player shouldn't have to think about any rules; he has to think about the rules of drama. It also abandons the assumption that the designer is responsible for everything. If the player intentionally does something to screw up the game's story, then he, not the designer, is the one at fault.

(If he screws up the story unintentionally, that's a different issue. That's the designer's fault. It's up to the designer to construct a world in which the player cannot accidentally violate the story.)

In summary, I concluded that we still have the eternal trade-off between player freedom and story consistency, but it isn't such a big problem after all. It only seemed like a big problem because we assumed that we designers had total responsibility for anything that happened; that the player should be allowed to do whatever he liked and the story should respond appropriately; and that we were required to offer him maximum freedom at all times. By making those assumptions, we set ourselves up to fail. Instead, we need to embrace the trade-off and learn to work with it. The more power that we designers keep for ourselves, the more we are responsible for the quality of the story; the more power that we share with the player, the more the player shares in our responsibility.

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.

Conclusion

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.

Read more about:

Features
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like