GAME DESIGN DOCUMENT (GDD) TEMPLATE

Concept Document

The concept document serves the purpose as a way to present a game concept. A
general overview of the game, with the idea anyone can read and understand what the
game is like. This part of the document is one that will change very little once the concept
is accepted.

Title Page
The title page includes general information about the game:
● Game Name :
● Game Logo :
● Game Catch Phrase :
● Document Type :
● Document Version :

Credit Page
The credit page should present information about the person who authored the document
and for what company.
● Document Purpose:
● Document Version:
● Working Title:
● Game Concept:
● Game Document Author:

Sign-Off
The sign-off section lists all the people involved (by rank and role) and confirms that each
member of the team has read through the document and agrees with the current plan.

GAME CONCEPT SIGN-OFF

Lead Artist:
Lead Designer:
Lead Programmer:
Lead Producer:
Introduction
The introduction should include a brief sentence or two about the game, its genre, player
type, technical form, references, and theme. Everyone that reads this should be able to
understand what the basic idea of this game is.
A new purpose for the introduction can also be the reason for the concept and history of
the game the concept is based upon. Here is a short list of subjects to address in the
introduction:
• Genre • Player Type
• Game Play • Technical Form
• History • Reference
• Theme • Design Intentions (original or cloned)

Game Analysis
The game analysis provides a general overview of the game.

Game Description
Genre:
• Describe the Genre
Example:
● Role-play
● Adventure
● Strategy
● Puzzle
● Simulator
● Construction & Management

Game Elements:
• Game elements are the basic activities the player will be doing for fun during the game.
Example:
● Shooting
● Collecting
● Chase
● Combat
● Dodging

Game Content:
Example:
● Horror
● Thriller
● Humor
● Drama
Theme:
Example:
● Western
● Sci-Fi
● Fantasy

Style:
Example:
● Real
● Old School
● Manga

Game Sequence:
Example:
● Linear- Storylines
● Hyper- Storylines that the player can influence
● Simulation

Player:
The Number of players that can play the game at once

Game Reference
Game Taxonomy:
• Game Taxonomy is here as a reminder of what the design direction is.
• Game Taxonomy is made up of Simulation-, Game- and Narrative-based. These can
further be divided into Chance vs. Skill, Fiction vs. Non-Fiction and Physical vs. Virtual.
Based on Lankoski and Björk: “Lindley (2003) slightly modifies Caillois’ (1961) classical
four elements... identifying three primary descriptors (narrative, ludology, and simulation),
upon which operate additional dimensions differentiating the level of chance vs. skill,
fiction vs. non-fiction and physical vs. virtual.
Example:
Xyanide is a Fictional Game/Narrative, while Sim City is a NonFictional Simulation/Game.

Player Immersion: • This is an attempt to understand what kind of enjoyment the player
will receive from the game.
Example:
● Tactical
● Strategy
● Narrative
● Physical
● Emotional
 ● Mental

Reference:
• References can come from anywhere.
• The idea is to describe your game’s story, play, and style with references.

Game Technical
Technical Form: • Basically there is 2D graphics (Flat) and 3D graphics (Form)

View: • Camera view the player will experience the game from

Platform: • iOS, Android, Mac, PC

Language: • C#, C++, Ruby, Java

Device: • PC, Mobile, Console

Game Sales

Consumer Group:
• This could involve conducting a research or focus group with actual consumers to
gather or validate market acceptance data

Payment:
• This could involve discussions on monetizing the game and receiving payments from
customers

Estimated Price:
• This could involve market sizing and market pricing strategies for the game product

Game Atmosphere
In the game atmosphere section, it is best to have a mood board or a clear description of
the game’s style. This is a good place to start interacting with a graphic designer.

Game Play
The gameplay section is utilized to create a descriptive paragraph about how the game is
played.
The idea is that you want the person to imagine they are actually playing the game. Try
not to use generic (i.e. broad, non-descriptive) names when writing about the gameplay.
• Opening the game application • Game Options
• Story Synopsis • Modes
• Game Elements • Game Levels
• Player’s Controls • Winning
• Losing • End
• Why is all this fun?

Example:
Few readers want to hear statements such as: “enemy_1 will have more hit points than
enemy_2.” Instead, it is better to make statements such as: “the Lazarus Fighter has more
armor than the Apollo Fighter.”

This outline will vary according to the type of game.

Key Features
Key features are a list of game elements that are attractive to the player. It may be a
good idea to research the key points below or consult with a professional marketer.

• Number of Levels
• Number of Enemies/ Characters (Example: 12 characters or amount of enemies, end
bosses)
• Time of Game Play (Example: 2 hours of fun) • Replayability
• Audio Specifications • Graphic Specifications
• Device Compatibility • Number of Players
• Online Activities (high scores, etc.) • Number/Type Modes
• Marketing Ideas • Consumer Group
• Unique Features • Merchandising

Selling Features
This is a list of features that could be potentially helpful to market and/or sell a game. If a
game has any copyrightable material, note it here. It may be a good idea to research the
key points below or consult with a professional marketer.
Design Document

This document describes how game objects behave, controlled and properties they have.
This is often referred to as the “mechanics” of the game. This documentation is primarily
concerned with the game itself. This part of the document is meant to be modular,
meaning that you could have several different Game Design documents attached to the
Concept Document.

Design Version
A version can single out a certain series of devices that may have limitations, different
OS, or more advanced features. A code convention for different versions would be
advisable.
Example: Such as J1.1
(J): (JAVA) Developed for a particular Technology
(1.): Concept Update
(.1): Content Update

Design Guidelines
This is an important statement about any creative restrictions that need to be regarded
and includes brief statements about the general (i.e. overall) goal of the design.
• Menu
• Synopsis
• Game Play
• Player Control
• Game Over (Winning & Losing)

Game Design Definitions

In this section, the definition of the gameplay is established. Definitions should include
how a player wins, loses, transitions between levels, and the main focus of the gameplay.

Game Matrix
The game matrix is a spreadsheet containing the generic names of the player and
antagonistic elements and their game properties. This should allow an easy cross-
reference for any elements in the game that have numerical or other descriptive values
associated with their name.

Game Flow Chart

The game flow chart provides a visual of how the different game elements and their
properties interact.
Game flow charts should represent Objects, Properties and Actions that are present in
the game.
Flow chart objects, properties and actions should have a number reference to where they
exist within the game mechanics document.
Player Elements
The player elements section lists all the elements that are directly related to the player or
serve to benefit the player.
Devise two sets of names for player elements. One set is a generic name (or code) and
the other is its game name. Describe the terminology that you use to describe the player’s
properties.
This is a good place to interact with a graphic designer to ensure the game graphics
match the game names. Graphics that will be seen during gameplay should be exhibited
here.
Multi-player issues should also be mentioned here.

• Default (Status): What are the default settings for the player at the beginning of the
game or level?
• Actions: What can the player do?
• Information (Status): What information about the game is available for the player?
• Default Properties: How does the player begin the game?
• Winning: How can the player win?
• Loosing: How does the player lose?

Player Definition
Use the player definition section to make quick descriptions that define the player.
Below is a suggested list of player definitions:

Player Properties
Make a list within the player properties section that defines the properties for each
player. Player properties can be affected by the player’s action or interaction with other
game elements. Define the properties and how they affect the player’s current game.
A suggested list of player definitions may include:
• Health
• Weapons
• Actions
• Etc.
Each property should mention feedback as a result of the property changing!

Player Rewards (Power-ups & Pick-ups)

Within the player rewards section, make a list of all objects that affect the player in a
positive way (i.e. health replenished).
Define these objects by describing what effect they cause and how the player can use
the object.
User Interface (UI)
This is where a description of the user’s control of the game can be placed. It is also
recommended to think about which buttons on a device would be best suited for the
game. Consider what the worst layout is, then ask yourself if your UI is it still playable?
A visual representation can be added, where we relate the physical controls to the
actions in the game. When designing the UI, it may be valuable to research quality control
and user interface (UI) design information.

Heads up Display (HUD)

The HUD section is where a description of any graphics that will represent information
during gameplay should be described.
A visual representation (mock-up screenshot) here would be useful.
This is another good place to seek the advice or collaboration of a graphic designer.

Player View
A screenshot is very necessary in the player view section.
It is also beneficial to include a definition of how the camera moves for the player.
Finally, a (mock-up) overview of the level relative to the screen size will help create a
perspective of the size of a level compared to what is actually seen.

Antagonistic Elements
This is where a list of antagonistic (i.e. enemies, opponent) objects should be listed with
graphics and written description.
Describe the terminology that you used to describe antagonistic properties.
Devise two sets of names for player elements. One set is a generic name (or code) and
the other is its game name.
This is another good place to collaborate with a graphic designer to ensure the game
graphics match the game titles, names, and descriptors.

Antagonistic Definitions
This is where a description goes of what makes an antagonistic element.

Antagonistic Properties
This is a list of properties that antagonistic elements have in common.

Antagonistic List
This is where a list of all the antagonistic elements goes.

Artificial Intelligence (AI)

This is where visuals and written description(s) of the antagonistic element’s behaviors.
These should be labeled in such a way that they can be used in level design without
having to describe them again.
Devise generic names for repetitive behaviors.
This is how an AI action could be deconstructed:
• Normal State: What is the object doing if it has not come in contact with the player?
• Detection State: What does it take for this object to detect the player?
• Reaction State: What does the object do as an action after passing the reaction state?
• End State: What happens to the object after the player has reacted correctly or
incorrectly to the object?

Global Game Elements

In this section, it is important to describe the boundaries, neutral objects, camera views,
and scale of the world.
Neutral game world objects can be things like a static background, objects that do not
interact with the player, or antagonistic elements.

The Story
This is where the story can be described in detail. A storyboard can be used to tie in
graphics to the text. This can later be used for splash screen concepts.

The Story Copy

A shorter version of the story (the in-game version) should also be written here. This is
where the script for in-game characters or story information during the cut scenes would
be placed. This category does not always pertain to the current Game Design.

Concept Art
Sketches that are used for the concept can go into this section as visual reference. In the
case of a brand, certain creative restrictions should be noted here. This is a good place to
collaborate with a graphic designer to ensure game graphics match game names.

Level Design
This is where information pertaining to level design and visuals of the level design goes.
Level design can best be shown as a flow chart. Use generic names to create level
design.

Level Copy
This is where the script for in-game characters or story information during the cut scenes
would be placed.

Audio & Sound F/X

This is where game audio and Sound F/X should be listed, first with generic names and
then described. This section also includes deciding if you will use a device’s vibration ring
mode.
Game Architecture
The game architecture section is best produced using a flow chart to represent the
overall game.
Be sure to identify (i.e. name, number) each screen.
• Title Screen
• Option Screens
• Game Modes
• End Screens

Game Architecture Overview

The splash screens or video clips need to be in accordance with the game story and
style. If cut scenes use video then storyboards should be created.
Menus should be designed with the most important options easily accessible. Be aware of
how many clicks it takes to accomplish a task.
The game Instructions should be written so that the player understands how to play the
game.
Mock-ups should be made so that the game programmers get the correct layout of the
menu.
It is a good idea to mention and describe the high score screen in this section.

Architecture Copy
All text from the game can be compiled here.
Review the Game Architecture Overview section.

How To Play Copy

This section will organize the game copy. The game copy includes information for the
player, clearly describing how to play the game.

Technical Document
The information concerning the technical aspects of the game should be placed here. The
technical document is best achieved with consensus from the people responsible for the
Visual, Programming, and Audio aspects. This part of the document is meant to be
modular. This means that it is possible to have several Game Technical documents
attached to the Game Design Document (GDD).

System Requirements
This is a list of system requirements that a device will have to meet to run the game.
This also represents the restrictions that may apply to the end product.

Visual Content
A list of technical requirements from those in concerned with the visual aspects of the
game. All objects should be listed with their generic names.
General
● File Size Restrictions
● File Format Type
● File Quality Type
● Visual Scale
Player Elements
● Type of States (Default, Damage, Destroyed, etc.)
● Amount Animation Frames
Heads Up Display (HUD)
● Type Icons
● States
● Font Type
Antagonistic Elements
● Type of States (Default, Damage, Destroyed, etc.)
● Amount Animation Frames
Global Elements
● Background/Texture/Tiles
● Font Type

Audio Content
This is the section for organizing the audio content. It is very important to communicate
with the audio designer before and while the audio content is being developed.
General
● File Size Restrictions
● File Format Type
● File Quality Type
Player Elements
● Type of Sound f/x
● Device Vibration
Antagonistic Elements
● Type of Sound f/x
● Device Vibration
Global Elements
● Ambient Music
Splash Screens
● Ambient Music
Menus
● Type of Sound f/x

Programming Content
The programming content section should help permit good collaboration with the
programmer. The objective of this section (and task) is to try to organize and modulate as
much as possible.
General
● Requirements
● File Size Restrictions
● File Format Type
● Specify Coding Conventions
● Language/Device Restrictions
● Screen Type (Small, Medium, Large)
Player Elements
● Type of Event
Antagonistic Elements
● Type Event
Global Elements
● Type of Event
Splash Screens
● Type of Event
Menus
● Type of Event
● Type of Options

Code Structure
This is where an overview of how objects/functions/data interact, a list of what specified
functions/routines do, and a list of what order modules will be written.

Concerns and Alternatives

If there are concerns about something technical, they should be stated here, along with
any alternatives to the concern.

Resources
The resources section lists applications and equipment that are acceptable for use in the
development of this game. This begins to satisfy a legal challenge that developers must
begin to be aware of.

Technical Matrix
The technical matrix section will be split into the different device series for each content
category.
The technical matrix includes the content lists of Audio, Visual, and Programming.