Game Design Documentation (GDD) *
What is a Game Design Document, and why you should try to create it before starting a game?
The term Game Design Document (GDD) is commonly and loosely applied to any documentation used to align all the work involved in the creation of the game.
The GDD should always be created before starting development. If you have a simple game being made solo or by a small team that communicates every day then you can have a small GDD. As the size of a game increases so should also it's GDD become more in depth. This will help to make sure everyone involved with the game will have the same goals and objectives while working in the game.
It should provide a starting point to explain the game idea to yourself, to a team or to a publisher/partner.
It is a central reference point that should provide the information needed by everyone involved with the game, in such a way as to bring confidence that they know how their work is contributing to reach the expected final product.
It can be used as an historic reference when doing an analysis of how an ongoing project (or finished project), is being developed compared with how it was projected initially.
It should be prepared in a way that each team member can find the relevant information for them, from:
the idea originators - to explain what the game is about.
the development team - to explain how the game is supposed to be played.
the art and sound/music team - to explain what the game mood is expected to be.
the marketing team - to explain how the player will find the game and what their first experience will be.
the distribution team - to explain ways the players will be able to acquire the game.
GDD contents
Although a GDD could initially be as simple as a one page word document describing the game, it should be developed and maintained so that it reflects all that is expected of the game in terms of player interactions, team needs, marketing needs and information needs.
Player interactions:
Expected main game context(s) of the players? (shooting, management, exploration, interaction with other player)
Other game contexts the players can do in the game?
Team needs:
Expected platforms and devices the game will be played? (desktop, mobile, console, web, etc)
Expected team members available for each kind of development? (Activity, Number, Time, etc)
Expected availability of space and resources for each kind of development? (equipment's, Time, workplace, etc)
Special event dates? (game fairs, holidays, alpha/beta testings, etc)
Marketing needs:
Expected communities for the marketing actions? (ex. Discord channel, Kickstarter page, Twitch channel, Youtube channel, etc)
Expected team members available for each kind of action? (Activity, Number, Time, etc)
Expected availability of space and resources for each kind of action? (equipment's, Time, workplace, etc)
Special event dates? (print/web publications, game fairs, progress notifications)
Information needs:
Who are the people responsible for each part of the game? (Design, Development, Marketing, Partners, etc)
What is the information needed by each.
Amount of documentation
Incremental documentation
Usually when the game is developed for an external client to the development team. This means every possible change has to be approved by multiple sources.
Could also be used if the team is going to make a new game that is very similar to a game that was create previously.
The first version of the GDD is agreed upon before the game production starts, and is used to plan/estimate the game development that will be made.
Feedback is collected and at regular intervals is used to create a new GDD version proposal (by the dev team, client or third party).
The new version of the GDD is reviewed and if approved, results in programmed changes for the game production.
Live documentation (smaller teams or new kind of product)
First version is agreed upon before the game production starts.
Feedback is sent to one element of the team that reviews it and chooses if it is to be updated in the GDD.
When the GDD is updated the team is informed of the changes, and makes the necessary changes in the game production.
You could have simple sentences explaining each point, or formalize each point in the format Goal / Objective / Outcome, where:
Goal - why are we going to do this?
To become a marked leader.
Objective - what is expected to be done to achieve the goal?
Sell 10000 units in first 24 hours of release.
Expected outcomes - how to track if the goal and objectives are progressing positively.
Have positive brand recognition reflected in google analytics data.
Section examples
Brief description of the game idea
What inspired it and what makes it stand out in the market.
Game Goals, Objectives and Outcomes
For the company
For the players
Art
Backgrounds
Characters
Type of animation (ex. pixel, realistic, stylized)
Company
Branding
Partnerships
Gameplay
Mechanics that allow the player to achieve Objectives.
Game mood.
Tasks to do in game.
Marketing
Target users
Target platforms
Development team
Team members and responsibilities
Time breakdown
Work breakdown
Sound
Characters
Environments
Music
World story:
Backstory (current game)
Backstory (other related games)
Game story (by player)
Game story (by npcs/narrator, non interactive elements like video)
End story (single, optional by game outcome, multiple endings)
Links
Usually a GDD is used in one of two ways:
Last updated
Was this helpful?
