Rules to Play by: Story and Game Design

Games Telling stories?
-A brief note on games and narratives
by Jesper Juul

In this article Jesper Juul poses the following question: Do Games tell Stories?
To answer this question Juul examines three arguments that favor the statement that Games tell Stories. Then Jull switches sides and looks at three arguments that speak against this statement. Then he finishes by looking at some experimental ways of telling Stories in games.

The most compelling argument he looks at that favors Games telling Stories is the argument that we use narrative for everything. Our brain works best when we can create a context, even if that means we draw our own conclusions. Because of that, a game wouldn't even need to spell out a narrative to a player. Instead, the player will create a context and story in his own mind almost automatically.

Juul also describes some of the trouble with translating a Story to a Game, arguing that Story itself can only be presented through a medium. (Be it a book, movie, play or videogame.) However, when translating a story, or a linear experience to a game, some issues arise. Most notably that the player will always be active. He also argues that games are less proficient at using 'time' to their advantage. Whereas film, theater and literature can freely switch between tenses over the discourse of a story, games hardly do so. I can't say I agree with Juul here. Playing through a non-linear timeline, where the story switches between timelines, should prove the same problems as playing through a linear timeline. As Juul said, in games we play through events. Following that argument, it shouldn't matter if these events are offered to the player in a chronological fashion or not.

The last section of Juul's article admittedly confused me a little. It deals with avant-garde, experimental narratives, but he discusses these issues in such broad, general terms that it's hard to really see what he's getting at.

Game Design: From Blue Sky to Green Light
-Deborah Todd
Chapter 4: Story in Game Design -- The Thousand-Pound Gorilla


This is a 30 page chapter, mostly filled with interviews and observations from designers working for the larger studios. However, the first few pages of the chapter actually deal with Todd's views on Game Design, and on how story should be written for it. She starts off with an interesting point, arguing that no matter how you look at it, when you make a game, you tell a story. When you tell someone about a game you're making, you're telling its story. Who is the game about? What is the goal? What is the setting. According to Todd these characteristics are all related to story, and therefore, a game always has a story. I guess this all depends on your definition of story, but it's not one I would subscribe to myself. As Todd reasons, everything is story, which might be true, but that doesn't mean that story is also a narrative. Not every game is about a character, not every game is about a history, not every game is a series of sequential events.

Later on however, in a paragraph called "And then..." versus "And because..." She does make an interesting point but fails to truely come to a solid conclusion. While Todd argues that writing a story in an "And then this happened, and then that happened..." way is rather boring and shallow compared to a "And because of this happened that other thing happened" approach, she fails to point out whywhy this is. In my opinion, she makes a valid point in saying that the "and because" method makes for a more organic story, but she never says how this could be interesting for a good game design. As I see it, the "And then" approach is linear, more based on cinema and literature than anything. The "And Because" method would be a lot more practical for games as they give a reason as to why events unfold the way they do, allowing for variation and deviation from the linear path, as we can look at cause and effect.



When Designers Have Story Problems
-Jeff Spock

This Gamasutra article written by writer Jeff Spock lists five reasons why Designers shouldn't complain when story gets in the way of design. In short, he lists the following reasons:

1) The designers should have paid attention to the story earlier, and the fact that they have to change things is their own fault for not referring back to the story earlier.

2)The writer was put on the team too late, which is bad practice

3)Story, if done well, should be an instrumental part of the game. If this isn't the case, shame on the designers!

4)A writer understands that changes in design might ask for a change in story. Designers should understand that they are required to do the same when the story asks for it.

5)The story isn't just the writer's problem, it's the team's problem.

Now, when reading this, I have to say Mr Spock has some issues with priorities, at least in my opinion.

1)Perhaps they should have paid attention to the story earlier, if we assume the story is that important to the game.

2)Might be bad practice, but then again, if a writer is brought into the project this late in development, he can't really expect to go around changing aspects of the game that have already been produced.

3)If story is done well, it should be an important part of the design. That said, shouldn't the writer come up with something that matches the story rather than a designer having to accomodate the story in his game? This ofcourse all depends on the project itself, but in my opinion, story shoudl support design, not the other way around.

4)Pretty much the same as with point three. A writer should understand that he supports the game, not the other way around.

5)Very much so, but the writer is responsible for creating a story that fits within, and enforces the game design.

Conclusion

Alright, so at the end, what are my views on all of this? Where does story fit into games?

First of all, there's a matter of definition. Without defining what story means to me, it's hard to explain. To me, a story (within a game) is a sequence of narrative events (using characters, backstory and setting) that is driven by the actions of a player.

Not every game demands a story. Some games are perfectly fine relying just on gameplay mechanics and form. Games like Tetris don't need a story, and to a game like Castle Crashers story is mostly inconsequential and not instrumental to the final design.

Then there are games that use story. For example, take Mass Effect. But even then, a designer needs to be constantly aware of the fact that story is just another button to push and trigger an experience with the player, much like form does.

Keeping that in mind, story should always be written as a design, it should adhere to the same rules as game design does, meaning that it needs -function-. If a story isn't functional, if it isn't used as a 'button' to press, get rid of it. It doesn't matter anymore and you might just as well leave it out.

So in conclusion: Yes, story can be used succesfully as a button to push, as Mass Effect shows, but it can never be reason for making a game, nor can one expect a design to support a narrative.