Designer's Notebook: Designing with Gameplay Modes and Flowboards

Before I start this column, I have two announcements. First, it's about time for another edition of my "Bad Game Designer, No Twinkie!" columns. (See my previous installments for game misfeatures, design errors, and personal annoyances covered in the past.) If you've got a game design gripe you'd like to get off your chest, send some E-mail to [email protected]. Please be sure to mention a game that the Twinkie Denial Condition appears in. I can't guarantee that I'll use it, but I would definitely like to hear about it.

Second: if you are the chunky, dark-haired fellow with a maroon shirt and an Armenian last name who chatted with me on the mezzanine of the San Jose Convention Center at the Game Developers Conference, and accidentally left behind a signed copy of Richard Rouse's book Game Design: Theory and Practice, I have it for you -- drop me a line.

One of the questions I get asked a lot is, "How do you start designing a game?" It's my belief that players play games -- large games, anyway -- to have an experience that they cannot have in the real world. The thing to do first, then, is imagine the nature of that experience. Once you have the experience in mind, you can move on to defining and documenting the gameplay. And, not coincidentally, another of the questions I get asked a lot is, "When you're documenting a game design, where do you start?" This column is part of the answer.

A central idea at the heart of most videogames is the concept of the gameplay mode. This notion is intuitively obvious, but I've never seen an article or book that describes it directly, so here goes.

When a player plays a videogame, he experiences three things directly:

1) A means of perceiving the game world, which I call the perspective because it's usually defined by a camera looking at 2D or 3D space from a particular point of view.

2) A means of influencing the game world, of projecting his will into it, which I call the interaction model. There are many of these, but two of the most common are the "avatar-based" and the "omnipresent" model, the former found in most action games, the latter in most board and war games.

3) The gameplay itself -- the challenges he faces and the actions he may take to overcome those challenges. I prefer a somewhat more rigorous definition than Sid Meier's "interesting decisions" -- if a piece of interactive entertainment does not offer challenges, it's not really a game. To me, challenges and actions make up gameplay, even though the definition is not perfect for all cases.

The conjunction of these three elements -- perspective, interaction model, and gameplay -- constitutes a gameplay mode, a particular way of playing the game. If any one of the elements changes significantly in the course of playing the game, then the player has moved into a new gameplay mode.

This description may seem a bit abstract, but a simple example will make it immediately recognizable. In a car racing game, the player spends much of his time driving the car. The perspective is usually out the windshield of the car; the interaction model is through treating the car as a mechanical avatar; and the gameplay consists of certain challenges (driving it safely, conserving fuel and tires, and of course finishing first) and actions (steering, accelerating, and braking) that address these challenges. The business of driving the car is a gameplay mode, and in most cases it is the primary mode.

Many serious racing sims include another gameplay mode, however, in which the player can make adjustments to the car to try to improve its performance. The perspective in this mode is usually a schematic diagram of the car -- the player isn't looking at the game's setting at all. The interaction model is neither avatar-based nor omnipresent, but more that of a mechanical engineer working at a computer-aided design station. And of course the challenges and actions involve finding the optimum configuration of all the car's various characteristics for maximum performance. Really dedicated players may spend 50% of their time, or even more, tuning the car and adjusting it for the current track and weather conditions.

Some games, such as Tetris or most adventure games, have only one gameplay mode. A few have two in which the player spends near-equal amounts of time. For example, in some war games you have to organize your troops for battle first, then actually fight the battle in a second phase. Nine Men's Morris also includes two phases, one for placing the stones and a second one for moving them.

Complicated games can easily have a couple of dozen, or even more, gameplay modes. In an American football game, choosing and executing a single pass play typically involves six modes all by itself: selecting a formation; selecting a play; calling signals and the snap; backpedaling, choosing a receiver, and throwing the ball; maneuvering the receiver under the ball and catching it; and running downfield avoiding tacklers. In each of these, the perspective may not change, but the challenges facing the player and the user interface that implements the actions both do. The modes are avatar-based, but right in the middle of the play, the avatar switches from the quarterback to the receiver!

The boundaries of a gameplay mode are not sharply defined. Switching the camera from cockpit view to chase plane view in a flight simulator isn't really significant enough to call it a mode change. On the other hand, it might seem that Pac-Man has only one gameplay mode, but actually I think there are two: running away from the ghosts when you are vulnerable, and chasing the ghosts when they are vulnerable. Your challenges are sufficiently different in each (catching versus avoiding being caught), that even though the perspective, interaction model, and available actions are the same in both, they constitute different modes. I don't insist upon it, but from the standpoint of documenting the game, I think it helps to make the distinction.

In addition to the active gameplay modes, most games also include non-interactive modes as well-movies, high-score tables, mission briefings, and so on. For our purposes they're all gameplay modes, but some of them have no challenges or actions; they're only included to present information. Even a pause menu is a gameplay mode of a sort.

So the answer to the question, "where do you begin documenting a game design?" is simple: don't begin at the beginning of a game. The beginning of the game is the splash screen, or maybe the intro movie. Neither is very important, because they're non-interactive and they don't last long. The place to begin is at the primary gameplay mode, the place that the user will spend most of his time -- typically 60%-80% or more. This is the heart of the player's experience, the part of the game that it is most essential to get right. Define the primary gameplay mode first of all, then add others as necessary.

As a game progresses, it frequently moves from one gameplay mode to another, depending on what's going on in the game. These transitions can either occur as a result of player actions -- the player calls time out in a sports game to send new athletes onto the field, for example -- or automatically as part of the natural flow of the game. (When a level is complete, most games automatically move on to a summary screen to let you know how you did.) The relationship among all these modes is the game's structure.

The best way to document the game's structure is with a flowboard. The word is a combination of "flowchart" and "storyboard." Like a storyboard, it consists of a number of pictures, but unlike a film storyboard, it's not a linear series. Rather, each picture is a sketch, or mockup, of the screen in one particular gameplay mode. Under the picture is the mode's name and a brief description of its perspective, interaction model, challenges, and actions. Connecting the pictures together are arrows showing how the modes switch from one to the next, with a text notation to indicate when and why the transition takes place.

Figure 1 shows a simplified version for an old-fashioned coin-op game, using boxes without the pictures.

There's no victory condition in this flowboard--the game assumes that the player will eventually lose sometime, in classic arcade fashion. It also lacks a feature allowing the player to insert a coin to continue play, because the earliest arcade games didn't have that.

Notice that this flowboard doesn't actually document the levels themselves. It's intended to describe the game's functionality, not its content. The point of the flowboard is to convey to the programmers and user interface designers the key screens and modules that they will need to create, on the assumption that every level is functionally identical to every other level (as the old arcade games were). You could include each level as a separate gameplay mode, but then you'd have a very large flowboard with a lot of redundant material in it that the programmers don't need. It's better just to document the key modes (including the other housekeeping or non-interactive screens), and define the levels in a separate document. Similarly, in a large PC or console game with a linear storyline, you don't need to document the story itself in the flowboard unless the game's perspective, interaction model, or gameplay change significantly as the story progresses. Instead, just write the linear story down in a separate document.

On the other hand, if you have a branching storyline but the functionality of the gameplay doesn't change much from one episode to another, you should document the story in a separate flowboard -- a narrative, as opposed to a functional, flowboard. (Wing Commander was a good example of this: the gameplay was the same for each mission-flying a starfighter -- but the storyline branched based on the outcome of the mission.) The programmers will need to see the narrative flowboard too, to know which branch of the story to present next, but it will only complicate the coding process (and the flowboard itself) if you have narrative branches intermingled among the functional branches.

The most complicated situation of all occurs when you have a branching storyline whose gameplay does change significantly as the story goes along. Then you have no choice but to document them together as a single, gigantic flowboard. I don't think I've ever seen such a game. For one thing, it would be difficult and time-consuming to program; it already takes long enough to build a game with only one or two kinds of gameplay in it. For another, most players like their game to stick to a single genre, and genres are defined by gameplay. If your story requires the game to switch between several kinds of radically different gameplay, most players are going to be put off.

Gameplay modes and flowboards are at the heart of my game design workshops, and indeed my whole approach to designing games. Back when I was working for p.f. Magic, we used to draw each mode on a single sheet of paper and stick them up on the wall, then add more sheets to show the arrows running between them. This gave us lots of room for drawing the screen mockups and penciling in notations, and the whole team could see the flowboard at once. If we needed to rearrange something, it was easier to pull down the sheets and move them than it would have been to edit a big drawing and print it all out again.

Give it a try!