Game Design Workshop: Designing, Prototyping, & Playtesting Games (Gama Network Series)

Contents Of A Design Document

There are as many different ways to write a design document as there are designers. The game industry has no standard way of documenting designs. It would be nice if there were a set formula or style to follow, like the standards for screenplays or architectural blueprints, but this simply doesn’t exist. Everyone does agree that a good design document needs to contain all the details required to create a game, however, what those details are will be affected by the specifics of the game itself.

In general, the contents of a design document can be broken up into the following areas:

• Overview and vision statement

• Marketing and legal information

• Gameplay

• Characters (if applicable)

• Story (if applicable)

• World (if applicable)

• Media list

The design document may also include technical details, or these may be articulated in a separate document called a technical specification. The technical specification or the technical sections of the design document are generally prepared by the technical lead or director.

Exercise 14.1: Researching Design Documents

To get a feeling for the various ways that designers approach the writing of design documents, go on the web and do a search using Google or Yahoo! for game design documents. You’ll find dozens posted on the Internet. Pick two and read through them. What are their strengths and weaknesses? If you were a member of the design team, would you be able to execute the design as described? What questions do you have for the designers after reading the documents?

Figure 14.1: Character sketches from Jak & Daxter and Ghost

When you approach the writing of a design document, it’s easy to get distracted by the scope of the document and forget the ultimate goal—to communicate your game design to the production team, the publisher, the marketing team, and anyone else with a vested interest in the game. This is one reason why we advise you not to write your design document until you’ve built and playtested a working prototype of your idea. Having this type of concrete experience with your proposed gameplay can make all the difference in your ability to articulate that gameplay in the design document.

You should also think of your design document as a “living document.” You’ll likely have to make a dozen passes before it’s complete, and then you’ll need to constantly update it to reflect changes that are made during the development process. Because of this, it’s important to organize your document modularly. If you organize your document carefully from the beginning, it will be easier to update and manage as it grows in size and complexity. Also, as we mentioned earlier, it will be easier for each group to find and read the sections that affect their work.

The following outline is an example of how you might organize your design document. We’ve noted under each section the types of information it should contain. Keep in mind that our goal here is not to give you a standard format which will work for every game, but rather, to provide you with ideas for the types of sections you may want to include. Your game and its design should dictate the format you use for your own document, not this outline.

1. Design history

   A design document is a continuously changing reference tool. Most of your teammates won’t have time to read the whole document over and over again every time that a new version is released, so it’s good to alert them to any significant modifications or updates that you’ve made. As you can see, each version will have its own section where you list the major changes made in that iteration.

   1.1	Version 1.0
   1.2	Version 2.0 1.2.1 Version 2.1 1.2.2 Version 2.2
   1.3	Version 3.0

2. Vision statement

   This is where you state your vision for the game. It’s typically one or two pages. Try to capture the essence of your game and convey this to the reader in as compelling and accurate a way as possible.

   2.1	Game logline In one sentence, describe your game.
   2.2	Gameplay Synopsis Describe how your game plays and what the user experiences. Try to keep it concise—no more than a couple of pages. You may want to reference some or all of the following topics: Uniqueness: What makes your game unique? Mechanics: How does the game function? What is the core play mechanic? Setting: What is the setting for your game: the Wild West, the moon, medieval times? Look and feel: Give a summary of the look and feel of the game.

3. Marketing information

   3.1	Target audience Who will buy your game? Describe the demographic you’re targeting, including age, gender, and geographic locations.
   3.2	Platform What platform or platforms will your game run on? And why did you choose these platforms?
   3.3	System requirements System requirements may limit your audience, especially on the PC where the hardware varies widely. Describe what is required to play the game and why those choices were made.
   3.4	Top performers List other top-selling games in the same market. Provide sales figures, release dates, information on sequels and platforms, as well as brief descriptions of each title.
   3.5	Feature comparison Compare your game to the competition. Why would a consumer purchase your game over the others?
   3.6	Sales expectations Provide an estimate of sales over the first year broken down by quarter. How many units will be sold globally, as well as within key markets, like the United States, England, Japan, etc.?

4. Legal analysis

   Describe all legal and financial obligations regarding copyrights, trademarks, contracts, and licensing agreements.

5. Gameplay

   5.1	Overview This is where you describe the core gameplay. This should tie directly into your physical or software prototype. Use your prototype as the model and give an overview of how it functions.
   5.2	Gameplay description Provide a detailed description of how the game functions.
   5.3	Controls Map out the game procedures and controls. Use visual aids if possible like control tables and flowcharts, along with detailed descriptions. 5.3.1   Interfaces Create wireframes for every interface the artists will need to create. Along with each wireframe should be a description of how it functions. Make sure your detail out the various states for each interface.   5.3.2   Rules If you’ve created a prototype, describing the rules of your game will be much easier. You’ll need to define all the game objects, concepts, their behaviors, and how they relate to one another in this section.   5.3.3   Scoring/winning conditions Describe the scoring system and win conditions—these may be different for single-player versus multiplayer, or if you have several modes of competition.
   5.4	Modes and other features If your game has different modes of play, such as single and multiplayer modes, or other features that will affect the implementation of the gameplay, you’ll need to describe them here.
   5.5	Levels The designs for each level should be laid out here. The more detailed the better.
   5.6	Flowchart Create a flowchart showing all the areas and screens that will need to be created.
   5.7	Editor If your game will require the creation of a proprietary level editor, describe the necessary features of editor and any details on its functionality. 5.7.1   Features   5.7.2   Details

6. Game characters

   6.1	Character design This is where you describe any game characters and their attributes.
   6.2	Types 6.2.1   PCs (player characters)   6.2.2   NPCs (nonplayer characters) If your game involves character types, you’ll need to treat each one as an object, defining its properties and functionality. 6.2.2.1   Monsters and enemies   6.2.2.2   Friends and allies   6.2.2.3   Neutral   6.2.2.4   Other types   6.2.2.5   Guidelines   6.2.2.6   Traits   6.2.2.7   Behavior   6.2.2.8   AI

7. Story

   7.1	Synopsis If your game includes a story, summarize it here. Keep it down to one or two paragraphs.
   7.2	Complete story This is your chance to outline the entire story. Do so in a way that mirrors the gameplay. Don’t just tell your story but structure it so that it unfolds as the game progresses.
   7.3	Backstory Describe any important elements of your story that don’t tie directly into the gameplay. Much of this might not actually make it into the game, but it may be good to have it for reference.
   7.4	Narrative devices Describe the various ways in which you plan to reveal the story. What are the devices you plan to use to tell the story?
   7.5	Subplots Because games are not linear like books and movies, there may be numerous smaller stories interwoven into the main story. Describe each of these subplots and explain how they tie into the gameplay and the master plot. 7.5.1   Subplot #1   7.5.2   Subplot #2

8. The game world

   If your game involves the creation of a world, you need to go into detail on all aspects of that world.

   8.1	Overview
   8.2	Key locations
   8.3	Travel
   8.4	Mapping
   8.5	Scale
   8.6	Physical objects
   8.7	Weather conditions
   8.8	Day and night
   8.9	Time
   8.10	Physics
   8.11	Society/culture

9. Media list

   9.1	Interface assets
   9.2	Environments
   9.3	Characters
   9.4	Animation
   9.5	Music and sound effects List all of the media that will need to be produced. The specifics of your game will dictate what categories you need to include. Be detailed with this list, and create a file naming convention up front. This can avoid a lot of confusion later on.

10. Technical spec

    As mentioned, the technical spec is not always included in the design document. Often, it is a separate document prepared in conjunction with the design document. This spec is prepared by the technical lead on the project.

    10.1	Technical analysis 10.1.1   New technology Is there any new technology that you plan on developing for this game? If so, describe it in detail.   10.1.2   Major software development tasks Do you need to do a lot of software development for the game to work? Or are you simply going to license someone else’s engine or use a preexisting engine that you’ve created?   10.1.3   Risks What are the risks inherent in your strategy?   10.1.4   Alternatives Are there any alternatives that may lower the risks and the cost?   10.1.5   Estimated resources required Describe the resources you would need to develop the new technology and software needed for the game.
    10.2	Development platform and tools Describe the development platform, as well as any software tools and hardware that are required to produce the game. 10.2.1   Software   10.2.2   Hardware
    10.3	Delivery How do you plan to deliver this game? On CD-ROM, over the Internet, on wireless devices? What’s required to accomplish this? 10.3.1   Required hardware and software   10.3.2   Required materials
    10.4	Game engine 10.4.1   Technical Specs What are the specs of your game engine?   10.4.2   Design Describe the design of your game engine. 10.4.2.1   Features   10.4.2.2   Details   10.4.3   Collision Detection If your game involves collision detection, how does it work? 10.4.3.1   Features   10.4.3.2   Details
    10.5	Interface technical specs This is where you describe how your interface is designed from a technical perspective. What tools do you plan to use and how will it function? 10.5.1   Features   10.5.2   Details
    10.6	Controls’ technical specs This is where you describe how your controls work from a technical perspective. Are you planning on supporting any usual input devices that would require specialized programming? 10.6.1   Features   10.6.2   Details
    10.7	Lighting models Lighting can be a substantial part of a game. Describe how it works and the features that you require. 10.7.1   Modes 10.7.1.1   Features   10.7.1.2   Details   10.7.2   Models   10.7.3   Light sources
    10.8	Rendering system Rendering is a big part of games these days, and the more details you can provide the better. 10.8.1   Technical specs   10.8.2   2D/3D rendering   10.8.3   Camera 10.8.3.1   Operation   10.8.3.2   Features   10.8.3.3   Details
    10.9	Internet/network spec If you game requires the use of the Internet, LANs, or wireless networks, you should make the specs clear.
    10.10	System parameters We won’t go into detail on all the possible system parameters, but suffice to say that the design document should list them all and describe their functionality. 10.10.1   Max players   10.10.2   Servers   10.10.3   Customization   10.10.4   Connectivity   10.10.5   Web sites   10.10.6   Persistence   10.10.7   Saving games   10.10.8   Loading games
    10.11	Other This section is for any other technical specifications that should be included, such as“help menus,” “manuals,” “setup and installation routines,” etc. 10.11.1   Help   10.11.2   Manual   10.11.3   Setup

11. Appendices

    The appendix is the perfect place for reference documents, such as agreements with third party developers, subcontractors, or talent. Also details on hardware or software can be included in the appendices so that they don’t clutter up the main design document. In general, if there are lengthy pieces of information and data that your team may need but that don’t belong in the body of the design document, you can place them in the appendices.

    11.1	Appendix A
    11.2	Appendix B
    11.3	Appendix C

    We want to emphasize that the previous outline is merely a list of suggested topics that may need to be addressed in order to communicate your design. Every game will have its own specific needs and the organization of your design document should reflect these needs.

    The following table of contents from a game design document is an example of how one game has dealt with these topics. The game is Godzilla: Destroy All Monsters Melee, published by Atari and developed by Pipeworks Software. The game designer and producer, Kirby Fong, has provided an excellent overview of the design in the manner in which the sections and subsections are organized. In just a brief glimpse, you can get a good idea of whether or not the topic your interested in is covered in the design document and where to find it.

Title: President, Gas Powered Games

Project list (five to eight top projects)

• Hardball II

• 4D Boxing

• Test Drive II

• Triple Play Baseball

• Total Annihilation

• Total Annihilation: The Core Contingency

• Dungeon Siege

How did you get into the game industry?

I started in the business by answering a small classified ad in the newspaper. I started as a programmer at a game developer in Burnaby, B.C., Canada called Distinctive Software. My first assignment was to do Hardball II. It was a sequel to the hugely successful Hardball by Bob Whitehead, and was a great learning experience. I worked almost every single day for the eighteen months it took to develop the game.

What are your five favorite games and why?

This list changes over time, but some of them include Populous (PC), Duke Nukem 3D (PC), the original Command & Conquer (PC), Ratchet & Clank (PS2) and now Battlefield: 1942 (PC).

What games have inspired you the most as a designer and why?

The most inspirational games are the early Sid Meier and Peter Molyneux games, and then without a doubt Dune II and Command & Conquer from Westwood Studios. Without Command & Conquer I would never have left EA to create Total Annihilation.

What are you most proud of in your career?

Total Annihilation because of the very short timeline we created it in—20 months from beginning to end, and that it had such a huge mod community, and then Dungeon Siege for the sheer engineering complexity.

What words of advice would you give to an aspiring designer today?

My advice would be to get a job in the business at any level to get your foot in the door. Once you see how games are really made you will change your strategy and get your game made much sooner, even though it could take you ten years to learn the business. Read every book you can find and play every game you can get your hands on. Pick your role models and look carefully at how they find success.

Godzilla: Destroy All Monsters Melee Design Document, Version 2.1

Copyright 2000 Pipeworks Software

1. Legal notifications

2. Essence of Godzilla

   2.1	Gameplay emphasis

3. The story

4. Features

5. The look

   5.1	Game views

6. Gameplay

   6.1	The battles 6.1.1   Weapons play   6.1.2   Hand-to-hand combat   6.1.3   Fight again?   6.1.4   Health and energy   6.1.5   Rage   6.1.6   Power-ups   6.1.7   City destruction   6.1.8   Human armies   6.1.9   Fight boundary

7. Play modes

   7.1	Adventure mode (1 player) 7.1.1   Scoring   7.1.2   Rounds   7.1.3   Fight again (reset)   7.1.4   Elapsed time counter   7.1.5   Unlocking the “hidden” monster   7.1.6   MemCard data   7.1.7   Adventure options   7.1.8   Adventure mode game flow
   7.2	VS mode (1 or 2 players) 7.2.1   Scoring   7.2.2   End game options   7.2.3   MemCard data
   7.3	Melee mode (2 to 4 players) 7.3.1   Melee rules settings   7.3.2   MemCard data
   7.4	Team battle (3 to 4 players) 7.4.1   Rules settings
   7.5	Destruction Mode (2 to 4 players) 7.5.1   Scoring   7.5.2   Destruction game flow
   7.6	Survival mode (1 player)

8. Game flow chart

9. Art components

   9.1	Front end screens 9.1.1   Intro   9.1.2   Title screen/main menu   9.1.3   Adventure screen   9.1.4   VS: monster select screen   9.1.5   Melee: monster select screen   9.1.6   Team battle: monster select screen   9.1.7   Destruction: monster select screen   9.1.8   Survival: monster select screen   9.1.9   City selection screen   9.1.10   Main options screen   9.1.11   Adventure “Top 10” screen   9.1.12   Survival “Top 10” screen
   9.2	Fight Screen 9.2.1   3D elements   9.2.2   Overlays
   9.3	Environments 9.3.1   Tokyo   9.3.2   San Francisco   9.3.3   Los Angeles   9.3.4   London   9.3.5   Monster Island   9.3.6   Osaka   9.3.7   Seattle   9.3.8   Alien arena/alien mothership (hidden level)
   9.4	Hidden levels
   9.5	Easter eggs 9.5.1   Pickups   9.5.2   Art gallery   9.5.3   Bonus levels   9.5.4   Atari 2600 COMBAT game
   9.6	Characters 9.6.1   Hidden character   9.6.2   Bosses   9.6.3   Traffic   9.6.4   Military   9.6.5   People   9.6.6   Flying saucers
   9.7	Power-ups 9.7.1   Health power-up   9.7.2   Rage power-up   9.7.3   Mothra air strike power-up
   9.8	Cinematic noninteractive sequences (NIs) 9.8.1   Attract mode   9.8.2   Game intro   9.8.3   Adventure mode story setup   9.8.4   Villain monster intro   9.8.5   Monster intro   9.8.6   Power-up sequence   9.8.7   Victories

10. Music and sound

    10.1	Music 1.1   Front end music   1.2   Fight themes
    10.2	Voice-overs 10.2.1   Monster intros   10.2.2   Villain intros   10.2.3   Military radio chatter
    10.3	Sound effects 10.3.1   Monsters   10.3.2   Military   10.3.3   City

11. Controls

    11.1	Walking
    11.2	Aiming/shooting/throwing
    11.3	Basic moves/controls
    11.4	Fight moves defined 11.4.1   Punches   11.4.2   Kicking   11.4.3   Grabs/throws

12. Fight mechanics

13. Cameras

    13.1	Game play cameras 13.1.1   Panoramic view   13.1.2   Top down view
    13.2	Instant replay cameras 13.2.1   Orbiting cam   13.2.2   Tank cam   13.2.3   Helicopter cam   13.2.4   Street cam

14. Meet the monsters

    14.1	Godzilla 2000
    14.2	Godzilla ‘90s
    14.3	MechGodzilla
    14.4	Mothra
    14.5	Rodan
    14.6	Anguirus
    14.7	Orga
    14.8	King Ghidorah
    14.9	Mech-King Ghidorah
    14.10	Megalon
    14.11	Gigan
    14.12	Destoroyah
    14.13	Hedorah

15. AI

    15.1	NPC senses
    15.2	NPC states
    15.3	AI abilities 15.3.1   Maneuvering   15.3.2   Targeting   15.3.3   Attacking   15.3.4   Evading

Under each of the sections in your design document, you need to answer all the questions that a team member may have. For instance, the “character designs” section would include drawings and a description of each character in the game, while the “levels” section would include not only the intended gameplay for each the level but explanations of any story elements that would be found in each level.