[Here, GameCareerGuide presents an extract from Creating Games: Mechanics, Content, and Technology -- Chapter 5: The Design Document. This comprehensive and easy-to-understand guide should get you on the road towards creating your first design documents with relative ease.]
Terms Explained: Choke Point - Design Document - Issue Tracking - Player Composite - Bugs - Plot Graph - Staffing Plan - Storyboard - Tags - Technology Plan
The design document describes the development team's shared vision for all aspects of the game and the development process. It is considered a working document because it is continually revised, based on feedback and experience. The team begins writing the design document before the game, but the document is not finished until the game itself is finished!
The format of the design document is essential to its use as a reference document. Each chapter addresses a specific aspect of development, such as the user interface. The order and style of the chapters varies across companies, but any game-development project should contain most of the sections discussed in this book. When the developer works with a publisher, the developer proposes the game with an early version of the design document and later uses the design document to present the game's evolving specifications to the publisher. Some sections of the document resemble a business plan in order to meet these needs.
Design documents are often hundreds of pages and are maintained by the lead designer and producer, although other members of the team contribute a lot of the content. In the board game industry, design documents tend to be short and informal because board games are simpler than video games, and the development process is shorter and involves fewer people. A tightly-focused design document of about 20 pages is good for an indie game or classroom final project. As with any working document, controversy may arise about whether to write a long document (to create a full specification) or to write a short document (which is easier to keep up to date). We recommend keeping the design document on the short side and augmenting it with regular face-to-face communication between team members.
New document technology like webpages and wikis can make design documents up to date and more visible to the whole team. Online documents also have the advantage of hyperlinks between sections of the document and external concept art or supporting documents.
This chapter describes the basic content of the design document. Although all of the following features are presented in this chapter, later chapters discuss individual features in more detail.
The title is on one page. It is graphically simple, like the frontispiece for a book. Yet it contains vital information. The title page should contain:
Larger companies or those working with publishers require legal statements on this page as well. For example, copyright information, "confidential/do not distribute" instructions, and the main office contact phone number and address.
This one-page section describes the entire game in three sentences: 
A game might be interesting and engaging because it contains a new technology, has an interesting story, contains a new mechanic, or can be marketed at a low price. There are many reasons a publisher might want to approve a game. These tend to focus on either novelty, e.g., "never before have RPG and puzzle games been combined" or "the first real-time Scrabble game," or (ironically) the complete absence of novelty, e.g., "this is a James Bond game, and all James Bond games sell 1M units." Often the text for the executive summary can be entirely drawn from other sections of the design document.
The overview consists of two or three pages that compactly describe the major qualities of the game. It follows the overview worksheet format from the previous chapter. It must pitch the core concept, review related games, and present the reader with a mental image of the game as a whole. It is essentially a distilled version of the entire design document.
The overview is the first part of the design document that is written. Once accepted by an internal team, the proposal/overview then evolves into a proposal from the team to the company. The ideas from the overview are finally expanded into a full design document.
This section reviews related games and serves as background research for both marketing and design purposes. Experience with previous work is important. You should extend the successes of previous games while avoiding their pitfalls. Rarely do truly original ideas emerge; usually someone has already come up with your great idea. So research previous work and then leverage it.
The related games section should devote about one page to each related game. The specific games chosen should be a superset of those described in the overview section.
Discuss existing games that resemble yours in any way (e.g., setting, mechanics, business model). Why do you feel that you can repeat the success of a previous game or avoid its failure?
Some previous work may be your competition. You need to address this head-on. Judge your own potential and account for competition in your design. Why will your game succeed if it is competing with an already established game?
Figure 5.1: Library of related work games at Iron Lore Entertainment.
A wise designer draws heavily from previous games. Most games companies have large libraries of games available for close study and reverse engineering during production (see Figure 5.1). Build such a library and plan on spending many hours perusing everything from menus to data files in other games.
 An academic would call this the abstract for the document.
This section creates a marketing model of the players who will purchase and play your game. These aren't the in-game characters but the real people who will playing the game. The characteristics of this group will help you create intuition for design decisions, as well as serve as a job description for the playtesters you will recruit.
Creating a player composite takes the player from being an ambiguous presence in the design (or, even more dangerous, a carbon copy of you!) and makes him or her into a concrete person you want to make happy. For example, you may create the following profile:
"John Brooke, 27, accountant. Single. Graduate of Loyola College. Plays games alone about once a week, and with male friends on a next-generation console plugged into an HDTV in his living room on weekend afternoons. Focuses on competitive, action games like Gears of War and Madden. Watches football one day a week. Favorite TV shows are Lost and Sopranos reruns. Drives an Audi A4. Drinks imported beer."
The profile answers the following questions about this target player.
Most games have both a primary market and a secondary market; for example, an Asteroids remake might target both preteens and nostalgic 40-somethings. Make a composite for each demographic you hope to target. When available, the composites can be based on actual market research. But even without such research, it is better to invent the composite than to have none at all. With a composite, the entire development team will explicitly agree, which is far better than having everyone independently make different personal assumptions.
For all but abstract games, like Yinsh and go, the setting and narrative are significant aspects of production. Most players never create a mental model more sophisticated than the fiction they are told and depend on a consistent virtual world for enjoyment.
In the world section, give the background. This may be the history of an entire civilization or just the conditions surrounding the main character. Record information about areas and events to keep the decisions made by various team members consistent. The Halo series is based on hundreds of pages of documents detailing several alien races, the main character, the rough geography of the universe, and the detailed geography of the ring world in which the game takes place. The amount of detail needed for your game depends on the scope of the setting and on the player's exploration ability. The only limiting factor is the time you can invest creating and maintaining this information.
Some of the world information will be revealed to players in the game manual or throughout the course of the game. Other aspects will never be revealed, but their consistency will be felt. Sequels and expansion packs are a great opportunity for revealing aspects that were kept secret in the initial game. Chapter 11 describes methods for building out your world.
Describe each character's background and motivation. This is especially important for the main character in a narrative-driven game, whose motivations will become the player's own. Include concept and in-game art for each character. List aspects including their:
For nonhuman characters, make sure their origins and race are well developed.
Create a flow chart to show the player's progression through the game. In a plot-driven video game with a strong narrative, this serves as the nonlinear map of the narrative. Figures 5.2 and 5.3 show plot diagrams for Ultima VII as drawn by player Urpo Lankinen.  Annotate your graph to show narrative arcs and different physical regions within which the player travels. For a Choose Your Own Adventure book, the progression graph essentially is the game; all that is missing is the flavor text (which, in that case, comprises all of the text that the player sees!).
Figure 5.2: Plot graph for the main quest in Ultima VII.
Figure 5.3: Detail from the progression graph for the main quest in Ultima VII.
For a game that lacks a strong narrative (e.g., an emergent instead of progressive game), the progression graph indicates the major stages through which gameplay changes occur. Strategy games like Civilization typically see an escalation of risk and power throughout the game that can be shown here.
In a board game, the progression graph describes the setup and the states of the game. Most modern board games have several phases to each turn that can be clearly delineated on the turn progression graph. An example is shown in Figure 5.4 for RoboRally, a board game in which players "program" robots with cards and then have them fight on the factory floor.
Figure 5.4: Progression graph for play in the board game RoboRally.
For games with cutscenes and cinematics, label those scenes in the plot graph and provide additional material in the form of storyboards and scripts describing the scenes. See Don Bluth's The Art of Storyboard [Bluth and Goldman 04] for a good graphic introduction to these.
The art direction section is a combination of descriptive text and images that convey the graphic style of the game. It typically includes concept art (e.g., as shown in Figure 5.5), reference art from books to inspire the style, instructions on the use of lighting in a 3D game, font samples, and constraints specified by the underlying technology. See Chapters 13 and 14 for a discussion of some of the constraints that the graphics engine places on the artwork in a video game.
Figure 5.5: Concept art for Titan Quest. (Image courtesy of ILE/THQ)
For a computer game, the user interface is the installer, the title screen, menus, dialogs, in-game heads-up display and information displays, options screens, and any other controls or text. Each of these must be storyboarded for both content and graphic style, although content is the primary purpose of this section. Storyboards can be simple sketches that show the GUI elements, with callout boxes and labels indicating the function of each element. Flow charts (state machines) are needed for each major GUI interaction showing the modes that the interface can be in and how the player's actions change modes.
User interface storyboards are simpler for a board game. In this case, they are essentially concept art for the layout of the play area, board, and pieces. The difference between the UI section and the concept art section is that UI focuses on functionality and concept art focuses on style.
This section is exclusive to video games. The tags and dialogue section is a database that maps descriptive labels (tags) used by the programmers and designers to actual text that the user will see and hear in game. For example, a button labeled "Launch Attack!" in the game might have the tag ATTACK. Later in the development cycle, the designers can decide that the button should instead say "Commence Firing." To make this change, the tag stays the same, but the value stored for that tag in the tag database changes. This way, the programmers don't have to update their source code for cosmetic changes, and the technology and design teams can work without interfering with one another. Tags are also used for dialogue lines. The tag HELLO INKEEPER1 could map to "Salutations, weary traveler. Come in and rest yourself for a while."
Tags are critical for internationalization. Translators can work through the database without significant concern for where text appears in the game. Likewise for adjusting potentially offensive language to satisfy content ratings.
In games with spoken dialog, tags map not only to text but to audio files, although these are more difficult to change. However, like translators, voice actors can work through the database of script lines. Voice actors should be given some context and experience with the game so that their tone and inflection are appropriate.
The technology plan is primarily for video games, but it can be adapted to board games in a useful way. A video game requires several major pieces of software. Some are part of the game itself, like the core engine (rendering, physics, and networking) and the gameplay code (user interface, artificial intelligence, and game logic). Other pieces are tools: the software used for maintaining the design document (e.g., Microsoft Word, wiki), the artist tools (e.g., 3DS Max, Photoshop), the programmer tools (e.g., Visual Studio, VTune), the management tools (e.g., Project, Excel, Trac), asset management (e.g., AlienBrain, Subversion), level editors, art exporters, and so on. Hardware technology is also required for console development, development consoles, all development workstations and servers, and often special-purpose technology like motion capture and 3D scanners for artwork.
The technology plan enumerates all of the technology needed for producing the game and maintaining the company. It designates whether it will be bought or built in-house. For technology that can be bought, the specific solution selected should be explained and defended. For technology that must be built, the rationale for building in-house should be explained and the rough specifications for the project outlined. The buy/build decision is often easy except for core engine technology, where the company must decide if it can adapt an existing game engine or must build its own. For further discussion of core engine technology and this difficult decision, see Chapter 6.
Board games require some tools for production (usually 2D art programs and word processors) but not nearly as much as video games. However, board games have another technology requirement in terms of playing pieces and their manufacture. The technology plan for a board game should discuss how those pieces will be obtained and the costs associated with that plan. Generic pawns and dice can be purchased inexpensively, but custom pieces require a more significant investment. Playing boards and cards can be surprisingly expensive to produce, although there is great room for savings by altering the printing method or switching to lower-quality (sharp corner, monochrome, thinner) paper and cardboard components.
For students working on a class project, the technology plan is highly constrained by the materials available for the course. For a board game, reusing existing game pieces and boards is a fast and cost-effective alternative to producing custom pieces. For a video game, using open-source software or writing a mod for a game engine is a great alternative to buying or building. Students are often tempted to build most of their technology, but reusing existing technology allows you to focus more on design and innovation and less on reinventing the wheel!
Video games require complex software design. The architecture documents describe the features of each programming module. This includes the major application interfaces (APIs), the algorithms that are used to implement them, and the design patterns behind them. In addition to text and tables of numbers, architecture typically contains many diagrams. These include inheritance diagrams, memory depictions of key data structures, and data file format diagrams. The two types of diagrams that always appear are the system module diagram and the data flow graph. The module diagram depicts the high-level control structure, and the data flow shows how information moves.
The system module diagram looks like a brick wall, where each brick is a software component. Components at the bottom are low-level libraries, such as DirectX and Havok. If we personify the components as people in a company, these are the laborers who will do the actual "heavy lifting." The components that rest on top of them direct the action of these lower libraries. Those themselves are managed by higher-level routines. In programmer terminology, higher boxes call into the boxes below them, creating a dependency. Components at the top of the module diagram are generally the most specific to the particular game, while those at the bottom are so generic that they may be provided by the platform manufacturer for use in all games.
The boxes in the data flow diagram are major software components (some of which are licensed), and the arrows show the kind of data that flow between them. The direction of arrows shows data dependence. Data generally flows in from pre-created art assets and real-time user input and out to the display. An example of the data flow diagram for a typical game appears in Figure 6.3.
Video games depend on their control schemes. An otherwise great game can fail because the input mechanic is too awkward or is targeted at the wrong audience. The controls section details both the mapping of buttons to in-game functions and the algorithms mapping analog inputs to actions.
Figure 5.6: Controls for Roadkill on the PlayStation 2 by Red Octane. (Image courtesy of Red Octane/Activision)
This section contains images such as Figure 5.6 that show the explicit control layout for traditional input devices, as well as action diagrams for more recent innovations such as accelerometers (e.g., the NintendoWiimote), video cameras, and audio and gesture recognition. Chapter 17 explains the technology behind user input and theories of how to design effective input schemes.
Most games are divided into levels that represent a discrete change in difficulty, such as different waves of aliens in Space Invaders. It can also be a scenario or map, such as the warehouse "Assault" map in Counter-Strike or the Joan of Arc battle in Age of Empires. In a classic emergent game like chess, levels become vague (although one could consider the opening, middle, and end games to be separate levels).
In a game that has a strong and primarily linear progression, levels are generally areas of a larger world (although the same location may be revisited as a separate level). The progression through this is indicated by the plot graph.
For games with location-based levels, create maps that show the layout and the connectivity of the level. Indicate major encounters, key item locations, and goals. The topology of the level is more important than the true proportions for this section, but you should make notes tying areas to the art direction section.
Provide analysis of the level space, diagramming the flow of characters through the area and identifying choke points and focus nodes. A choke point is a small area that controls the flow between major parts of the map -- for example, a narrow mountain pass and a bridge over a river. Characters will be funneled through these areas, and control and influence over such areas will become key to the player's strategy. A focus node is the location of a shared resource. Examples include a gold mine in an RTS game, a key power-up in an FPS, a healing shrine in a fantasy game, the flags in a rally race, and a watering hole in an animal simulation. These areas increase player interaction by bringing them together. Unlike choke points, they are not necessarily sources of contention because players may collaborate to use the resource and may share it if it is not limited.
Some games have randomly generated levels, like Settlers of Catan and the random maps in StarCraft. For these, discuss the kinds of features that will appear in the level and how the level-generation process ensures that they arise in the proper distribution.
The heart of the gameplay design in the document is the mechanics analysis section. It is equally important for video games, board games, major AAA titles, indie games, and class projects. Pen-and-paper RPG manuals, such as the AD&D Player's Handbook, give a good idea of what the mechanic descriptions in this section should look like. Economics textbooks give good examples of how to analyze, model, and balance mechanics.
Mechanics, also known as game mechanics, are small groups of rules that outline a strategic conflict, inspire a particular emotion in the player, or move the game forward. They are perhaps best understood through some examples.
Racing is a classic mechanic. Get to the finish line before your opponents. Racing puts time pressure on the player, creating stress and motivation. It is inherently both fair and balanced; the achievement scale is defined by the ratio of fastest to slowest racer. The racing mechanic need not be as explicit as cars on a track. For example, in a capture-the-flag game, a race mechanic begins as soon as a flag is taken and both sides are trying to reach the goal (or intercept the carrier) as fast as possible.
Shooting is a popular mechanic. It involves reflex actions, strategy in setting up a shot before the enemy appears, and leading the target when projectiles are slow. Shooting doesn't have to involve guns. Various games have used shooting mechanics to fire oneself out of a cannon, take pictures of wildlife, or successfully throw and catch a ball in sports.
Describe the mechanics in your game. Mechanics are typically shared between large numbers of games and are the primary definition of genre. Indicate what other games use similar mechanics and describe the differences. Motivate the gameplay reason for each mechanic. Does it prevent an undesirable strategy, simulate some aspect of the game's setting, or exist to deepen strategy in an otherwise too simple game? Explain alternative mechanics that could have been employed to address that need and why this one is better. What is the strategy that arises from the mechanic?
Give guidelines for making the mechanic balanced and useful for gameplay. Support these arguments in text, graphs and diagrams, and probability and mathematics.
Other common mathematical tools for evaluating and balancing mechanics are outcome matrices and unit databases. Outcome matrices are for evaluating competitive situations where one kind of unit is up against another kind. The matrix lists the first unit type along the rows and the second unit type along the columns. Each entry in the center describes the outcome for the combination of unit types (think of a multiplication table from school or a road map that shows the distance between cities). Unit databases are tables with the unit types listed down a column and adjacent columns describing their statistical properties, like hit points and movement speed.
For each measurable property of the game (e.g., points, gold, health), give a target graph of how it should ideally vary over time. See Chapters 7, 8, and 10 for further discussions of the mechanics analysis section.
The master development schedule describes the plan for producing the game on time. It is broken down into prototype releases and milestones, and those are divided into individual tasks assigned to developers. Milestones describe the features and user experience that will be available at distinct points in time. They should be monthly or bimonthly for a game that is in development for years, but for a month-long indie project, they may be weekly or every other day.
Tasks can be chained based on dependency in a Gantt chart to graphically indicate when a task has been inappropriately scheduled before another task it must build on. Figure 3.7 shows a project schedule maintained in Microsoft Project with both a Gantt view and a breakdown per milestone.
5.17.2 Staffing Plan
For a commercial game, the staffing plan describes how developers will be hired over time to meet the demands of the schedule. It can be expressed as hiring milestones or as a graph running along the bottom of the timeline. When designing it, remember that recruiting, interviewing, and training talent takes time from both the new hire and the existing team members. An indie team or a class project team generally has no hiring and needs no staffing plan.
5.17.3 Key Developers
Briefly describe the qualifications of team leads, producers, and managers. These are the people who should have proven track records and who will be held responsible for delivering a quality game product on time. Qualifications include education, previous job experience (especially games shipped), exceptional skills, and awards received.
In industry, this section is primarily to convince a publisher (or investor) that your team has the ability to deliver the game that it is promising to create. In academia, this is to convince your teacher that your team has the necessary skills.
5.17.4 Issue Tracking
Issue tracking is a more sophisticated version of maintaining a "to-do" list. Issues are known bugs (also: errors or drawbacks) of the game design or implementation, customer support requests, and features that have been requested but not approved or scheduled. Issues are what you aim to eventually change into lines on the change log.
Issues are commonly owned by one developer, but they are stored in a format that is visible to management and the rest of the company. A video game has so many issues that they are usually stored in a database and not in the design document itself. For a board game or extremely simple (e.g., puzzle game) computer game, a bulleted list with some details at the bottom of the status section may suffice.
Figure 5.7: Sample bug list and a specific open ticket from the SourceForge issue tracking system for the G3D game engine.
Figure 5.7 shows a screenshot from an issue-tracking system. The top of the screen is a table listing a small number of issues stored in the database. The table lists the developer who is assigned to resolve the issue, a summary, the date, and so on. The bottom is a detailed view of a single issue that has been selected.
How is the project going? Augment the schedule with one or two paragraphs that summarize the current status in text. These should point out milestones that are at risk of slipping and major successes. Keep this up to date at all times.
The budget section describes the total cost of development. Line items include the cost of purchased technology, salary (according to the staffing plan), recruiting costs, art assets, and contractors. Marketing is not usually the developer's responsibility, but if you are producing a shareware/independent title, then that is a factor. See Appendix D for sample budget worksheets.
Because it is a working document, the design document that you begin with might not might not look anything like the one you end with. Many changes are trivial and need no explanation. If you expand information that is already present or fix a minor error, everyone understands the change. When a major change is made, however, it is important to record that information. For example, if one mechanic is completely removed after a playtest, it should be noted on the design document, and everyone who will be reading it should be alerted. For such a change, add a line to the change log section briefly summarizing what happened -- for example, "Removed time limit on water war stage because playtesters reported excessive tension on that level."
Developers frequently release rule changes (for board games) and patches (for video games) even after the game itself has been released. These are accompanied by change logs to let the players know what changed. Those change logs are edited versions of the ones that are in the design document.
Some designers call the change log the revision history and maintain it right after the title page. The back of the design document is another popular location. It is often useful to not only maintain a bulleted list but to designate build or version numbers between strings of changes. This is helpful when reviewing old playtesting information to see what set of changes were enacted before and after the test.
1. Give one player composite for the core constituency of each of the following games.
2. Draw a plot graph for your daily routine containing about 15 nodes. Use branches to indicate different ways your day plays out -- for example, according to the day of the week or based on what you find in your e-mail.
3. Why are tags used in games instead of just putting the value of the tag directly into the game code?
4. What is the difference between the plot graph and level design?
5. List ten game mechanics -- for example, racing, shooting, and rockpaper- scissors relationship.
6. What is the difference between the key developers section and the staffing plan?
7. Why is a change log useful?
8. Find the change log for a published game, and list a few of the major changes between versions.
9. Create a "blank" design document for your project. This should contain all of the sections that are relevant but need not have any content beyond the section titles and the cover page. You can do this by starting with one of the templates on our webpage and deleting unnecessary sections or by following the instructions in this chapter.
It is hard to obtain sample design documents for major titles because game developers and publishers consider them confidential internal documents. However, a few have been published. The following reading contains examples of design document templates or completed design documents.