GDD
The GDD, or Game Design Document, is a method of describing what you envision as your final product and how you plan
on getting there. The document is intended to hold all the little details required to make your game functional. If you have to
modify a number or add something to the project that wasn't described in your GDD then you have made a mistake.
However, the GDD is not meant to be the end-all-be-all for your game design. It is a fluid document that can be changed
throughout the game creation process. However, the point is that you need to think through the myriad details of your game
before starting to work on it. This leads to another important aspect of the GDD, it can often be used to for making the initial
time and budget decisions about a game, and thus be used to determine the feasibility of making the game.
While exploratory game creation can be useful and is always the tempting method of making a game, there are many benefits
to the game design process. First, in the professional environment, game-oriented or not, put a lot of emphasis on design
often to the point of fanaticism. Companies are very strict and can often become so rigid they do not allow a lot of variation
in a product once development is completed. From the programmer's standpoint it is often difficult to make ones self sit
down and write about what they want to accomplish. Often they can't resist the desire to just leap in to making the game.
However, this is rarely possible when working in groups because no one can read your mind. It also makes it easier to give
up when one part of the game becomes too difficult. It especially leads to large wastes of time because you will fixate on a
single portion of the game when you run into a problem. The best way to avoid those types of time wasters is to know what
else you can be working on, so that you can come back later to take a fresh look at the problem.
Regardless, this class is entended to help you master all steps of game development, which includes the design phase.
Therefore, you will need to start thinking through your ideas before working on them. It will also allow me to identify items
that will be beyond your skill or take an inordinate amount of time to complete. With some practice and increased
knowledge, you should be able to acknowledge your own prowess and identify how long each piece will take to complete.
While DigiPen has provided a GDD description in module 1, I am proposing a revised version here. Even so, it is important
to realize that not every game will have the exact same style of GDD. It is important to learn how to modify the GDD to
concisely conver your design. The main portions that you will mostly need in every document are the
 Hi-concept
 Competitive product analysis
 Detailed overview of the game and it's purpose
 Game flow including how one starts the game, how it ends, and what happens when the game instance concludes
 Sketches and details of the various levels, supplimentary material (such as title screen, score screen, etc), characters,
and game objects. These don't necessary have to be, and I suggest they not be, the final visual drafts of these
objects.
 Controls
The following is my revised version of the DigiPen GDD material presented in module 1.
HI-Concept - A hi-concept is a sentence of approximately twenty words or less that summarize the content of your game,
the idea of your game, and the genre of your game.
Competitive Product Analysis - The competitive product analysis allows you to relate your game idea in terms of an
existing game, which highlights those aspects of your game that are unique or different. The analysis must include the
following information:
 Product name
 Product platform(s)
 Development company
 Publisher
 Release data
 A short description outlining the similarities and differences between your game and the product. The differences
should highlight the features of your game that will set it apart from the product.
Product Development Overview - A short summary (5-6 lines) explaining the game details and features of the game.
Personally, I view this section as what one might read on the back of the box for a game that describes it.
Target Demographic - Specify the target age group for your game. Also include a brief reason for your choice.
Detailed Storyline - For many games, storyline is an important detail because it gives purpose and determines the
general flow of the game from start to conclusion. However, not all games utilize stories. Puzzle games such as Sudoku and
Scrabble do not really utilize a story in the traditional use of the word. In these situations, I expect you to detail the point of
the game, how the game progresses, how you win and/or proceed to future levels, etc. Storyline in this sense is what is the
game about (purpose) and what is the general flow of the game. Regardless, even games as simple as the original Donkey
Kong game have a basic storyline, premise. Do not neglect this section.
Main Character(s) - In my opinion, the main character is the visual object on the screen that direct how the game is
played. For a FPS the main character is the person holding the weapon, while in a chess game it is the highlighted rectangle
telling the player which square is going to be activated. How about a roleplaying or RTS game? What consititutes the main
character can be a difficult concept to deal with because the main character is also who the story is about. However, I am
designating this section to the description of the visual element that manipulates the game flow. I want drawings,
descriptions, ties to storyline characters, etc that encompass the visual element and its purpose in the game. Obviously, you
describe only what is applicable to your game.
Characters - The characters of a game usually refers to those elements of a story that might have a mind/purpose of their
own. Items such as levers and doors would be considered game objects even if they provide automated response to game
play. I expect a full specification of each character including sketches, what sounds they may use and when, what they do,
how they interact with the game, etc. Details should include things like approximate sizes, speeds, and other information
relating to their interaction within the game.
Game Objects - This is all the non-character pieces of the game. These include wall samples, doors, levers, platforms,
weapons, etc. You should describe each object, provide sketches, how they are utilized in the game, etc. Details should
include things like approximate sizes, speeds, and other information relating to their interaction within the game.
Level Overview - In the level overview, you need to describe each level, how it fits into the game, and how it flows with
the other levels and the game in general. You will need to provide sketches of each level including initial layouts of the
various characters and object and important game related details. You should also provide information about how the level
works, how you complete/start a level, etc. Basically, what are the details required to make the level.
Other Game Elements - This section is for those elements of the game that are part of game play, but accessible only
by the user. These elements include HUDs, inventory screens, item selections (such as those in a level editor), etc. You will
need to provide sketches and descriptions of how they fit into the game. The descriptions should include where they get their
data from and how they are used.
Game Flow - Game flow describes how the game proceeds from the logo screen to how the game exits. You will provide
sketches of those aspects of the game that are not part of game play such as title screen, menus, score screens, etc. Beyond
this, you will need to document how each various screen or portion of the game will transition and when to the others. It
should also include how the game is reset or concluded, etc.
Game Controls - This should address the controls and control devices you plan on utilizing in the game. It should also
detail what objects can be manipulated by the controls within the game.
Development Risks - In this section, you should attempt to identify those aspects of the game that could be tricky or
difficult to implement, ie. time consuming. Basically, you want to make an educated guess on those features that could hold
up production. These could be items such as you want to implement something you have may have to research. For
example, less say you want to use conversations in the form of chat bubbles, but you have never attempted something like
that before.
The purpose of this section will help you allocate your time by helping you prioritize game implementation. If you have a
short amount of time to implement something, it may be better to implement a simple place holder object first and come back
to the more complicated version later. Or it may be a cruicial part of your game in which case it would be better to attempt to
address it early in development, and if it seems like it is going to take too much of the development time to implement, it is a
good time to place this game on hold and come up with a new one for now. Also, it may be useful to work on this section
throughout the entire process of making this document so you can identify potential time risks as early as possible.
Target Estimates - Based on all the information above, you should be able to calculate a prilimiary estimate for
important delivery and design aspects of the game such as total game disk memory size, development time, target play
length, etc. This section is not necessary all the time, but as games become more complex and you become more skilled at
game design this section will become more important.
Tool Use - List of tools/programs you will need to create the game.