Game Design

(Elliott) #1

Table of Contents.............................


The reader may laugh to think that I list this as an important part of the document. Of
course a document over fifty pages in length and containing multiple sections will have
a table of contents — why even mention it? What bears emphasis, however, is the
nature of the Table of Contents section. Since creating an index is a time-consuming
task for a large body of text such as a design document, it is unlikely you will have time
to make one. In the absence of an index, the Table of Contents ends up as the tool peo-
ple use to navigate your document. When a member of the development team needs to
find a specific piece of information in your document, she will be inclined to look first in
the Table of Contents to try to find where that information is most likely to be. So the
more detailed and inclusive your Table of Contents, the more likely she will be able to
quickly find the information she needs.
No simple novel-style table of contents will do in the design document — in other
words, no listing of only eight separate sections with the reader left to navigate the
pages within the sections on her own. The Table of Contents must include subsections,
sub-subsections, and perhaps even sub-sub-subsections. We have already discussed
how you will need to use bolded headings throughout your document to make it easy
to navigate. In addition, any commercial word processor will allow you to turn these
headings into entries in a table of contents. These entries will then automatically
update for you as those headings move around within the document. Most word proces-
sors even allow someone reading the document on her computer to click on an entry in
the table of contents and be taken directly to the appropriate part of the document.
Making a detailed Table of Contents for your design document is crucial to making it
useful.


Introduction/Overview or Executive Summary.............


It is a good idea to have a single-page overview of your game’s design at the beginning
of your document. This summary is not very useful to developers actively toiling away
on the project, who, as you may remember, are the target audience for the document.
However, for new team members who come on board the project, a summary will be a
good starting point for understanding the game. Indeed, for anyone reading the docu-
ment for the first time, be they a producer, an executive, or a marketer, getting an idea
of the game’s “big picture” through a one-page summary can be quite helpful. Even if
whoever reads the Introduction is not going to have time to read the rest of the docu-
ment, this one-page summary should allow them to understand the essence of the
gameplay.
The Introduction should limit itself to a single page. Longer than that and the Intro-
duction stops being an effective summary. Any information that does not fit on a single
page is simply not part of the game’s core design. If you find yourself going over the
limit, figure out what is least important among the data you have in the summary and
cut it. Repeat this process until the summary fits on a single page. Think of the sum-
mary like your resume: longer than a page and you may lose your reader. Write a
gripping first paragraph that sums up the entire game, with the following paragraphs
filling in the structure outlined in the opening.


360 Chapter 19: The Design Document

Free download pdf