Writing Your Design Document
|
| < Day Day Up > |
|
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.
-
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
-
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.
-
-
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.?
-
Legal analysis
Describe all legal and financial obligations regarding copyrights, trademarks, contracts, and licensing agreements.
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
Legal notifications
-
Essence of Godzilla
2.1
Gameplay emphasis
-
The story
-
Features
-
The look
5.1
Game views
-
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
-
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)
-
Game flow chart
-
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
-
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
-
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
-
Fight mechanics
-
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
-
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
-
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.
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 162