instead of several. Often, if the same gameplay mechanism is described in detail in
more than one place, when it comes time to make a change, only one of the descriptions
will get updated. This leaves the other description out of date, thus resulting in an
internally inconsistent document. Nothing is more frustrating to the reader than to find
contradictory information in the design document. Inconsistent information in a speci-
fication can also throw up a red flag for producers, who will begin to question your
competency to develop a game when you cannot seem to keep your facts straight.
Many people like to read design documents on their computer, as it allows them to
search for words and navigate the document more easily than with a large heap of paper
on their desk. For these people, it makes sense to include hyperlinks wherever appro-
priate. Most modern word processors make it easy to create links from one part of your
document to another, allowing the reader to quickly navigate to another relevant sec-
tion. This can be quite helpful as you try to avoid repeating any more of your design
than is absolutely necessary. Instead of repeating, include a hyperlink to the pertinent
location so that the reader can jump there if she needs to remember how a specific sys-
tem functions. A Wiki hypertext system can be great for allowing you to easily link from
one part of a document to another, or, more often, to break your big document into
smaller chunks that can all be interlinked easily. Wiki also allows you to easily link to
other content that does not belong in the design document, such as the technical design
document for a given feature or the art bible that shows what a particular character
looks like.
As you write your document, you want to write as well as you possibly can, but
keep in mind that the design document is supposed to be a reference document for the
creation of an entertaining game, not an entertaining document in and of itself. You
want your writing to communicate the information necessary in as concise and succinct
a manner possible. Do not spend a lot of time worrying about making the document
stimulating reading. No one is looking for excitement when reading the bulk of a design
document; they are looking for information. I usually try to make the Introduction and
Story Overview the most readable sections of the document, where someone could
actually sit down and read through those sections and be interested while doing so. But
for the rest of the document, you will be successful if you simply manage to include all
of the information necessary. Spending a lot of time dressing it up with fancy verbiage
will do nothing to improve your game. Similarly, though you should try to write as cor-
rectly as possible, do not spend too much time worrying about editing the document for
grammatical mistakes. If the members of your team — your document’s audience —
are able to read it and get the information they need, they will be happy. They really will
not care if you used a gerund correctly or not. That said, if your document is so dry or
badly written that no one can stand reading it, people will be less likely to turn to it for
the information they need. Furthermore, if you are writing your design document as a
really large pitch document that you hope will convince people to fund your project, you
may need to be a little more refined and sales-oriented with your writing, while still
keeping the document useful and relevant for the development team.
As you write your document, it will be awfully tempting to compare elements of
your design to other games, certainly ones the readers are likely to have played.
Though in Chapter 5 I discouraged you from using such comparisons in your focus, in
the design document comparisons can actually be useful, but with a caveat: you must
358 Chapter 19: The Design Document