Why We Write, Pt. 1

I expect that the meat of this post will develop into a sort of standard introduction, by way of back-rationalization, to the benefits of Narrative Game Design as a formal practice. This isn't the first time I've tried to do this, but it may end up being the most pragmatic approach so far. After all this time, there are still people at the studio where I work who do not understand why there should be someone on the core design team - different from (or not only) the scriptwriter - who cares about the story of the game. Someone who is involved in the production from concept to gold master. Lately, my tried and true flippant response to people like that has been to hold up a very complicated flowchart printed out on tiled 11x17 sheets, explaining that "this is the story". But frankly, this seems a little glib.

Luckily, in the course of doing research for the Familiarity talk, I ended up reading the frequently-referenced paper by Penelope Sweetser and Peta Wyeth on Game Flow that lays out an excellent and rather thorough framework for examining how any particular aspect of a game's design contributes to the overall player experience. And since I've been arguing for a while now that the narrative is implicated in - you heard me - every aspect of the player experience, I now have a mouth with which to co-locate my money.

In attempting to model a players' enjoyment of the game experience, Sweetser and Wyeth adopt the concept of Game Flow, which hinges on eight elements (their order):

• Concentration
• Challenge
• Player Skills
• Control
• Clear Goals
• Feedback
• Immersion
• Social Interaction

The authors go on to exhaustively define the criteria for each of the eight elements of Flow. I'm only going to summarize them in the instances where it might otherwise appear that I'm over-reaching.

So the question is: Does a game's story contribute in any demonstrable way to all, some or any of the above elements? For about half of them, the answer seems to be indisputably, yes. The game story can - and arguably, should - be used to more clearly communicate the low, mid and high-level goals to the player. Given enough content and sufficient intelligence, the story systems can deliver immediate in situ feedback to the player. Immersion has probably been the main motivation in developing game story to date. The shared fictional universe of the game provides a context and common vocabulary for players connecting socially in multiplayer games; but I would even argue that NPCs are able to afford the player a simulation of social interaction, specifically where the story supports it (in single-player games where the player is encouraged to regard the NPCs as people instead of bots or pawns).

At least two of the remaining elements seem a little more problematic, and warrant a more in-depth examination of the Game Flow model. How can the story provide the player with more concentration? The model offers a number of criteria, but of greatest interest is the requirement that "players shouldn't be burdened with tasks that don't feel important." In fact, to facilitate concentration the game should enable the player to feel like he/she is making meaningful choices at every level. If the player understands that the events of the game are part of a larger narrative, and can see first-hand how their individual choices alter the outcome of that narrative, we can say that the game qualifies. On the subject of Player Skills, Sweetser and Wyeth deliver a fairly clear hint to narrative designers: "Players should be taught to play the game through tutorials or initial levels that feel like playing the game." In some ways, this requirement is THE best test of a given story's suitability; if it can't deliver to the player an elegant, motivated context for learning the rules of its own universe, it probably isn't up to any of the other tasks...

Now we're left wondering about two remaining elements of player satisfaction, control and challenge, that on first glance seem completely oriented around low and mid -level game mechanics; seemingly decoupled from any aspect of the experience that might implicate the narrative.

On the subject of control, Sweetser and Wyeth state that:

• Players should feel a sense of control over their characters or units and their movements and interactions in the game world
• Players should feel a sense of control over the game interface and input devices
• Players should feel a sense of control over the game shell (starting, stopping, saving, etc.)
• Players should not be able to make errors that are detrimental to the game and should be supported in recovering from errors
• Players should feel a sense of control and impact onto the game world (like their actions matter and they are shaping the game world)
• Players should feel a sense of control over the actions that they take and the strategies that they use and that they are free to play the game the way that they want (not simply discovering actions and strategies planned by the game developers)
  
  
• (emphasis mine)

It should be pretty obvious that a traditional linear narrative - predetermined by its author, baked into the game and unresponsive to the input of the Player - will fail to satisfy any of the criteria for control. Refering to Henry Jenkin's spectrum of environmental storytelling, we can start by looking at games that allow the player to enact a sequence of "micronarratives" throughout the gameplay experience, and conclude that the less frequently the narrative imposes bottlenecks in the Game Flow - i.e., contracts the possibility space of the low-level mechanics at pre-scripted intervals in the critical path - the less artificial the transition between game "story" and game "performance." Story moments occur more frequently, are more granular and are better distributed throughout the game. As a result, the story is less obtrusive and better able to conform to the player's individual low-level inputs. Instead of steering the player towards one particular solution or "exit", the story can unfold consistently even if the player is pursuing a novel strategy.

Emergent narratives - players' own stories that arise completely as a consequence of their low and mid -level choices - are a direct consequence of giving the player control over a wide breadth of systems and populating the simulation with highly affordant ingredients (including AI characters) that can be manipulated in an intentional way. When the player's story emerges in a coherent manner, adhering to (or at least mimicking) familiar narrative structures, the player receives a powerful jolt of actualization; the sudden awareness that he exists as a force in the game world, capable of making deliberate choices that have larger, meaningful consequences.

Both enacted and emergent narrative can be viewed as natural outcomes of an approach that uses the game's metaphor as a soft cushion between the player and the hard boundaries of the game simulation. The story is used to discretely guide the player away from the limits of his/her agency, keeping him/her in what Michael Mateas describes as the "sweet spot" between the formal (premise) and technical (simulation) constraints of the game. Put another way: If the metaphor of the game reinforces the player's own perception that they should be able to do a particular thing, the game's mechanics had better support it, or the player will feel a loss of agency. The logical complement to this idea is that if the player ever does collide with the boundaries of the simulation (both in the literal sense of "hitting the world fence" and in the mathematical sense of "boundary conditions"), there should be some failure-tolerant feedback, delivered within the context of the game metaphor, that keeps the player from feeling like he/she has "broken" the game.

In fact, ensuring that the game narrative serves the player's understanding of the game mechanics lies at the heart of a problem I refer to generally as "coverage." Delivering sufficient coverage of the control space is one of two components of the broader "continuity management" problem. What is the other? That's where challenge comes in. And that I will leave for the next post.

Comments

[Ben Sullivan]

While I can't claim to quite follow all the details of this excellent post, it provides some great links to other docs that I will enjoy reading over the next few days!

Good stuff! I appreciate people going to the effort of putting this awesome training material on the web for us young developers!

- Ben Sulli