Creating a GDD

What is a GDD

GDD is the short form for Game Design Document, a written documentation used during a game’s development, that contains all information necessary to create the project and what purposes these elements have.

It’s the place that contains/references the location of balancing values or other non-persistent game information to avoid having duplicate versions of data tables, feature descriptions or balance sheets.

It also contains information about the game in general, which can be used for pitching, marketing or just to talk about the game.

The GDD should also contain technical and workflow information like specific import or plugin requirements, how-tos for critical software like version control and naming conventions or folder structures (This can also be placed in a different document if this is preferable)

Why write a GDD

There are many reasons why a GDD eases the creation of a project. Most of them are centred around improving communication and the ability to retrace previous thoughts later in development.

→ A GDD allows to quickly check on relevant information about the project or a feature to ease communication with the client, third parties or press/marketing.

→ A GDD allows team members to familiarise themselves with the project or a feature before going into a meeting, shortening meeting times significantly.

→ A GDD allows new team members to read up on the project reducing the load on the original team members during onboarding.

→ A GDD forces a Designer to formulate every concept into a readable/visualizable form resulting in more defined designs.

→ A GDD allows checking why early decisions have been made during later stages of development and can therefore inform new decisions about if something should be changed and if yes what the team must be aware of.

→ A GDD will feature visual indicators for features making it easier to talk about them during meetings.

→ A GDD has an overview of all elements in the game which offers a list that can be used for prioritization, to make sure that everything needed has been added to the project, estimate the overall work required to complete the project and make certain duplicate features are minimized.

→ A GDD is an online space that contains all relevant information, which reduces the likelihood of contradicting information in duplicated files.

→ A GDD contains general metrics for the project allowing all team members to work with the same parameters.

There are many additional benefits that will be specific to a project.

General Game Design Documentation Overview

The purpose of the Game Design Documentation is to make information accessible to the team and to give a point of reference that can be used later during the project to understand why initial decisions have been made. To do this in an effective way it is crucial that the information in the documentation is complete and easy to find.

Usability and navigation:

It should be easy for all team members to access the GDD
- Online wikis are generally suited best for this
The documentation should be easy to navigate
- Page titles should be easy to understand
- Relatable sorting structure
  - Potentially a page explaining the sorting structure
- A search function
- Table of contents containing all pages and one on every larger page containing the headers

Overall useful pages:

A page that quickly summarizes the game
- Overarching narrative
- Art style
- Logline
- Core loop + gameplay description
- Special features
- Special hardware features/requirements
A page containing naming conventions for all project-related files
- Every team member should be aware of them
- Should always be up to date
Table of contents

Useful sections for feature briefs:

Start pages with short summaries, including the purpose and how it works
Detailed feature description
If applicable: Include a section for technical implementation and how to use
If applicable: Include a section about how the feature should look like
Include a section that allows departments to leave notes for other departments
- For Example:
  - Meshes for a feature need a specific collision setup
  - An element is intended for the background and not close to the player

Basic GDD structure

The GDD should contain all information necessary to create the project, much of this information is only available after development has started, so it will be essential to update the GDD while working on the project.

To make this easier it is recommended to create a structure that is flexible enough so it can be edited later while still making sure that the documentation is easy to navigate. A very basic example is listed here.

Title page
Content table
Project summaries
- Overarching narrative
- Art style
- Logline
- Core loop + gameplay description
- Special features
- Special hardware features/requirements
Relevant working information
- Naming conventions
Narrative information
Feature briefs
- Listing of all game features + sub-features
Level design
- Level design guidelines
- Levels
- How-tos
Art
- Art Guidelines
- How-tos
Tech
- Tech briefs
- How-tos

Feature brief example

A feature brief example using the control elements for Blast the Past to showcase what a complete feature brief could look like.

General description:

The vehicle should feature a number of control options that can all be physically interacted with. These controls should feature a small variety in how they can be interacted with and should feature elements that make their interaction and purpose easy to understand. The purpose of these interactions is to make the gameplay feel more hectic which is the intended emotion for the game, while also pushing more tactile physical interactions relating to one of the core pillars.

Placement:

There should be a large number of control elements to make the experience more hectic and chaotic, and because of that each control element should navigate a single thing the vehicle can do. These control elements should be spread out in the entire vehicle so the player has to move around more pushing deeper into the options VR creates. In addition to that, each primary control element must be far enough apart so the player does not accidentally interact with the wrong thing.

Primary control options related to the crank and arm movement and rope control elements.

Vehicle control options:

The vehicle gives the player control over a variety of movement and play elements which will translate to indirect methods for the player to destroy the main building.

Movement the vehicle can move left and right along a rail
Crane arm movement the arm of the crane can rotate along two axes to allow for up/down/left/right movement
Extend/retract rope the rope on the arm should be able to extend and retract
Extend/retract arm length
Open/close windows
Horn that can be active for any amount of time.
Start vehicle event that activates all other control options
Windshield wiper toggle that can set them active/inactive
Quit game button
Item spawn/select interaction to 3D print collected items

Control elements:

All controls are physical and mounted in a way that incentivizes the player to understand what effect they have this is achieved by placing them in a way that allows the player to see the result of the interaction while using the control element from the seat position while also looking at the control element.

Control options:

Buttons = Can be pushed by simply touching them
- Can trigger an event
Switches = Will switch state by simply grabbing them
- Can trigger an event with a bool
Lever = Must be grabbed and then dragged along an axis
- Update between a 0-1 value
Joysticks = Must be grabbed and then dragged on a 2D plane
- Update between a -1-1 value can be used at two axes at once if needed
Pullables = Must be grabbed and then dragged for a certain distance
- Can trigger an event for a duration
Cranks = Must be grabbed and then rotated around a fixed point
- Update between a 0-1 value

Visual indicators:

All control elements will feature a grip section that can switch colours to indicate the current state of the element.

Grey = Disabled
- The player cannot grab or interact with the control element
Orange = Useable
- The control element is usable but the player does currently not interact with it
Light Green = Can be grabbed
- Indicates that this control element would be grabbed if the player presses the grab button
Green = Currently Active
- The control element has been grabbed by the player and is currently in use

The One Sheet

While creating your GDD you usually also want to create a One Sheet. The One Sheet is a single page containing enough information to understand what the overall game will be like use the project summary pages created for the GDD as a baseline to create the One Sheet.

Project summaries
- Overarching narrative
- Art style
- Logline
- Core loop + gameplay description
- Special features
- Special hardware features/requirements

The One Sheet will mainly be used to communicate the project to external parties like publishers or press but can also be used during onboarding. In any case, it should be visually appealing and feature a lot of visual aids.

Metrics

The GDD is a place to collect the metrics every team member should relate to. These metrics change from project to project but in general, these will be values that should be consistent for every section of the project and can frequently not be changed easily during later stages of development. These metrics are usually collected on guideline pages.

Examples are: Player character scale + camera position which can affect door sizes/hallways/etc.; Jump height; Fall damage heights; Player speed; Player base health; Basic weapon damage; Basic enemy damage; Max damage enemy; Basic enemy Health; Max health enemy; Color patterns for each area; and lots more depending on the project.

Having all of this in a place every team member can reference makes sure that every game section can function using the same base ruleset.

Data collection

The GDD is the place where all project data is displayed. This covers feature lists, balancing information, voice line relations, and basically every other piece of information a project has to offer. This has the intention of avoiding duplicate files that will then be updated independently resulting in contradicting information.

If it is not possible to save the information in the GDD, the GDD should offer a path and file name to the place the information is stored and the file in this location will always be considered the most up-to-date version.

If a project is at a stage in which data like balancing information can be stored in the actual project the GDD information should be labelled as pre-iteration and link to the location of the currently used data within the project to avoid duplicate work.

Frequently useful pages

The GDD should contain all the information necessary to create the project. These are a few things that are frequently required for a project.

Project Description
Characters
Story
Story progression
Theme
Gameplay
Goals
User Skills
Game Mechanics
Challenge
Losing
Winning
Art Style
Music and Sound
Technical Description
Marketing and Funding
Target Demographic
Platforms
Monetization
Localization
Pipeline information
Naming convention/Folder structure

GDD examples

GDD examples, these are very basic but the structure is OK
https://philippstenger.com/projects/mute-the-flute/
https://philippstenger.com/projects/blast-the-past/

Old documentation format, recommended for content, not structure
http://gameshelf.jmac.org/2008/11/13/GrimPuzzleDoc_small.pdf
https://mikaelsegedi.blogspot.com/2015/02/game-design-document-from-

GDD software

https://www.atlassian.com/de/software/confluence
https://js.wiki/
https://hacknplan.com/
https://tiddlywiki.com/