basis in reality or feasibility and end up frustrating and infuriating the teams assigned to
“make them happen.”
Pie-in-the-Sky Documents include ideas such as “a fully modeled replica of
Manhattan will be the players’ primary game-world, complete with AI agents repre-
senting all of the city’s seven million inhabitants in real-time.” The authors of
Pie-in-the-Sky Documents do not want to be bothered with messy details such as the
reality that no existing computer system can simulate seven million humans in any sort
of reasonable time frame (let alone real-time). Another feature suggested might be “a
natural language parser will be included that allows users to type in full, complex Eng-
lish sentences, which the characters will respond to with their own dynamically
generated dialog.” The guilty designer does not want to hear that research institutions
have been working for decades on natural language processors that still have trouble
with short, simple sentences. When confronted with a Pie-in-the-Sky Document that
you must work with, the first thing to do is call a reality check meeting involving key
programmers and artists as well as the management who want this document imple-
mented. With them all in the same room, some simple and quick calculations on a piece
of paper or white board will often reveal how fundamentally impractical the game pro-
posed is, and if the management still refuses to accept the reality of the situation, it
might be time to start looking for a new job. Pie-in-the-Sky Documents are often com-
bined with Ellipsis Specials to create truly wretched design documents, where the
guilty designer outlines a completely impractical project without bothering to go into
much detail about it.
The Fossilized Document........................
Any of the above flawed design documents can also be a Fossilized Document. Indeed, a
design document that does not necessarily suffer from any of the above problems and
was once a fine reference tool will become a Fossilized Document over the course of a
project if the designer is not diligent in her efforts to keep the document up to date. I
know of no original game project whose design has not changed significantly during the
course of its development, and when the design changes but the design document does
not, that document starts to become fossilized.
Suppose a programmer on the development team looks something up in the Fossil-
ized Document and the information she finds is out of date. She may start implementing
the old, long-since-modified functionality. At some point, a designer or producer who is
aware of the changes that have taken place in the design will notice that the program-
mer is creating a system that is no longer appropriate, and will chastise the
programmer for doing so. This creates frustration for both parties, not to mention wast-
ing the programmer’s time. Furthermore, whenever the programmer needs to know
something about the design in the future, she will not trust the design document, and
instead will go hunt down a designer or producer to find out how a given system is sup-
posed to function. Of course, this defeats the purpose of the document, as the designer
must stop whatever she is working on to explain the system to the programmer. This
new system may be described correctly in the document, but the programmer is not
going to get burned again by using the Fossilized Document. When the designer fails to
update the document when design changes occur, the entire document becomes use-
less. No one can trust it, and as a result no one will bother to read it.
378 Chapter 19: The Design Document