Wiki systems can be great for more easily keeping a document or collection of doc-
uments up to date. With Wiki, any member of the team can update a section of the
document through their web browser, and full version control and history is supported
to prevent the accidental loss of data. So, for example, the programmer who is imple-
menting a particular feature can slightly modify the text of the design document to
match how the feature actually ended up working, to add more information, or to link to
the newly created technical design document for that particular feature. On a large
enough project, keeping the design document completely up to date can be a full-time
job.
A Matter of Weight .............................
It is often joked that design documents are not read, they are weighed. This is not sur-
prising given the heft of many design documents and the lack of desire among team
members to read them. Shockingly, this statement is often true. I once heard an ex-pro-
ducer from a major gaming publisher talk about her experience with design documents
and the project approval process. She said that the “decision-makers” would bring a
scale to their “green-light” meetings. When it came down to two similar projects that
were both relatively worthy of funding, they would take the design document for each
project and place it on the scale. Whichever one weighed more would get accepted, the
other rejected. Much as it pains me to tell you, if you are in the commercial gaming busi-
ness and groveling for dollars at publishers, you need to make your document hefty. You
need it to be impressive to pick up and flip through. Many will never read it at all. Oth-
ers will read only the Overview and Table of Contents at the beginning. But everyone
will pick it up and remark on its weight.
Of course, many of these super-thick documents contain a lot of information of
negligible value toward the actual development of the project. They may be stellar
examples of one of the failed types of documents I discussed earlier, such as a
Back-Story Tome or an Overkill Document. It is your challenge as the game designer to
make the document as practical as possible by providing only useful information in the
document, while making it hefty enough to impress the suits. One might want to
include a large number of flowcharts or concept sketches or choose to use a bigger font,
all while not being too obvious. Indeed, a great game (though a simplistic one) can have
a perfect design document only ten pages long. One wonders how many great, simple
games have been cast aside by publishers who were unimpressed with the mass of their
design documents.
Thankfully, over the last few years many publishers and developers seem to be
wising up to the unwieldiness of massive design documents. Design consultant Mark
Cerny has been preaching the concept of starting development with only a simple
“macro” design document of perhaps ten pages in length that can be expanded on as
needed over the course of development. As I have discussed, others are starting to use
Wiki as a means of organizing and interlinking a lot of design information contained in
many smaller documents. And fewer and fewer publishers are funding development
based on a phone book-like design document alone, with prototypes and high-level,
graphical pitch documents becoming increasingly important. The days of padding out
the design document just for the sake of it seem to be thankfully drawing to a close.
Chapter 19: The Design Document 379