Read that title with Cartman’s voice.
(Sorry, I didn’t find the way to embed it).
The video shows both Trey Parker and Matt Stone, creators of South Park, crashing into a narrative class in some university, giving a quite short but incredible useful lesson. Watch the video; the web page has some serious issues about buffering, but it’s short and it’s worth the waiting.
To sumarize, I can quote Parker:
… We can take these bits, which basically are the bits of your outline, and if the words “And Then” belong between those bits, you are fucked, basically, you got something pretty boring.
And he continues with:
What should happen between every bit that you’ve written down is either the words “Therefore” or “But”.
Those quotations are extremely wise, but not only regarding narrative, but game design.
I need to say that this entry is some kind of introduction because I haven’t developed a extense theory of what the “And Then”, “Therefore”, “But” approach has to do with games mechanically, but I think one could extract some useful techniques from it in order to go deep while you’re designing.
Let’s take first the narrative approach Stone and Parker have.
What they are doing in the class is to encapsulate in a rule of thumbs the principle of causation. “Therefore” and “But” between history bits basically chain those bits into a cause and effect timeline: This happens, and therefore this other thing happens, but this happens and therefore this happens.
Sounds kind of dumb and redundant put it that way, but cause and effect are the most basic ingredients of good narrative. “And Then” is not a forbidden expression. I realized that, for example, if you want to maintain two or more plot lines in a story, two or three “And Then” properly used could come quite handy (Stone and Parker used it when killing Kenny from time to time, and it’s funny that way). But three of those are already a lot, and they serve to separate different storylines, each storyline should has its own cause and effect chain based on “Therefore” and “But”, until they managed to become one unified storyline (if required).
That cause and effect chain is not that easy to achieve, because you can use a “Therefore” with totally unrelated things inside the inner narrative logic, and that’s a mistake to. Usually (it seems) in this cases “And Then” should fit better, so you know something is wrong.
As Stone himself says, a lot of movies, books, comics and TV shows out there are a sequence of “And Then”‘ and that’s not a story. There is a total amount of zero narrative in there. Videogames are a place when the “And Then” happens more than usual, but an special thing occurs when talking about videogames and narrative.
Let’s spend some minutes on that particular issue.
I pointed out in the last entry that in general, a narrative game has two stories: the designers driven one, and the players driven one. Valve’s designers made a little inside about it in this Portal Post-Morten. A way more detailed study can be read in this entry of Schreiber’s Game Design Concepts Blog.
The designers driven story (or Story-Story, as Valve’s designers call it; Embedded Story as referred by Schreiber) is the usual narrative we identify in games: the plot arcs, characters and dialogues. The players driven story (or Gameplay Story, as Valve’s designers refer to it, Emergent Story as called by Schreiber) is the sequence of actual and specific actions the players take while playing.
Tetris has no designer driven story: there is no narrative whatsoever. This title is what we call a non narrative game. Tetris is totally made of player driven story, you take those little tetris pieces, move and rotate them in specific ways until the game finishes somehow. That sequence of actions makes up a story that depends exclusively on the player. On the other hand, a game like Portal has a sequence of actions that conform a plot, with characters and dialogues that are a companion for the player driven story.
The questions that arises are: how different these stories have to be? how much separation between them has to exist, or how much of it it’s permitted?. Valve’s designers talk about the Story Delta, how much the actions directly driven by the player trigger actions in the designers driven story. Their conclusion is that delta has to be as little as possible in order to engage players.
I agree with that.
Do you want to see a game that I think is poorly design mostly because of a big story delta? I’m getting repetitive here, but there it goes.
Heavy Rain has a very big story delta, where mechanics are reduce to a big group of basics actions that, most of the time, have nothing to do with the story, or even the entire game (the Quick Time Event disease). Even though the game does a good job creating meaningful decisions moments (from time to time), those decisions has nothing to do with the game mechanically. As I said the last entry (link above), David Cage is taking elements of another media (cinema) to trigger a particular aesthetics, forgetting the idea to trigger that same aesthetics using game design tools. His upcoming game, Beyond: Two Souls, is going further down in that direction.
I’m not criticizing the mere existence of this kind of games. From a very formal point of view, Cage’s intention is not different from Adventure Games, like the classic Maniac Mansion, but that is another subject. Heavy Rain is a good exercise in game design, for better or worst. What I think is that it is time for David Cage to grow up a pair and make a movie, and be criticized by it instead of hiding his mistakes behind “a new media” tag. Seriously.
Dane Cook made a proficient argumentation on this subject. I invite you to read Shadow Emotions and Primary Emotions. I won’t use the terminology Cook had, but I will asume you have read the entry.
What has all this talk about desginers and players driven story with Parker and Stone’s assertions? Heavy Rain is a game full of “And Then”, both narratively and mechanically. From the narrative point of view, this comparisson makes sense, but what about from the mechanic point of view.
Let’s go back to the Tetris example.
One thing I’ve always critiziced about Tetris is that, in most of its implementations, the way the pieces appears has nothing to do with player performance. They are and bunch of “And Then”: the S shape appears, and then the L shape, and then the T shape and so on; there is nothing like: the player has made this kind of combination, therefore the L shape appears (with a little bit of randomness in the implementation). Some versions of Tetris follow a list, others are completely ramdon, both of them somehow managing to respect the general rule of “the I shape appears less often than the others”.
Something similar happens with the utterly famous Angry Birds. See, the fact that you can’t arrange those little birds’s order, but follow the given order provides the players with a lot of “And Then” moments. There is no strategy whatsoever as consequence of players performance. You throw this bird, and then throw the next one, and then, and then, until you manage to somehow guess the answer to the challenge. That makes easier the design labor, but is not a good way to engage players (which seems kind of contradictory given the popularity of this game).
Heavy Rain, mechanically (and again, narratively) speaking, is a sequence of “And Then” in the same way I’ve exposed above. On the other hand, Portal, due its low story delta, is more like a chain of cause and effect, welded out of a sequence of “Therefore” and “But”, both mechanically and narratively. Actually, mechanics and narrative are so close together that you can manage to treat them as one thing.
You have no portal gun at the very beginning, therefore you have to listen to GLaDOS, therefore you pass through the Portal, but the first red button appears, therefore you have to learn what to do with it… and so on and so forth.
Reading that last paragraph you can point out how linear this kind of games are (one of my biggest complaints about Portal). Portal doesn’t constraint player actions from a game control point of view, but its storyline is, in fact, very linear. There are game design reasons for that. However, if you look at more open but narrative games, like GTA IV, Fallout 3 and Bioshock, you would detect the same kind of cause and effect chain both mechanically and narratively in each separated plot arcs.
One good example I find out useful when speaking of Heavy Rain is Earthworm Jim. I love this game, it’s one of my biggest influence, but I realized, over time, that it’s very badly designed. This entry explains why.
What happens with Earhworm Jim that made it incredibly popular is that it has so much charisma and personality embeded to it. Mechanically, it has the same problem as Heavy Rain, it is a (sometimes annoying) sequence of “And Then”.
You learn to shot first, and then in the next level you have to learn this bungie mechanic, and then has to learn the space bike mechanic… and so on and so forth.
What Parker and Stone says about narrative totally applies to mechanics: if you create a series of “And Then” you have something pretty boring at best, pretty annoying at worst. Of course, why Angry Birds and even Heavy Rain work that well comercially, even when they are a series of “And Then”, is a matter of what Dane Cook talks about primary and shadow emotions, but a lot of it also happens as well in movies, books and TV shows.
There is no reason at all to avoid the duty of creating a “Therefore” and “But” chains, even when it’s a certainly difficult task to complete.
I have no idea of a method to come with “Therefore” and “But” welded mechanics, it’s extremely related of your particular game, but Valve’s principles of design as teaching activity (that I’ve also developed on this blog before) it’s a good start.
Any comments on this regard will be welcome.
P.D.: Totally unrelated to the post subject (but not to game design in general), but I always find interesting Stone’s appeareance in Michael Moore’s Bowling for Columbine.