The Impossible Dream

Play Flow First

by Hunter Logan
Jan 01,2003

Play Flow First

Before I begin, I want to thank Aeon and the other good folks at RPG.net for giving me the forum for this column. I think rpg.net is an outstanding site and I'm happy to be here. Thank you.

I've returned with a new message. The key to successfully designing games is sitting right in front of everyone who wants to do it. Most of us don't see it. We don't even know it's there. I think those who do know are busy designing games that actually work the way they're supposed to work. Play flow is the answer.

Play Flow

Play flow is the way the game is actually played. See, when we talk about game design, we often talk about what the players want or what the game is about. We craft clever mechanics and interesting mechanical devices. What's more, the best of these really are both clever and interesting. We sweat over character design and other design elements. Anyone who designs a game should do all of this, but all of this should really come later.

I have this idea that you can design the core of a game in about 30 minutes if the first thing you think about is play flow. Think about this. If you're anything like me, you want to design games that play differently than other games already on the market. That's why I want to do it, and I've observed that play flow is the unspoken reason many other people also want to design games. So many people want to design games, yet only a few people come up with anything worthwhile. I've made many stillborn attempts myself. I've also designed a game or two that sort of worked, but I wouldn't call them especially successful. Recently, I broke through the barrier, but it's only because I kept asking the same questions: Why? What's wrong here?

I think conventional thought about game design sets the wrong priorities. I think most people consider mechanics or character design first, not play flow. People come up with a really neat mechanic and then try to make play flow support it. People come up with excellent character design concepts and try to wrap mechanics then play flow around that. For most of us, it doesn't work. If it does work, it's probably a fluke. More likely, you'll find the game is broken in some significant way. It doesn't do what you want it to do because it can't do what you want it to do. The play flow is probably wrong because it was considered last. I have made the mistake and I have seen ample evidence all over the web that others make the same mistake. I think this is also true of some commercial game designs. This is no crime, but it's unfortunate. There must be a better way, and I think this is it: Instead of considering play flow last, consider Play Flow First. That is, let everything in the game support the play flow, not the other way around.

Let's talk about formal definitions.

A Play Flow is a set of actions that produce events that lead to either a decision point or a resolution point. (As much as I would like to take credit for this bit of thinking, others got here first. Ron Edwards and John Kim are equally responsible for planting the idea in my head for Play Flow First design. Ron planted his part in conversation and in many web discussions. John Kim planted his part in his descriptions of various roleplaying sessions on his Roleplaying Styles website. Brian Gleichman first defined the resolution point in his Alternate View of Gamism article.)

A player is anyone who is actively involved in playing the game. Unless otherwise noted, I make no distinction between the designated GM and other participants.

An event is any encounter or situation that occurs during the course of play. These usually involve the PCs and often result in a decision point, a resolution point, or both.

An action is anything a player does that has an effect on a character or causes a change in the game world.

A decision point is any point where a player chooses a course of action (makes a decision). The choice affects what happens in the game world.

For example, a group of characters take a prisoner. They may select from several choices. Whatever the players decide will have repercussions for both the characters and the prisoner. Here are some possibilities.

• Kill the prisoner.
• Torture the prisoner.
• Talk to the prisoner.
• Take the prisoner with them.
• Release the prisoner.
• Treat the prisoner as a long-lost friend.
• Do something completely different.

A resolution point, according to Brian Gleichman, is "that part of the game where conflicts are decided. A very common Resolution Point is a single battle. However any test of skill or the solving of a puzzle can also viewed in this way." I agree with Brian's definition, but I personalized his meaning. To me, a resolution point is any point that requires the use of one or more mechanics to determine the outcome of an event. A battle is a notable resolution point.

Mechanics are the processes written into the rules to determine what happens at a resolution point.

A mechanic is a self-contained play flow composed of at least two steps. The first step is usually a mechanical device. That's a function written into the rules to help resolve an event. Rolling dice, betting coins, and drawing stones are all examples of mechanical devices. Once the device is used, the second step is usually an evaluation to determine what happens as a result of using the device. A mechanic may also include functions such as a countdown.

Play Flow Overview

This is an overview of one possible play flow. It's historically common and very manageable.

• Description. The GM describes the locale and situation for the players.
• Clarification. The players ask questions about specific details of the description. The GM answers as appropriate.
• Decision Point. The players discuss what they want to do and decide on a course of action for their characters. This decision may spawn an event. If the players have difficulty making a decision, the GM may add an event to the game.
• Event. Finally, something happens. The GM describes the event and the players ask questions to clarify the situation.
• Decision Point. The players decide what their characters will do about the event. In this case, indecision is a decision as the GM may push things along as he sees fit.
• Resolution Point. The players' decision leads to a resolution point. Using the appropriate mechanics, the GM and players resolve the event.
• Repeat. This flow of play is repeated. When the players resolve an event, their characters make progress in the game world.
  
  

Mechanic Overview

This is an overview of a simple mechanic.

• Call Mechanic. A player, often the GM, calls for the use of a mechanic as stated in the rules.
• Use Mechanic. Players roll dice, bet coins, make declarations, or do whatever else is needed to make the mechanic work.
• Evaluate Results. The players use this to determine what actually happened in the game.
• Continue Play. Once the outcome is determined, the play flow continues.

A Play Flow with Mechanics

Event resolution is part of a play flow. In many ways, it's a play flow nested within another play flow. This can also be done with a flowchart. This example demonstrates the idea of play flow and outlines what might happen when some PCs gets in a fight. I left the exact resolution methods undefined because they're not important to this part of the discussion.

• Description. Two characters are walking through a run-down neighborhood. It has empty storefronts all over. Broken-down and burned out cars litter the street. The alleys show signs of people living in cardboard boxes.
• Clarification: The players want to know who else is around. The GM notes that a group of motley-looking young men is milling around at the next intersection. They're harassing people passing by. They're probably a gang of thugs.
• Decision Point: The characters could go around this obvious trouble spot, but the players want to see what will happen. They decide to have their characters walk right up to the thugs.
• Event: The characters encounter the thugs. As the characters approach, the GM informs the players that the thugs are making insulting comments and saying something about paying an "intersection tax."
• Decision point: The players could decide to have the characters pay the tax or parley to prevent combat, but the players prefer to fight the thugs.
• Resolution Point: The players play their characters and the GM plays the thugs.
• Roll Initiative. The players roll dice for their characters. The GM does the same for the thugs. The combatant with the highest roll wins initiative and may resolve his actions first. In the result of a tie, the rules may specify some sort of tiebreaker. Some combatants may have more than one attack. These are resolved at appropriate intervals during the countdown.
• Initiative Countdown. The GM counts down initiative starting at the highest result. At each count, all attacks are resolved as appropriate.
• Resolve an attack. The player controlling the current combatant declares a target. He then rolls dice for the attack. The GM uses the die roll to determine the result of the attack.
• Resolve next attack. If other combatants are allowed to attack, their attacks are resolved as described. When no more attacks remain, the countdown continues.
• Continue Countdown. While Initiative is still above 0, return to step a) Initiative Countdown. When initiative reaches 0, go to step 2) Continue Play.
• Continue Play. If combatants remain willing and able to fight, return to step 1) Roll Initiative and repeat the process for the remaining combatants.
• Play Continues: When the battle is over, play continues. The GM updates the situation for the players and the players decide what they want to do next.

Prioritizing Play Flow

It's time to step back and put this in perspective. Some people are more methodical than others in their approach to game design. Your effort will not fail because your first thought about your new game design was something like, "I want a game about being the living dead on an alternate earth. And I want to use a mechanic where people draw stones from a bag." As far as I'm concerned, that's as good a start as any, but I'd bet money you want to write it in such a way that it will work right off. I think you can do that if the next question you ask yourself is, "What's it like to play this game?" The answer is to figure out the play flow. This doesn't guarantee design free of struggle, but I think it increases the chance that you'll be able to bash together a game design that really works in very little time. Inspiration is unpredictable. The creative spark has a mind of its own, but formal thinking is very reliable.

Next installment, I will look at something I call Balance of Power and discuss how that relates to play flow.