3. Game Documentation
The game documentation is the bible from
which the producer preaches the game’s
goals, through which the designers champion
their ideas, and from which the artists and
programmers get their instructions and
express their expertise.
4. Game Documentation
The purpose of game documentation is to:
Express the game’s vision
Describe the game’s contents
Present a plan for implementation
5. Game Documentation
The three principal documents:
Game Design Document (GDD)
Technical Design Document (TDD)
Art Document
6. Game Documentation
In 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 the team 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.
7. Game Documentation
Documentation does not remove the need for design
meetings.
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.
8. Game Design Document (GDD)
The lead designer is the principle author of all
the game design document.
To a programmer and artist, it is the
instructions for implementation.
However, design documentation should be a
team effort, because almost everyone on the
team plays games and can make great
contributions to the design.
9. Game Design Document (GDD)
The GDD addresses:
User Interface
Control Scheme
Game Mechanics
Storyline
etc.
10. Game Design Document (GDD)
Game features may be ranked as follows:
Tier One: The core features of the game
Tier Two: Adds value to the core features
Tier Three: Designates what would be nice
to have inside the game
11. Game Design Document (GDD)
Tips for a good GDD:
Describe Not Just the Body, but the Soul: Take time to
describe the feel that the game should have, the
purpose behind each element, the experience each
user will have, and any other aspects of the game's
soul you can envision and describe.
Make it Readable: Plenty of white space, bold headers,
short lines of text, direct the eye towards important
material.
Prioritize: Categorize your game elements as:
indispensable, important, if possible, rejected
12. Game Design Document (GDD)
More tips for a good GDD:
Get Into The Details: A document without details is useless.
Generalities can be interpreted by anybody in any way that they
like.
Some Things Must Be Demonstrated: Sometimes a few rough
sketches are enough, but if the idea is truly important to your
concept of the project, you may want to make a rough animation
yourself.
Not Just "What" But "How": In the real world, the "how" determines
the "what." For example, suppose you've opted for claymation.
Work out the process of how the images will be captured and
document everything. What material and what color should the
backdrop be? What camera should be used and why? What are the
steps for processing the captured frames?
13. Game Design Document (GDD)
Even more tips for a good GDD:
Provide Alternatives: There are too many things about game
development that are unknowable at the beginning. Give the
development team some options about what to do.
Give It A Life: No matter how good something looks on
paper, the greatest expert still modifies things when it enters
the concrete world of objective perception.
Include a Table of Contents, Headings, Page Numbering:
Nobody should be able to say, "I did it that way because I
couldn't find any reference to it in the document."
Deliver It in Good Condition: Do whatever you can to
facilitate everyone actually reading and using the thing.
14. Technical Design Document (TDD)
The TDD describes the plan for creating
the game
While the GDD provides the “what”, the
TDD provides the “how”
The TDD is written by the Lead
Programmer, with input from the Lead
Designer and Lead Artist
15. Technical Design Document (TDD)
Project Overview
Project Summary: The "Elevator Pitch"
Technical Summary: What engine and other software is
being used to create the game; how long it will take to
make it; what platforms it will run on.
Target Minimum System Requirements: What
configuration the end user will need to run the game.
Technical Risks
Third Party Tools
16. Technical Design Document (TDD)
Hardware and Software
2D Software
3D Software
Sound Software
Programming
Development Platforms
Engineering Development
Content Development
20. Technical Design Document (TDD)
Guidelines
Don't write a Victorian novel: Use bullet points and
tables, and keep sentences short. The object is to
describe the technical design as concisely and
precisely as possible.
When documenting object-oriented designs, make
sure readers can quickly find and grasp each
class' name, responsibility, and relationships to
other classes
A picture is worth a thousand words: use
diagrams. Keep them simple and make it easy on
yourself.
21. Art Document
The Art Document is written by the Lead Artist
and addresses:
Style Guide
Asset Lists
Tool Instructions
22. And Don’t Forget…
Each of the three documents should have:
Game Title
Author Name
Version Number
Date Created
Date of Last Update
24. Answer these questions:
Who is on the core production team?
What 3 documents are written during
preproduction and which team member is
responsible for each?
What does it mean to “describe not just the
body, but the soul” of a game?
What is The Pre-Production problem and what
does Extra Credits recommend as the
solution?