Game Development Reference
In-Depth Information
experience along with the components the development team requires to pull it all together, and can
be used to pitch the game to potential investors or publishers.
Before diving into the GDD, here is a brief description of the roles of your fellow game development
team members, who along with you will be working from the GDD.
The Game Development Team
The game design document serves to communicate the vision of the game design to the game
development team. A typical team includes the game designer, the developer, and the artist.
The
game designer
is usually the originator of the game itself—the original concept, rules, and
vision of the play experience. The designer is also the person responsible for creating the game
design document and using it to keep the other team members coordinated.
The GDD is a dynamic document—it is normal that much about the game design may change over
the course of production. This might be in response to team member input or tester feedback or
because of budget restrictions. The game designer steers the changes to conform to the overall
vision of the game and updates the GDD to communicate any changes to the rest of the team, as a
change in one area commonly requires corresponding adjustments by other team members.
The
artist
creates the visual elements of the game. This includes the characters, animations, the
terrain and objects in the game world, and GUIs.
The
programmer
might also be called the
engineer
or
developer
. All interactions between the
player and the game are defined by the code the programmer writes. This interaction includes
mapping the game controller to character action, controlling the camera, defining the AI for enemies,
and even writing the “cheat code” for testing certain aspects of the game. Fundamentally, the
programmer writes the code that implements the game designer's vision of gameplay.
Testers
come in different varieties of bug testers and play testers. Bug testers are also known as
quality assurance, the people who test the products of the other team members to ensure they get
the desired results specified in the GDD. Whereas quality assurance screens for technical accuracy,
play testers test the game experience—just because a game is bug free and meets the GDD
description still doesn't guarantee that it is fun.
As the team gets bigger, it will have more specialized roles in each category. Level designers,
enemy-AI developers, and riggers and animators are just examples of the many specialty areas
involved in large game development projects.
While you might be your whole team and wear each hat when necessary, creating a game design
document will be helpful to you for a number of reasons. First, a GDD will help you clarify your game
concept and provide a structure from which you can further flesh out the idea. As you build your
game design on paper, you will see the sheer number of details involved in even a relatively simple
game. The GDD helps you keep track of the details. Reducing certain desired features due to time or
budget constraints is a common occurrence, but you will still have a record of the original concept
that may be handy as an upgrade or complete sequel to the original game.
At some point you may end up bringing someone into the development process, and you can
quickly get them up to speed via the GDD. When you reach this point, you will learn a lot about
what you meant to say in your GDD compared to how it can be interpreted by others. The alternate
interpretations might be better or worse than your original version, so be open to outside ideas.
