Saturday, October 31, 2009

Blogs of the Round Table: Denouement as gameplay

I just discovered this thing called Blogs of the Round Table. Each month, they have a topic (about game design) and anybody with a blog can address it and join the discussion. This month's topic is: "How can the denouement be incorporated into gameplay?" (http://corvus.zakelro.com/round-table/). The assertion is made that denouement in video games is frequently either missing or contained in a non-interactive final cutscene.

What is denouement? It is a word that has far too many vowels in the middle. The etymology of the word has to do with untying knots, and the meaning of it can be described in english as "tying up loose ends" in a story. In the denouement, the murderers are revealed, everything is explained, people die and/or get married as needed, and, in the case of most sitcoms, everything returns to be exactly the way it was at the beginning of an episode. A "good" denouement, though, is supposed to demonstrate the consequences of everything that happened before it, so the sitcom example might not apply.

There are several things about the normal structure of games and the concept of a denouement that make them less than compatible.

Interactivity means gameplay, and gameplay implies the act of solving interesting problems; on the other hand, denouements can be thought of as the revelation of interesting solutions to the game plot as a whole. So it is natural that on a game's timeline, there is usually a very slim intersection between plot-related gameplay and a denouement, right when the interesting problems turn into interesting solutions. (I think this points to a set games that can - and sometimes do - have denouements that are satisfyingly incorporated into gameplay: mystery adventure games, where the player's character usually resolves the plot through standard adventure gameplay)

So, gameplay turns into cutscene right at the moment the denouement comes. This is usually, but not always, dissatisfying (the Fallout series, for example, have endings that have been well-received by gamers: a series of cutscenes that show specific consequences of the player's choices at different points in the game.) But denouements sort of feel like cutscenes even in non-interactive media: they are very expositionary; they take the focus away from action or dialog, take the control away from the characters; they often change the unspoken dramatic rules() and mess with time flow by compressing it or jumping around to the "interesting" bits, like a birth or death or marriage of some characters many years after the game.

This sort of thing - especially the messed-up time flow - makes it difficult to make a denouement that is playable in a sensical manner under the same gameplay rules as the rest of the game. One could make the denouement interactive in a different way than what the player had been experiencing before then, a sort of denouement mini-game, but does the player want to do that right before finishing the game (and usually right after getting through the climax)? In fact, does the average player want to have to do *anything* after beating the final boss?

They might not; partially just because that's the way they're used to doing things - beat the boss and go home - which alone is no reason for things to stay that way. But also because the natural flow of a game is different from the natural flow of a story: a game's flow is shaped by a difficulty/learning curve, which (ideally) ramps up steadily until the end, and by the end makes the player feel like they've learned a new skill (namely, how to play that particular game); a story is shaped by an action curve, which rises, climaxes, and then falls again. So, the glaring difference between the two shapes - the falling action and denouement - is typically made up for in a final cutscene.

Because of this discrepancy in flow structures, anything interactive that does come after the climax of the action will likely feel "optional" in a way, not really part of "finishing the game". That's not necessarily a bad thing in itself, but it's something to keep in mind: if you do have an interactive denouement in your game, it shouldn't feel like one more chore to complete before you get to the end; rather, it should be more like an interesting thing that comes *after* the end, sort of like an unlockable for beating the game that increases the replay value.

I think one of the most obvious (and also the most appealing to me) ways to include an interactive denouement in a game is to let the player explore the world after the game is over. I always get frustrated with RPGs that do the opposite: they kick you out to the main screen right after you beat the game, and if you want to explore for any reason, you have to load an earlier save and hope that it wasn't somehow restricted in gameplay because you were so close to the end already (I'm looking at you, Magic Pengel!) It's not difficult to imagine being able to go back and talk to all the people you helped out (or hurt) in an RPG, and see how their lives turned out, or to go through environments you've been to before and see how they've changed since you saved (or destroyed) the world. This doesn't just apply to RPGs though: in any sort of game, the designer can imagine how the resolution of the main plot line would affect the existing levels (or what have you) and let the player go back and re-experience the "resolved" game. A big part of that would probably be revising the gameplay rules to remove part of the conflict, partially to lower the difficulty to exploration level and partially because, well, the player was supposed to resolve the conflict by finishing the game.

Bonus thought:
When talking about games, denouement doesn't just have to apply to the plot or story of the game. Since gameplay is inherently about conflict and problem-solving, we can expand the definition of denouement to be about the resolution of any part of the game structure. For example, picross is a puzzle game where you are given a grid of cells and have to figure out which of those cells are colored black and which stay white. When you are done coloring in the black cells, they make a picture. This can be considered a denouement in that you get a meaningful resolution to the problem at hand. Also, if beating a puzzle game unlocks some sort of "zen" mode (no time limits or goals other than to keep playing and staying alive), this is very similar to the "exploration of a resolved game world" denouement described above.

Bonus thought #2:
All of the thoughts above describe letting a player interact with a denouement that was pre-determined by the designers of the game. It would be interesting to instead design a game where the player gets to manipulate or create his own denouement. I'm personally particularly interested in a game design where the player gets to enact a sort of ret-con.

Tuesday, October 13, 2009

Put the quarter in the jar! (on payment and monetizing models)

There's this cartoon I like, Ed Edd 'n Eddy. It's pretty obscure, even though it "is currently Cartoon Network's longest running series[citation needed]".

The Eds are these kids who are constantly trying to get money for jawbreakers by running scams (not that I'm comparing video games to scams). One episode starts with a neighborhood kid (Johnny) minding his own business, when the Eds suddenly run up to him and frantically start telling him to do all sorts of crazy things in sequence (put the marshmallows in the tuba! now shoot the balloons! shoot the ballons!!!). Johnny has a lot of fun doing all these things, until at the end, the Eds hand him a jar and yell "Put the quarter in the jar, Johnny! Put the quarter in the jar!" Naturally, Johnny doesn't comply. He hands the jar back and says "Nice try, Eddy." Why? Well, mostly because this is a cartoon about how the Eds always get screwed over and fail to get any money, not a commentary on game payment models.

Nevertheless, I thought of this scene while contemplating how different payment systems affect game design and player enjoyment. Specifically, I was thinking about the difference between "Pay first, then play" models (like purchasing a game in a store or online, or even arguably subscription plans) and "Pay during or after gameplay" models (micro-transactions, shareware)

When I'm playing a game of the latter type, I often feel like a "put the quarter in the jar" moment is coming on, and the things I'm going through right now were put there in order to pave the way to the payment moment. For example, I might wonder, "why do I have these 10 extra-special doohickey points when I need 100 for most useful things, and how do I get more?" and the answer is, because they want me to buy more with real cash. Or I might try out a certain "optional" part of the game only to find that I need to feed it a steady stream of cash in order to have any success with it. This kind of thing puts me on guard and makes me enjoy the game less.

On the other hand, when I'm playing a game that I've already fully paid for (at least for the moment), I know that the design decisions I encounter are there for gameplay purposes, not "funneling me into paying some money" purposes.

I'm not saying that the free-to-play/shareware payment models are bad - each payment model has its own drawbacks for the player, if only because the player has to pay at some point in any case. But this "put the quarter in the jar!" feeling is something to watch out for when designing micro-transaction-like games.

Car Hero

This would be a device that went in place of a car stereo (and could also double as a car stereo). As the name implies, it would be a music game. The feedback would be mostly auditory and qualitative rather than score-based, and the game would work with the user's songs. So really, it'd be more like a cross between Wii Music and Lips (or Audiosurf/Harmonix's Phase) than Guitar Hero.

The auditory feedback can include both adding onto/"creating" the music (as in Wii Music) and sound effects that signify how well you are doing like fan applause/cheering.

For input, the driver's only option would be voice (singing, or possibly any sound effects that seem to fit the music), while the other passengers might have some sort of device which they can use to bang on like drums, or pretend to strum, or other things... whatever works. This would all be extremely drop-in, drop-out friendly, the players can switch "instruments" by just starting to do something different, and they can feel free to stop and start whenever, there's no failing ever. However, there might be "bonuses" (in the form of triggering certain feedback) for unison things, too.

Since the audience is pretty much captive, I don't think the game needs a lot of "game" (vs. toy) elements like scores and progression and such that typically hook and retain players, just immediate silly fun.

It would also be cool if passengers could plug in their mp3 players with USB cables and upload songs (or even choose from the ones already in the system!) to automatically form playlists (that is, if several players want to choose songs, the game would decide which songs and in what order to play and such)

BFP

"Breadth-first play" is a combination of "breadth-first search" and, uh, "play". As in gameplay. It refers to the way I tend to play games: in breadth-first search of a tree graph, you start with the root node , then systematically search *all* the nodes of the next level, only then go on to the next level, search all the nodes there, and so on. This is the way I play games which allow any deviations from the main plot line/action sequence: I want to try out(and maybe complete) *all* the side missions and activities available at a stage of the game before I willingly finish that stage and go on to the next.

Anyway, this may or may not be directly related to the things I will talk about here, it's just a cute term that (like this blog) has to do with video games and me.