contents can replace an index, but the absence of both is a huge error. The problems are
compounded when the document is as long asWar and Peace. The primary reason for
the existence of game design documents is to allow team members to quickly look up
information about a section of the game they are working on. If a programmer wants to
know how the AI for a particular enemy is going to work, she needs to find that informa-
tion quickly and easily. If she cannot find it, she may just make something up. Similarly,
when an artist wants an idea of the textures that will be needed for a given area in the
game, she wants to be able to find where that area is described as quickly as possible.
Design documents are not read like novels. No one starts at the beginning and comes
out at the end. Primarily, design documents are reference materials, and if team mem-
bers cannot easily retrieve the data they are seeking, they are liable to give up.
However, once one starts hunting through one of these Back-Story Tomes, one is
startled to find that, indeed, there is no information about the gameplay in there. It is all
back-story. And at 500 pages, it is far more back-story than most computer games will
ever use. The history of all the characters in the game, the friends of those characters,
and all the relevant parents and siblings are all described in minute detail. It may be
very interesting stuff (though usually it is a disorganized mess), but in the end the
reader is left with very little idea of how the game is supposed to function. These docu-
ments are often the sign of the frustrated novelist or a writer from a non-interactive
medium who does not truly understand game development. A lot of games make story-
telling one of their central concerns, and a story bible can be quite useful to game
creation. In such a case, it makes sense to discuss the game’s story in the design docu-
ment to some extent. But first and foremost, a design document is supposed to contain
the game’s design, which is very different from a game’s story. Remember, your most
important consideration when writing a design document must be, “what can the player
do?” Though these tomes are very significant in terms of weight and will probably
impress the venture capitalists, the programmer who has to work with such a docu-
ment as her only guidance is going to end up designing the game herself.
The Overkill Document.........................
Some designers think they can describe every last aspect of a game in the design docu-
ment. It is certainly true that many design documents lack the necessary detail to be
useful, as we found in the Ellipsis Special Document discussed above, but at the same
time, going to an excessive level of detail can be a waste of the designer’s time as well
as that of the person who has to sift through all of that excess information. Further-
more, excessive documentation can lead to the illusion that the designer has created a
complete, thorough document, when in fact she has gone into far too much detail about
certain subjects while skipping other areas that need to be addressed.
For example, suppose that the game being documented has a number of characters
that perform certain actions in the game-world. Say the game has townspeople, and
they need to walk around, sit down and stand up, talk to each other, and sleep. The doc-
ument should describe these behaviors in the AI section. A truly thorough document
might break this down into separate animations: stand from sitting, sit from standing,
idle sitting, idle standing, walk, converse with hand gestures, and so on. Probably this is
not necessary, since good animators and artists will be able to break this down better
than a designer can. But some designers may go overboard and actually sketch or list
376 Chapter 19: The Design Document