Companies that built a competent structure for working with gdd  heard a lot of negativity about design documents. Game designers found all sorts of inventive excuses not to keep records.

What’s the bottom line?

You don’t get what you want from the artist (for example, an artist).

In turn, the producer also gets from you not what was needed.

You are wasting time on unnecessary explanations and additions that could have been avoided.

You forget what decisions were made. In this case, you will most likely have to rethink the feature. And the deadlines are already running out, and the result, most likely, will not turn out the same as originally intended.

The compilation of game design documentation allows you to solve these difficulties. In fact, a design document, or GDD is a complete description of the game with permanent fixation of the decisions made on the project. This is an evolving document from which a team member can get any necessary data on the plan.

Documentation is of several types. This can be either a complete explanation of the scheme, including marketing aspects, or a thorough information of one specific feature. In general, to know how to make a game design document, pay attention to the following data:

• explanation of the game (target audience, platforms, style);
• gameplay scheme;
• type of the mechanic and interface;
• technologies used in the development;
• requirements for graphics / art design / sound;
• plot / lore;
• designer’s notes.

GDD solves not only the problem of informing the team about the state of the game. It is needed for a competent and effective set of tasks for performers (developers, artists, animators). Thus, documentation, as a kind of litmus test, allows you to track progress, assess the quality of work, and better plan work. If there is documentation where everything is described in detail, it is easier to correctly estimate the costs of developing a particular feature. In addition, it is the design doc that may be considered the effect of the work of a game designer, the endpoint that sends a clearly formulated idea for implementation.

Three horsemen of the GDD apocalypse

There are three mistakes that can negate all the benefits of designing a design doc. They are quite obvious, but, as practice shows, even the most obvious things sometimes need to be pronounced. So:

1. Ambiguity/incomprehensibility

Everything is simple here – all your theses, ideas, and results of calculations should be stated unambiguously. Don’t let people think for you, don’t offer several options for completing a task to choose from, don’t hope that colleagues can read your thoughts and don’t confuse colleagues with multiple literary phrases.

2. Illiteracy

Reading the documentation grows much more difficult if the text is full of spelling, grammar and punctuation problems. Take care of this.

3. Information is not necessary

In the creative process, it is easy enough for a game designer to indulge in lyrical digression when it comes to a favorite character, mechanic, or item. Remember about the “skeleton” – those things that must be indicated in the design doc (for example, if we are talking about a unit – damage, attack range, description of combat mechanics, and so on). And nothing else. All new ideas and additions can be left for notes. They should not be in the main document.

It is also worth noting that you always need to remember for whom you are writing GDD. For example, artists most often do not need precise formulas for calculating certain indicators, but for programmers they are necessary. For UI designers, interface diagrams, ordering of numbers, a list of important factors, and transitions are very important, while for almost all other departments this information will be superfluous.

Advice

Here are some tips from experience that will hopefully make it easier to work with game design documentation.

1). Keep the data up to date and complete. An outdated or unfinished design doc is almost as bad as missing one. To understand a project and develop it correctly, you need to constantly see the overall, truthful, detailed picture.

2). For paperwork, it is best to create a separate small regulation, according to which everyone will understand how to draw up a GDD.

3). When working with configs, write down in the design dock those mechanisms and structures that you want to vary in the future when setting up mechanics. If you do not do this in advance, there is a great chance that later you will have to ask programmers to “pull” from the code what could be immediately brought to the surface.4). Observe the unity of the naming. Agree “on the shore” and record in the documentation how the units, items, etc. will be called in the team. Read more on https://whimsygames.co/blog/game-development-cost/