GDD – Game Development Document Template

EDITING NOTE: REMOVE ALL ITALIC TEXT BELOW BEFORE YOU PUBLISH

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

GenreDescribe the Genre, Examples are listed below:

  • 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, Examples are listed below:

  • ™Shooting
  • Collecting
  • Chase
  • Combat
  • Dodging

Game Content

Examples are listed below – pick one:

  • ™Horror
  • Thriller
  • Humor
  • Drama

 Theme

Examples are listed below – pick one:

  • Western
  • Sci-Fi
  • Fantasy

Style

Examples are listed below – pick one:

  • Real
  • Old School
  • Manga

Game Sequence

Examples are listed below – pick one:

  • Linear- Storylines
  • Hyper- Storylines that the player can influence
  • Simulation

Players

The Number players that can play the game at once

Game Story

Story Idea

  • The idea for the story was excellent.
  • Message extremely clear.

Characters

  • Characters are extremely interesting excellent effort.
  • Characters are extremely suitable to storyline.
  • Main characters are named and very clearly described (through words and/or images).

Setting

  • Many vivid, descriptive words are used to tell when and where the story takes place.

Problem/ Conflict

  • It is very easy for the reader to understand the problem the main characters face and why it is a problem.

Game Storyboard

Sketches for all scenes. Shows excellent planning and organization of visual details.

  • Titles,
  • Detailed notes
  • Transitions
  • Special effects
  • Sound all described

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, Simulation and Narrative. This is further divided into fiction or non-fiction.
  • Example: Xyanide is a Fictional Game/Narrative, while Sim City is a Non- Fictional 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.

Atmosphere Mood Board

A Level (Locations) Sketch & Description

Character/Units Sketch & Description

Audio Description

Game Play

The game play section is utilized to create a descriptive paragraph about how the game is played. The idea is that you want the person imagine they are actually playing the game. Try not to use ge- neric (i.e. broad, non-descriptive) names when writing about the game play.

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 – include what makes sense.

  • Opening the game application
  • Game Options
  • Story Synopsis
  • Modes
  • Game Elements
  • Game Levels
  • Player’s Controls
  • Winning
  • Losing
  • End
  • Why is all this fun?

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 – include what makes sense.

  • 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)
  • Replay ability
  • Audio Specifications
  • Graphic Specifications
  • Device Compatibility
  • Number of Players
  • Online Activities (high scores, etc.)
  • Number/Type Modes

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 – include what makes sense.

  • Marketing Ideas
  • Unique Features
  • Consumer Group
  • Merchandising

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.

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.
Game Design Definitions
In this section, the definition of the game play is established. Definitions should include how a player
wins, loses, transitions between levels, and the main focus of the gameplay.
Issues that should be addressed here are:
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 with
in the game mechanics document.

  • Menu
  • Synopsis
  • Game Play
  • Player Control
  • Game Over (Winning & Losing)

Player Elements

The player elements section lists all the elements that are directly related to the player or serve to
benefit of 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 game play should be exhibited here.
  • Multi-player issues should also be mentioned here.

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 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 a 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 affect 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.

  • 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?

Heads up Display (HUD)

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

Player View

A screen shot 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 a
levels size 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 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 player has reacted correctly or incorrectly to 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 story board 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 to game story and style.If cut scenes use
video then story boards should be created.
Menus should be designed with the most important options easily accessible. Be aware 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 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

Menus

  • Type of Sound f/x
  • Font Type

Options

  • Add here

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 conc
ern.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *