members referring to it throughout the game’s development. Producers will often use
the design document as a springboard from which to schedule the project. A well-writ-
ten and complete document can also be of vital importance when a game is
subsequently converted to another platform by a different development team. The doc-
ument can serve as an ideal reference tool for this new team to understand how the
game is supposed to function as they start porting it to a new system, assuming it is
kept up to date over the course of the project.
Whereas a functional specification for, say, a spreadsheet application can be
extremely detailed and complete, a design document for a game is necessarily less
complete because of the more organic, dynamic, and iterative nature of game develop-
ment, as I discussed in Chapter 15, “Getting the Gameplay Working.” As a designer
working on a large team project, the design document will be the primary specification
with which you will need to be concerned. The guts of a design document are the detail-
ing of game mechanics: what the players are able to do in the game-world, how they do
it, and how that leads to a compelling gameplay experience. Design documents typi-
cally also include the main components of whatever story the game may tell and a
detailing of the different levels or worlds the players will encounter in the game. Also
included will be lists of the different characters, items, and objects the players will
interact with in the game-world. One can think of the important aspects of the design
document as not dissimilar from what a journalist looks for in a news story: what the
players do (which actions the players can perform), where they do it (the game’s set-
ting), when they do it (at what time and in what order the players must perform
different actions), why they do it (the players’ motivations), and how they do it (what
commands are used to control the game).
The design document can also be defined by what it does not include. Most of the
content contained in the other documents listed in this chapter should not be found in
the design document, including the bulk of the information found in the script, the tech-
nical design document, and the art bible. In particular, a design document should not
spend any time describing the game’s development from a technical standpoint. Plat-
form, system requirements, code structure, artificial intelligence algorithms, and the
like are all topics that should be covered in the technical design document and therefore
avoided in the design document. The design document should describe how the game
will function, not how that functionality will be implemented.
Similarly, discussions about the marketing of the game, explorations of how it will
be positioned compared to other games in the marketplace, and sales projections are all
inappropriate in the design document. In addition, schedules, budgets, and other pro-
ject management information should be left out. This information should certainly be
recorded in some documents, such as the pitch document or project schedule, but it
should be strictly excluded from the design document. I would think that such an exclu-
sion would be obvious to anyone undertaking a design document, but I have seen many
design documents that spent half their pages considering how the game will be sold.
The design document needs to describe how the game functions so that someone
working on the development team can see exactly what he needs to create. Including
materials that are more about the business side of the game’s development will only get
in the way of more appropriate information.
310 Chapter 17: Game Development Documentation