Also, from each wave to the next, the conditions under which certain enemies appear
change. For instance, the flea never comes out in waves in which there is a twelve-seg-
ment centipede on the play-field. If one were to write a Game Progression forCentipede
(which would not need to be very long at all), one would want to break it down by waves,
clearly delineating how the game changes from wave to wave.
Some games may not need a Game Progression section at all. For instance, a
design document for a strategy game likeCivilizationor a software toy likeSimCity
could describe all of the relevant gameplay in the Game Mechanics, AI, and Game Ele-
ments sections. Since the levels in these games are randomly generated anyway, there
is not much use in having a Game Progression section. However, if the game in ques-
tion is to include certain scenarios that do start on predefined levels in specific
configurations (as theSimCitygames do), a Game Progression section would be the
ideal place to describe these different scenarios and how they will challenge the player.
System Menus..............................
The System Menus section is where you should detail the main menu and whatever
other options screens players will be presented with at various points outside of the
game itself. These menus do not actually impact the gameplay in any significant way,
and as a result should be separated into their own unique section. You should include
descriptions of how players will save their game and how they will load it later.
Describe what type of interface players will have with these menus: will they use
mouse-pointer-based point-and-click, or will they use the Enter and arrow keys, or
both? Try to be as complete as you think is necessary to ensure that the system menus
are intuitive enough to allow players to enjoy playing the game itself. Producers love to
see that you have fully described the flow of these menus, so it may be important that
you include a System Menus section, though, in my opinion, such a section is not truly
required for a complete design document. It might even make sense to make the Sys-
tem Menus section into its own separate document, since they are so divorced from the
gameplay proper.
One Man’s Opinion .............................
In the preceding pages, I have presented the format I like to use for game design docu-
ments. Let me repeat that it is by no means the industry standard format. Many great
design documents have used formats wildly different from mine, both in terms of struc-
ture and in terms of how much detail they provided. But if you present a document
structured as I have explained, you will not be laughed at or thought a fool. As I have
stated previously, what is most important is that you communicate your vision for the
game to the people reading your document. You are free to present your design infor-
mation in whatever form makes the most sense to you while providing for maximum
clarity and utility for your data.
Part of the reason why the design document format can vary so much from project
to project is that games are not yet (nor do I think they ever will be) a standardized art
form, as plays, movies, or symphonies are. Just as a writer’s style guide for a cookbook
and a romance novel would be extremely different, one can hardly expect the design
document for a first-person shooter such asHaloto be of the same form as one for a
Chapter 19: The Design Document 373