The design document and its creation are discussed in more detail in Chapter 19,
“The Design Document.” You can find sample design documents in this book’s two
appendixes.
Flowcharts................................
Flowcharts may often be included as part of the design document or as separate docu-
ments. In game development, flowcharts have two primary uses. The first is to track
the players’ navigation of out-of-game menu options, such as those players use to start
a new game or load a saved one. Flowcharts can also be used to chart the areas the play-
ers progress to and from in the game, particularly in level-based games. Beyond these
most obvious applications, flowcharts can be quite useful for visually representing the
results of any decisions players may get to make in your game. Flowcharts are a means
for visually representing a chunk of gameplay, whether micro or macro, and can often
evolve into full decision trees with lots of branches, each representing a player choice
that leads to new choices or loops back to previous decisions. These visual representa-
tions can be helpful not only to a designer trying to figure out what the consequences of
a player’s actions will be, but also for communicating the sequence of events and
choices to other members of the team. With complex scenarios involving a lot of
branching, a flowchart representation will be much more effective at getting your ideas
across than what you will be able to convey with text alone. Flowcharts can be either
handmade or developed using various flowchart creation tools, such as Visio.
Story Bible................................
For games that tell stories, some amount of that story must be included in the design
document. Certainly a summary of the game’s overall story is essential, and a thorough
description of the game-flow will need to include parts of the story, but the design docu-
ment often cannot include it all. This is especially true if the game being developed
involves a complex story line with a variety of characters and locations, or if the game
takes place in a universe with a specific history. A story bible may be the best place to
document this information. Often the author of a game’s story will have in his mind a
vision for the universe and its inhabitants beyond the scope of the game, such as where
game characters come from and what their motivations are, and how the game-world
came to be in the state it is in when players encounter it. What the players experience
may be only the tip of the proverbial iceberg, with the story’s author having in mind ten
times more detail about the game-world than is actually communicated to the players
through the gameplay. Other aspects of the universe may only be hinted at. By having a
complete plan for the game’s back-story, even if the players do not directly learn all of it,
the story’s writer will have a much better chance at keeping the game’s narrative con-
sistent and plausible.
A story bible, then, is a good place to document a game’s potentially extensive
back-story. Separating this information from the design document proper avoids bur-
dening it with a lot of information that is less central to the game’s creation. Weighing
down a design document with a lot of back-story is an easy way to give it perceived
depth and completeness, but can hide the fact that the specification fails to fully cover
game mechanics and other more vital information. Nonetheless, the back-story is still
Chapter 17: Game Development Documentation 311