behavior of the AI or weapons and balance them properly. Statistics that you come up
with in preproduction, where you have no real chance of play-balancing or trying them
out, are a waste of your time as well as that of anyone who might have to read them over.
Instead, try to write descriptions of the game elements in question and their rela-
tion to the other elements. How do they compare in difficulty to each other? What traits
does a particular AI agent have? Is this one more or less likely to run away in combat?
Which AI capabilities will this element use and to what intended effect? How do the
entity and its various effects appear to the player? How big is it compared to other
objects? Include enough information for a programmer to understand what code will be
required for the entity and sufficient description that an artist will be able to make a con-
cept sketch. You want to provide as much useful detail as possible without overdoing it.
Readers, whether artists, programmers, or other designers, will know when you are
just documenting for documenting’s sake, in which case your document stops being
practical and useful. Do not waste their time by making them read reams of fluff to get
the information they need.
Story Overview..............................
Though not strictly necessary for a design document, I think having a brief Story Over-
view can be quite helpful in a design document, assuming your game has a story at all.
Properly written, the overview provides all of the document’s readers with an
easy-to-read narrative of what transpires in the game. Much like the design document’s
overview, the Story Overview is a quick way for everyone on the team to understand
the story’s “big picture.” To achieve this, you must keep the overview to an easily read-
able length while trying to include all of the major story points. A couple of pages should
be sufficient, though this may vary depending on the complexity of the game’s story; a
shooter might only require one page, while an RPG might take a few more.
Certainly you do not need to include all of the game’s sub-quests or describe every
conversation players will engage in or every character players will meet. Try to make
the Story Overview as compelling and readable as possible, so people will want to read
it. While the Game Mechanics section may be difficult to read with its bullet-point lists
and attention to detail, your Story Overview should be a pleasure to read. Indeed, if it is
not a pleasure, try to figure out why not. Is it because your story is not that compelling?
Do you need to refine and improve it in order to make it more interesting?
Game Progression............................
Depending on the nature of the game, the Game Progression section may well turn out
to be the longest in the design document. This is where the game designer breaks the
game down into the events players experience, and how they change and progress over
time. This section will provide a guide for both the art team and the level designers as
to what types of environments they will need to create for the game. The level design-
ers take this section as a guideline for what each level is supposed to include and then
fill in all the details as they build out each level, bringing all of the components of the
game together.
For many types of games, including RPGs, RTS games, first-person shooters,
action/adventures, and mission-based flight simulators, the Game Progression
Chapter 19: The Design Document 371