Violet sky
GAME DESIGN DOCUMENT (GDD) TEMPLATE
Game Name:
Genre:
Game Elements:
Game elements are the basic activities the player will be doing for fun
Player:
The number of players that can play the game at once
TECHNICAL SPECS
Technical Form:
Basically there are 2D graphics (flat) and 3D graphics (form)
View:
Camera view from which the player will experience the game
Platform:
iOS, Android, Mac, PC
Language:
C#, C++, Ruby, Java
Device:
PC, Mobile, Console
GAME PLAY
Use the game play section to create a descriptive paragraph about how the game is played. You want the
use tor imagine they are actually playing the game. Try not to use generic (i.e., broad, non-descriptive)
terms when writing about the game play. For example, few readers want to hear statements such as,
“enemy_1 will have more hit points than
enemy_2.” Instead, it’s better to make statements like, “The Lazarus Fighter has more armour than the Apollo
Fighter.”
Game Play Outline
This outline will vary depending on the type of game.
• 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.
DESIGN DOCUMENT
This document describes how GameObjects behave, how they’re controlled and their properties. 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 you
could have several different Game Design Documents attached to the Concept
Document.
Design Guidelines
This is an important statement about any creative restrictions that need to be considered and includes brief
statements about the general (i.e., overall) goal of the design.
Game Design Definitions
This section established the definition of the game play. Definitions should include how a player wins, loses,
transitions between levels, and the main focus of the gameplay.
Game Flowchart
The game flowchart provides a visual of how the different game elements and their properties interact.
Game flowcharts should represent Objects, Properties, and Actions present in the game. Each of these items
should have a number reference to where they exist within the game mechanics document.
• Menu
• Synopsis
• Game Play
• Player Control
• Game Over (Winning and Losing
Player Definition
● Use this section for quick descriptions that define the player
● Use the Player Properties section (below) to define 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.
● Use the Player Rewards section to make a list of all objects that affect the player in a positive
way. Define these objects by describing what affect they cause and how the player can use the
object.
Player Definitions
A suggested list may include:
• Health
• Weapons
• Actions
Player Properties
Each property should mention a feedback as a result of the property changing.
Player Rewards (power-ups and pick-ups)
Make a list of all objects that affect the player in a positive way (e.g., health replenished)
User Interface (UI)
This is where you’ll include a description of the user’s control of the game. 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 you 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.