How to Write a Game Design Document: Structure, Tips, and Common Mistakes

Game designers stand at the forefront of every game. They create the concept and rules of the game, conveying tasks to each team member. The main tool in the hands of a game designer is a game design document.

A game design document, or just GDD, is a full-fledged technical documentation of the game, the “bible” of the project, and an auxiliary tool with the basics that will guide the team even if the game designer falls out of communication at the most inconvenient moment. A GDD is created by a game designer in collaboration with department leads. Any member of your team can open the GDD whenever they need to, quickly navigate it, and get a clear guide to action.

“A bad GDD does not answer the main questions of what and why. After reading the documentation, the guys involved in the implementation shouldn’t have any big questions,” says Evgeny Chuvychin, Lead game designer at VOKI Games.

This article will discuss how to form an effective GDD that will be understandable and accessible.

A GDD that leaves no questions

Where do you start writing the main project manual? There are many popular services for organizing documents, such as Confluence, but you can also arrange information in Google Docs.

The volume of the GDD depends solely on the scale of the project. For a simple hyper-casual game, 3-5 pages might be enough. But if you’ve taken up the implementation of something more global, with a large number of levels, storylines, features, and screens, the document will significantly grow. The main thing is to describe everything accurately, not beautifully. You want to make sure navigating the document is convenient even for those who open it for the first time.

Be prepared that the GDD will change with each update of the game. Some processes will be optimized, new features and characters will appear, the methods of presenting information may change, etc.

Let’s start with structure. For each project, it is individual, but conditionally, it can be divided into headings:

• Table of contents
• Introduction
• Narrative
• Gameplay
• Interface
• Features
• Analytics

Table of contents. Here, it’s worth describing the hierarchy of the project and links for navigating through the document.

Introduction. We add a brief description of the game, its positioning, basic mechanics, setting, and target audience – everything that will help you understand from the first page how the creator sees the future product.

Narrative. The history of the place and events, lore, information about the characters, and quest elements.

Gameplay. All mechanics of the gameplay and ways of interacting with the player.

Interface. This part of the document should be designed as a mockup – a flowchart of all the screens and windows of your game – where you can get to and from each individual page. You can use Moqups, InVision, Gliffy, or any other equivalent.

Write and abridge

We recommend breaking down the structure into bullet points and lists where possible.

For example:

1. The player is invited to put a new piece of furniture in the mansion.

1.1. If the player has enough stars, they buy the item.

1.2. If the player doesn’t have enough stars, they are offered to complete the level to search for items.

Features. Item functions, resources, game features, and other features.

Graphics. Art guide, formats, text work and other standardization, characteristics of characters, and windows. It would be best if you avoided unnecessary descriptions of the animation:

Wrong: “The character jumps in place, raising his hands, frightened by the noise in the fireplace.” 

Right: “The character is frightened.” 

Define the task clearly and leave the nuances to the animator, who knows better how to make the character’s emotions as realistic as possible.

Analytics. A/B tests, statistics from different sources, and tracking metrics.

Some more helpful tips:

• Feel free to illustrate your information. It’s easier to describe a window or a character when you have an image to go with your text.
• Large files with references (pictures, videos) may overload the document and lose their effect. 
• You may upload pictures to a file hosting service or put them into a separate document. As for your videos, upload them on YouTube and add the links to the GDD.
• Your sentences should be short and informative. Remember, you are not writing a novel but a guide to action.
• The document should be in order, the text neatly formatted, and each link in the right place with a signature.

Back to the topic of a good GDD, we can say that you need to put yourself in the shoes of other team members and players when creating and editing it. Ask yourself the following questions: Can this paragraph be misinterpreted? Will the person have additional questions? Is the document easy to navigate? 

However, don’t chase the perfect GDD. Let it be optimized and updated in parallel with the development of your project!