the individual animation frames. This is absurd. There is no way to know in the design
document stage how many animation frames will be required for a given animation.
This sort of decision can only be made and adjusted during the game’s production. Not
to mention that listing animation frames is insulting to the animator who will only feel
demoralized by this degree of micro-management. Furthermore, the design document
should stick to gameplay design, and not veer into the territory of the art bible or other
art documentation.
Another example might be what I call “balancing data.” These are the actual statis-
tics for the weapons, items, and characters found in the game. The design document
should probably list what different attributes weapons and characters will have. For
instance, a weapon might have a range, accuracy, number of shots, and rate of fire. Fur-
thermore, the design document might want to describe the qualities of a given weapon:
“The Double Barreled Shotgun has a short range and a low accuracy, but does a large
amount of damage in a large area.” However, actually listing the values for a weapon’s
attributes is not very useful in the design document. Saying “Shotgun Accuracy: 2”
does not really serve any purpose since the number “2” does not have any context and
therefore no meaning. These values are best determined when the game is actually
functioning, when a designer can balance the weapons as they will be used by the play-
ers and thus the designer can experiment with different settings to achieve the desired
effects. Creating large tables full of data before this information is actually testable is by
and large a waste of time. Filling in a chart quickly may be a way to convey some raw
ideas that were hard to describe through words alone, but at best such a table is a first
pass that will no doubt change many times before the game ships.
As with animation minutia and precise balancing data, source code also does not
belong in the document. Designers who start writing out algorithms in their design
documents are going too far. It does not matter if the designer is also a programmer.
There should be no code, not even pseudocode, in the design document. Including code
will only serve to bloat the document and distract from omitted information that needs
to be covered. Some simple if-then-else type logical explanations may be useful and are
completely appropriate. Such examples may help communicate all the contingencies to
the person actually writing the code, and if nothing else force the designer writing the
document to consider all the possible cases and outcomes that the game will need to
support. But by the time the examples start looking like compilable C++ code, you
know your document is overdoing it.
If there is any useful information in the Overkill Document, it is so hidden in the
river of useless data that team members will be too intimidated to look for it. The
author thinks that she can preplan everything, and that she is far more talented than
any member of her team. While such excessive attention to detail can be impressive to
those who do not really know what they are doing, a design document that goes too far
will only infuriate the team that has to work with it.
The Pie-in-the-Sky Document......................
These design documents often have noble intentions with grand ideas for truly magnifi-
cent gameplay. Sadly, the writers of them typically lack any technical grasp of what the
computer is capable of or what a team of twenty people is likely to accomplish in a year
and a half. As a result, these overly ambitious documents put forth fancy ideas with no
Chapter 19: The Design Document 377