purpose of design documentation is to express the vision for the game,
describe the contents, and present a plan for implementation. A design
document is a bible from which the producer preaches the goal, through
which the designers champion their ideas, and from which the artists
and programmers get their instructions and express their expertise.
Unfortunately, design documents are sometimes ignored or fall short
of their purpose, failing the producers, designers, artists, or programmers
in one way or another. This article will help you make sure that your
design document meets the needs of the project and the team. It presents
guidelines for creating the various parts of a design document. These
guidelines will also serve to instill procedures in your development
project for ensuring the timely completion of a quality game.
intended audience is persons charged with writing or reviewing design
documentation who are not new to game development but may be writing
documents for the first time or are looking to improve them.
documents come in stages that follow the steps in the development process.
In this first of a two-part series of articles, I'll describe the purpose
of documentation and the benefits of guidelines and provide documentation
guidelines for the first two steps in the process - writing a concept
document and submitting a game proposal. In the next part, I'll provide
guidelines for the functional specification, technical specification
and level designs.
The Purpose of Documentation
broad terms, the purpose of documentation is to communicate the vision
in sufficient detail to implement it. It removes the awkwardness of
programmers, designers and artists coming to the producers and designers
and asking what they should be doing. It keeps them from programming
or animating in a box, with no knowledge of how or if their work is
applicable or integrates with the work of others. Thus it reduces wasted
efforts and confusion.
means different things to different members of the team. To a producer,
it's a bible from which he should preach. If the producer doesn't bless
the design documents or make his team read them, then they are next
to worthless. To a designer they are a way of fleshing out the producer's
vision and providing specific details on how the game will function.
The lead designer is the principle author of all the documentation with
the exception of the technical specification, which is written by the
senior programmer or technical director. To a programmer and artist,
they are instructions for implementation; yet also a way to express
their expertise in formalizing the design and list of art and coding
tasks. Design documentation should be a team effort, because almost
everyone on the team plays games and can make great contributions to
does not remove the need for design meetings or electronic discussions.
Getting people into a room or similarly getting everyone's opinion on
an idea or a plan before it's fully documented is often a faster way
of reaching a consensus on what's right for the game. Design documents
merely express the consensus, flesh out the ideas, and eliminate the
vagueness. They themselves are discussion pieces. Though they strive
to cement ideas and plans, they are not carved in stone. By commenting
on them and editing them, people can exchange ideas more clearly.
Benefits of Guidelines
to specific guidelines will strongly benefit all of your projects. They
eliminate the hype, increase clarity, ensure that certain procedures
are followed, and make it easier to draft schedules and test plans.
of hype. Guidelines eliminate hype by forcing the designers
to define the substantial elements of the game and scale back their
ethereal, far-reaching pipe dreams to something doable.
and certainty. Guidelines promote clarity and certainty in the
design process. They create uniformity, making documents easier to read.
They also make documents easier to write, as the writers know what's
expected of them.
ensure that certain processes or procedures are followed in the development
of the documentation - processes such as market research, a technical
evaluation, and a deep and thorough exploration and dissemination of
of drafting schedules and test plans. Design documents that
follow specific guidelines are easy to translate to tasks on a schedule.
The document lists the art and sound requirements for the artists and
composers. It breaks up the story into distinct levels for the level
designers and lists game objects that require data entry and scripting.
It identifies the distinct program areas and procedures for the programmers.
Lastly, it identifies game elements, features, and functions that the
quality assurance team should add to its test plan.
from the guidelines. The uniqueness of your project may dictate
that you abandon certain guidelines and strictly adhere to others. A
porting project is often a no-brainer and may not require any documentation
beyond a technical specification if no changes to the design are involved.
Sequels (such as Wing Commander II, III, and so on) and other
known designs (such as Monopoly or poker) may not require a thorough
explanation of the game mechanics, but may instead refer the readers
to the existing games or design documents. Only the specifics of the
particular implementation need to be documented.