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@example.com.
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
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
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
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
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!