Game Design Principles

BSCGD III-A/B

Course Instructor: Mr Altaf Hussain

 Lecture 2
Game Design Documentation
Importance of design
documentation
• Game documents have exactly two purposes: memory and
communication.
1. Memory
A game design will be full of thousands of important decisions that define how the
game works and why. There is a good chance you will not be able to remember
them all. When these brilliant ideas are fresh in your mind, you will likely feel that
they are impossible to forget. But two weeks, and two hundred design decisions
later, it is very easy to forget even the most ingenious of solutions. If you get in the
habit of recording your design decisions, it will save you the trouble of having to
solve the same problems all over again.
2. Communication
Documents are a very effective way to do that. And this
communication, will not be one-way. It will be a dialog, for as soon as a
decision is put on paper, someone will find a problem with it, or come
up with a way to make it better. Documents can get more minds on the
design faster to more quickly find and fix weaknesses in the game
design.
Creating game design
documentation
• A Game Design Document (GDD) is a comprehensive document used
in the game development process to outline and describe various
aspects of a video game. It serves as a blueprint or roadmap for the
development team, providing detailed information about the game's
concept, mechanics, features, storyline, characters, levels, and much
more. The GDD acts as a reference guide that helps ensure everyone
involved in the project understands the vision and goals for the game.
• Since the purpose of documents is for memory and communication,
the types of documents you will need are defined by what needs to
be remembered and what needs to be communicated.
• It is the rare game where one document serves all necessary purposes
— usually it makes sense to create several different kinds of
documents.
• There are six main groups that need to remember and communicate
different things, and each generates its own special kind of
documents.
• The figure shows some possible
paths of memory and
communication on a game design
team. Each arrow could be a
document, or more than one
document.
• Let’s look at each of the six groups
and what documents they might
create.
Design
1. Game Design Overview. This high-level document might only be a few
pages. It is often written primarily for management so that they can
understand enough about what this game is, and who it is for, without
getting into too much detail. The overview document can be useful for
the whole team to get a sense of the big picture of the game.
2. Detailed Design Document. This document is the one that describes
all the game mechanics and interfaces in great detail. This document
usually serves two purposes: so the designers remember all the little
detailed ideas they came up with, and to help communicate those
ideas to the engineers who have to code them and the artists who
need to make them look nice.
3. Story Overview. Many games call for professional writers who will
create dialog and narration for the game. These writers are often
contracted, and often far away from the rest of the team. The game
designers often find it necessary to create a short document that
describes the important settings, characters, and actions that will
take place in the game. Frequently, the writers respond to this with
interesting new ideas that change the whole game design.
Engineering
4. Technical Design Document. Often, a videogame has many complex
systems that have nothing to do with game mechanics and
everything to do with getting things to appear on the screen,
sending data over networks, and other crunchy technical tasks.
Usually, no one outside the engineering team cares much about
these details, but if the engineering team is more than one person,
it often makes sense to record these details in a document so that
when others join the team they can understand how the whole
thing is supposed to work.
5. Pipeline Overview. Much of the challenging work of engineering a
videogame comes from properly integrating art assets into the
game . There are often special “do’s and don’ts” the artists must
adhere to, if the art is to appear properly in the game. This brief
document is usually generated by the engineers explicitly for the art
team, and the simpler it is, the better.
6. System Limitations. Designers and artists are often completely
unaware of what is and is not possible on the system they are
designing for (or so they pretend). For some games, the engineers
find it useful to create documents that make clear certain limits that
should not be crossed — number of polygons on the screen at once,
number of update messages sent per second, number of
simultaneous explosions on screen at once, etc.
7. Art Bible. If several artists are going to work together on a title to
create a single, consistent look and feel, they must have some
guidelines to help maintain this consistency. An “art bible” is simply
a document that provides these guidelines. These might be
character sheets, examples of environments, examples of color
usage, examples of interface, or anything else that defines the look
of any element in the game.
8. Concept Art Overview. There are many people on the team that
need to understand what the game is going to look like before it is
built. This is the job of concept art. The art alone doesn’t usually tell
the story, though — it often makes the most sense in a design
document, so often the art team works with the design team to
come up with a set of images that show how they will look and feel
in the context of the game design.
Management
9. Game Budget. While we would all like to just “work on the game
until it is done,” the economic realities of the game business seldom
allow this. Usually, the team is required to come up with a cost to
develop the game before they completely understand what they are
building. This cost is usually arrived at through a document, usually
a spreadsheet, that attempts to list all the work that needs to be
done to complete the game, complete with time estimates which
translate into dollars.
10. Project Schedule. On a well-run project, this document will be the
one most frequently updated. We know the process of game design
and development is rife with surprises and unexpected changes.
Nevertheless, some kind of planning is necessary, ideally planning
that can change on a weekly basis at the least. A good project
schedule document lists all the tasks that need to be accomplished,
how long each will take, when each task must be completed, and
who will do them.
Writing
11. Story Bible. While one might think that the story of the game might
be determined entirely by the writers (if any) on the project, it is
often the case that everyone on the project contributes meaningful
changes to the story. The engine programmers might realize that a
certain story element is going to be too much of a technical
challenge, and they might propose a story change. The artists might
have a visual idea for a whole new part of the story that the writers
never imagined. The game designers might have some ideas for
gameplay concepts that require story changes.
12. Script. If the NPCs in the game are going to talk, their dialog has to
come from somewhere! This dialog is often written in a script
document that is either separate from, or an appendix to, the
detailed design document. It is crucial that the game designers review
all of the dialog, since it is all too easy for a line of dialog to be
inconsistent with a rule of gameplay.
13. Game Tutorial and Manual. Videogames are complex, and the
players have to learn how to play them somehow. In-game tutorials,
Web pages, and printed manuals are how this usually happens. The
text that goes into these is important — if players can’t understand
your game, how can they enjoy it? The details of your game design
will likely continue to change up until the last minute of development,
so it is important to be sure someone is continually checking this text
to make sure it is still accurate with the game implementation.
Players
14. Game Walkthrough. The developers aren’t the only ones who
make documents about the game! If players like a game, they are
going to write their own documents about it and post them online.
Studying what your players write about your game can be a great
way to find out, in detail, what players like and dislike about your
game, which parts are too hard, and which are too easy.