Project Documents

Game Desing
1. High Concept. The one- or two-sentence statement of the experience youre trying to
create.
2. Genre. A single sentence that places the game within a genre or a hybrid of genres. A
discussion of the genre your game falls under. This section should include comparisons to
other titles in the genre.
3. Gameplay. A description of the kinds of actions the player can perform during the game,
along with some examples.
a. Core Gameplay (What does the player do?)
i. Single-player ii. Co-op?
iii. Multiplayer?
4. Features. A list of the major features that set this game apart, including anything from
technical advancements to artistic style. Here, you should go into more detail about why
each of these features is important, and how youll implement them.
a. Game Features
i. Gameplay innovations (Special Effects)
ii. Advances in AI
iii. Artistic techniques and achievements
iv. License tie-ins (if applicable) (Tool Creation)
v. Other features that will make this game better than others like it on the market
5. Setting. Describe the game world in detail, and explain what makes it and its occupants
unique and interesting. Game Mechanics.
a. Main Menu
1. Single-Player
a. Load game
b. Save game
c. Play training level
d. Set difficulty level
2. Co-op
3. Multiplayer
a. Connection instructions
b. Character/team selection
b. Project Scope
i. Number of distinct locations
ii. Number of levels/missions
iii. Number of NPCs
iv. Number of weapons
v. Number of vehicles
vi. Etc.
c. Level #1
i. Synopsis
ii. Introductory material (Cutscene? Mission briefing?)
iii. Mission objectives (player goals)

iv. Physical description

v. Map
vi. Enemy types encountered in-level
vii. Weapons/powerups available
viii. Level walkthrough, including scripted sequences and non-interactive scenes.
This should also include any puzzles the player must solve, as well as the solutions
to those puzzles.
ix. Closing material (Cutscene? Debriefing? Statistics menu?)
d. Score
i. How score is tracked
ii. How score is communicated to the player
iii. Rules
f. Use cases
g. Graphics
i. Rendering
1. Geometry
2. Textures
ii. Animation
iii. Particle System
iv. Effects
6. Story. If the game has a story, describe it here in greater detail than in the pitch doc.
Include the major characters, their motivations, and how they achieve (or fail to achieve)
their goals.
a. Story
i. Back story
ii. In-game story (What happens during the game)
b. Environments
i. Area #1
1. General description
(sound)
2. Physical characteristics
3. List of levels that take place in this area
ii. Area #2
iii. Etc.
c. Characters
i. Player Character(s)
1. Personality
2. Back story
3. Look
4. Special abilities
a. Ability #1
i. When its acquired
ii. How the player invokes it
iii. Effect it has on the world
iv. Graphic effect that accompanies it
b. Ability #2 c. Etc.
5. Weapon set
i. Weapon #1 Powerups#2 Vehicles#3
1. General description and most effective use

2. When it is first acquired

3. Art (if available) (sound)
4. Statistics (for both primary and secondary fire)
a. Type of ammunition
b. Shots per clip
c. Fire rate d. Reload rate
e. Damage inflicted
f. Range
6. Regular animations
a. Walk, run, climb, roll, swim, crouch, crawl, idle, etc.
7. Situation-specific animations
8. Statistics (if applicable)
7. Target Audience. Explain why the game will appeal to the target demographic youve
identified.
8a. Hardware Platforms. A list of devices your game can be played on. If you plan to
develop different features for the various platforms, use this section to explain how the game
will be different on each one.
a. Delivery Platform(s)
b. Console Platform #1
i. A picture of the controller explaining what each button does
ii. Movement controls
1. Move forward
2. Move backward
3. Strafe left
4. Strafe right
5. Jump
6. Etc
iii. Weapon controls
iv. Action controls
v. Combos
vi. Force-feedback options
8b. Testing Procedures Weekly, Daily Activities
i. The Build
1. Generate a daily build.
2. Run the daily regression tests, as described in Daily Testsbelow.
3. If everything is okay, post the build so everyone can get it.
4. If theres a problem, send an e-mail message to the entire dev team that the new
build cannot be copied, and contact whichever developers can fix the problem.
5. Decide whether a new build needs to be run that day.
ii. Daily Tests
1. Run through a predetermined set of single-player levels, performing a specified
set of activities. a. Level #1
i. Activity #1
ii. Activity #2
iii. Etc.

8c. Development.
The development schedule is likely to last six months to two years. Very little software can
be designed, coded, and tested in less than six months (although with the advent of Internet
gaming and mobile gaming, small games are coming back into style).
i..Game Prototype
ii. Alpha
iii.Beta
iv.Code Freeze
9. Estimated Schedule and Budget. Break out the major phases of development, and the
level of effort associated with each, to show how you arrived at the estimates in the pitch
doc. (See Chapter 10 for details.)

Project Plan- Development Schedule

The project plan is a suite of documents that the producer uses to estimate costs, track
progress, maintain the schedule, and estimate profitability.
1. Manpower plan. This is a spreadsheet that lists when all the internal people connected
to the project come on board, and when they finish up. Here is a drastically simplified
version:

2. Resource plan. This spreadsheet lists all the external costs of the project and when they
will be incurred. The external costs appropriate to the preceding manpower plan might
look something like this:

Budget. This is a spreadsheet of all the costs associated with the project. Line items will
include the following:
a. Internal personnel costs (salaries of people applied to the project)
b. Hardware costs
c. Software licenses d. External contractor fees
e. Engine royalties
f. IP acquisition costs (license fee)
g. Marketing & costs
h. An overhead multiplier that applies fixed costs (building rent, utilities, travel,
personnel benefits, etc.) to the project
10. Competitive Analysis. A list of existing and planned games that will compete with yours.
List the games youll be competing with for sales, and explain how your game will stack up
against them.
11. Team. List the names and credentials of the design, tech, and art leads, as well as other
key team members. Also, list the games the organization has shipped. Publishers place as
much importance on the team as on the concept, so make sure this section convinces them
that your organization is capable of delivering the product youre proposing.
a. Team Personnel (with contact information for each individual)
i. Production Team
1. Producer
a. Office phone
b. Home phone
c. Cell phone
d. E-mail
2. Assistant Producer
a. Same contact info as above
3. Etc.
ii. Design Team
1. Design Lead
2. Level Designer #1
3. Writer #1
4. Etc.
iii. Programming Team
1. Tech Lead
2. Additional Programmers

iv. Art Team

1. Art Lead
2. Additional Artists
12. Risk Analysis. Explain the risks the project faces, and how you plan to minimize them.
1. Risk #1
a. Description
b. Potential impact
c. Possible ways to mitigate the risk
d. Current course of action
2. Risk #2
3. Etc.

The current risks document is an assessment by the project manager of the top risks to the
project, and how they're being mitigated. Usually this takes the form of a "Top Ten" list, but
the number is arbitrary and will change over time.

13. Summary. End on a high note. Emphasize again why this will be a great game, and why
the publisher should have confidence in your teams ability to deliver it.

14. The Manual

For getting the manual produced:
i. Ensure that the gamer has enough information to install the game and get it running.
ii. Explain how to play it.
iii. As game boxes get smaller and smaller, manuals have shrunk as well.