Here's a suggested structure for your document. In actuality, you'll need to tailor the
structure to suit your particular project. But my guess is that this example is pretty
close to the industry standard. If you're working with a team that you have a history
with, or if the game is following an established precedent, your document may be as short
as 30 or so pages. That's short. Often, these documents can end up in the hundreds of
pages. They're getting longer and longer as the industry matures.
Overview
(sort of a recap and revision of the original concept paper)
The User Experience
- To what genre does this game belong? (We haven't really
defined genres yet in this industry, as they have in Hollywood, so you'll have to be a
little more specific. Best to describe similar products.)
- What part(s) of the brain are you attacking? (Reflex
response? Imagination? Problem solving? Strategy?)
- What are the most compelling aspects of this game? (Give
this section much consideration. It is the core of your "mission statement.")
- How deep is the product? (Is this a one-shot deal for
buyers, or something they can keep getting into for a while?)
The Platform
- Arcade, home, or school?
- PC, Mac, console, or multiplatform?
The Users
- General audience
- Base target audience
- Describe typical users
Time
- Game-play time (This is one of the most crucial, decisive
issues in the design of any game. It's impossible to make meaningful design decisions
without establishing predicted maximum, minimum, and mean game-play times first.)
- Product life (How many days/months/years do you expect the
user to keep coming back to your game? This period is usually based on how long it will
take users to figure everything out and master it.)
Basic Concepts
(gives a feel for the game, why things are the way they
are, and what the essential, indispensable elements are)
Storyline
- The background story (if applicable)
- Storyline or object of the game play
- Rules of the game (Justify these rules and explain what you
expect to see from them.)
Heroes and Villains
- Include biographical information and descriptions, even if
this won't be implemented in the software. This will be of great help to the artists and
animators.
Novelties and Compelling Features
- This is your chance to state the things you could not bear
to see disappear from this project, and justify your emotional attachment to them.
Navigation Chart
(an illustration of how parts of the game link to each other)
Entry and exit
Main menu
Level movement
Access to preferences and credits
Global Behaviors
(ensures that your game will have a consistent feel to it,
avoids serious run-ins with the programmers)
Run through all the standard elements of your project
(sprites, buttons, life-bars, input devices, and so on) and describe their behaviors in
every circumstance you can imagine. Your programmers will shower you with wreaths for this
one. Later, you can go change things on them - as long as the objects remain consistent,
and everything is justified.
Illustrate the motion of each animation, at least in stick
form. For 2D scrollers, fighters, and the like, you'll want to describe things cel by cel.
With other projects, rough sketches of general movements and their approximate duration in
microseconds may be enough.
If you are relying on a specific input device, justify
your button-mapping and button-combination decisions.
Scenes and Action
(In an adventure game, this will take up most of your
document)
Include preferences, credits, and main menu.
In subchapters, lay out consistent behaviors of local
elements.
Very often, a storyboard (that is, a series of panels
illustrating each scenario) is provided. In many projects, however, this is clumsy and
impractical.
Lists of Resources
You'll have to go over this with a fine-tooth comb to make
sure it's thorough. Leaving out even a few items, or failing to describe them clearly,
could prove a major source of exasperation later on.
This section comprises detailed lists of animations,
sounds, music, narration, sprites, backgrounds - everything that needs to be created
besides code.
Cross reference each item to its main reference in the
document.
|