Getting It Read..............................
Once your design document is written, one of your biggest challenges may be getting
anyone on the development team to read it. Often, many programmers, artists, or even
other designers will not want to put the time into a careful reading of your document.
Others may have been burned by bad design documents in the past and will jump to the
conclusion that yours is of similarly poor quality. Keeping your document up to date,
including only useful information, providing a detailed table of contents, and limiting
yourself to practical, accomplishable gameplay elements will help. Including numerous
short, high-level summaries before each section of the document can also help team
members get high-level information for aspects of the game they don’t need to know so
much about. At the same time, such summaries can give readers a big-picture vision
before they dive into the gritty details of the document. If your team members sample
your document and find it to be of superior quality, they are more likely to return to it for
reference when they are actually implementing a given system or working on a particu-
lar piece of art. As with any written document, you need to earn the trust of your
readers if you hope to keep them reading.
Another key method of getting your design document read is to make it easily
available to anyone who wants to read it. Keep it in the same source-control system that
your team uses for asset management. You want your team members to be able to get
the latest version of the design document as easily as they get the latest build of the
game. Since you will be constantly revising and updating your document to keep it up to
date with the project (and to prevent it from becoming a Fossilized Document), source
control will be a valuable tool for keeping track of the previous revisions. Not to beat a
dead horse, but a Wiki system run over a company intranet can also be great for distrib-
uting the document to the team, with developers at any time being able to easily read
the very latest version of the document through their web browsers.
When you check in the latest version of the document, send your team an e-mail
telling them that it is available and explaining what has changed. That way, people can
easily skim over the changes. If one of the changes is relevant to their work, then they
can get the latest version of the document off the network and read over the relevant
updates. Updating your document does not do any good if no one knows you have
updated it or if people are still reading old revisions. It is probably a good idea to use a
version number with your document, such as 1.3 or 2.7. Include this version number,
along with the date, in a header on every page. Often people will print out a design doc-
ument and not realize how old or fossilized it is. If they can quickly compare a date and a
version number, they will know which version of the document they have and whether
they need to get a new one.
Documentation Is Only the Beginning...................
Some designers or aspiring designers seem to think that a thorough design document
is, by itself, enough to build a game. Indeed, some companies have had designers write
design documents, only to then have those designers move on to write other design
documents while a separate team actually executes their design. At its best, a design
document is a rough outline, more the suggestion of a game than anything else, and
380 Chapter 19: The Design Document