A game designer is the person behind every game. He devises the game’s idea and regulations, as well as informing each team member of his responsibilities. A game design document is the key instrument in this specialist’s hands.
A game design document, often known as a design doc or simply GDD, is a full–fledged technical documentation of a game, a project’s “bible,” and an auxiliary tool with the fundamentals that will drive a team’s activities even if a game designer “falls out” of communication at the worst possible time. Are you looking for a company that provides a full cycle of game development? Your answer – game development company – Whimsy Games.
A game designer collaborates with divisional leaders to build GDD. Any team member (programmer, artist, tester, project manager, technical support expert, and others) must be able to access the GDD, browse through it quickly, and get a clear guidance to action.
A terrible design document is one that fails to address the fundamental questions of what and why. It’s improbable that the folks working on the implementation have any broad queries after reading the documentation.
In our material, we will talk about how to form an effective GDD, which will be understandable and accessible in all respects. So where do you start writing the main project manual? There are many popular services for organizing documents (Confluence, etc.), but you can arrange information in Google Docs.
The amount of GDD depends solely on the size of the project. For a simple hyper–casual game, maybe 3–5 pages will be enough. But if you take on the implementation of something more global, with more levels, storylines, features and screens – the document can significantly “grow“. The main thing is to describe everything accurately, not beautifully. After all, it is necessary that navigation through the document was convenient even for those who opened it for the first time.
Be prepared that the GDD will change with every update of the game. Some processes will be optimized, new features and characters will appear, ways of presenting information will change, etc.
Let’s start with the structure. It is individual for each project, but conditionally it can be divided into headings:
- Table of contents
- Introduction
- Narrative
- Gameplay
- Interface
- Features
- Analytics
Table of contents: here it is worth describing the project hierarchy, links for navigating the document.
Introduction: we add a short description of the game, its positioning, basic mechanics, setting, target audience – everything that will help to understand from the first page how the creator sees the future product.
Narrative: history of a place and event, lore, information about characters, quest elements.
Gameplay: gameplay with all its mechanics and ways of interacting with the player.
Interface: this part of the document should be designed as a mockup – block diagrams of all screens and windows of your game: where and where you can get from each separate page. To do this, you can use Moqups, InVision, Gliffy or any other analogue.
We also recommend breaking down the structure into clauses and lists where possible.
For example:
- The player is invited to put a new piece of furniture in the mansion
1.1. If the player has enough stars, he buys the item
1.2. If the player does not have enough stars, he is asked to complete the level of hidden objects.
Features: item functions, resources and other features, game features.
Graphics: art guide, formats, working with text and other standardization, characteristics of characters and windows. It is important to note here that you should avoid unnecessary description of the animation. For example:
No: “the character jumps up in place, raising his hands up, frightened by the noise in the fireplace”;
Yes: “the character gets scared.”
It is important to clearly define the task, and leave the nuances to the animator – he knows better how to make the character’s emotions as realistic as possible.
Analytics: A / B tests, multi–source statistics and metrics tracking.
Some more helpful tips:
- Please feel free to use visuals to help explain the content. It’s weird to talk about a window or a character without including a picture of it in the text; huge files containing references (photos, videos) “burden” the page substantially, and the quality of these files suffers as a result. Pictures may be uploaded to a file hosting provider or extracted into a separate document, and the video can be published to YouTube with simply GDD links;
- phrases should be brief and instructive. Remember, we’re not creating a book, but rather a how–to manual;
- the document must be in order: the content must be well–organized, and each link must have a signature.
Returning to the topic of a good GDD, we can say that when creating and editing it, you need to put yourself in the shoes of other team members and players, asking yourself the questions: “Is it possible to misinterpret this point?”, “Will the person have additional questions?” “Is it easy to navigate the document?”
However, you shouldn’t chase the perfect design doc. Let it optimize and update in parallel with the development of your project! If you want great game animations, watch here.
