How to write a game design document

by Xozepew Usaz We are always in the lead!

Before starting to tell the rules for compiling a GDD, let's define who a game designer is and what is his role in the team. The closest analogue of a game designer in art is a director. He does not act in the film, does not deal with lighting and scenery, and does not even hold the camera, but at the same time it is he who decides how the film should look so that it conveys to the viewer the feelings that the director wants. Also, a game designer very often does not know how to draw and program, but he must be able to evoke the necessary sensations in the player. If you want a quick look at instructions, and examples of game design documents, go here https://whimsygames.co/blog/game-design-instructions-examples/

Therefore, he can be called the brain of the team, the one who always controls what everyone else is doing. Gives assignments and accepts work. Therefore, the main skill of a game designer is to find a common language with everyone in the team and make sure that they produce exactly what is in his head. Therefore, ideally, each project should be led by one good specialist. How difficult it is to find one is a completely different topic. Let's just keep in mind that this article is about a good game designer or someone who wants to become one.

You probably noticed that among the duties of a game designer, I did not mention GDD. Because in an ideal spherical world it is not needed. There, the game designer always keeps descriptions of all the features in his head, never gets sick, never quits, and he does not need to report to anyone. The game design document is a supporting document. The studio’s insurance against the loss of a game designer, a reminder of what he wanted to do, because development can sometimes be stretched out in time for reasons beyond his control, and a reminder for specialists about what they should do if they suddenly get distracted.

It is important to single out the human factor here. Even with the most ideally written terms of reference (hereinafter referred to as TOR), there will be those who will misunderstand it. Someone is misinterpreting a turn that is obvious to you. Someone will not know the term or will know its homonym (which are quite common in the industry). Someone will simply skip the line, reading diagonally. It is tough to act with such people - with a high probability of ruining your own company.

Some, wanting to save money, hire a game designer only to write documentation - the result is usually deplorable. Movies are not made without a director, even when Marvel fired the brilliant Edgar Wright and left behind the most complete storyboards, they still hired another person to complete the film. Although Wright's storyboards, of course, climb out of all the cracks and theoretically one could work on them.

Now about how to write the GDD itself. Large companies use services like Confluence for this, but after working in them, I find them not very convenient, compared to the most accessible way to maintain documentation - Google Docs. Easy to fill out, easy to share, easy to navigate, and free. If you're concerned about security, there's always the option to set up a corporate Gmail account so that no one outside the studio can access your documentation.

The next big question is GDD in one file, or as a set of technical specifications. To put it bluntly, both options are viable. The first option makes sense to use if you have a small project like match-3 or a similar game. GDD up to 20 pages is objectively more convenient to store in one piece. If you have a mountain of different modes or content, for example, a billion different tanks for WoT, or a detailed description of each level for a shooter, then it’s better to shove it all into different documents, leaving the main structure only.

It is also convenient for issuing tasks: I threw a link to a specific document - and you don’t worry about explaining where to look. But, I repeat, it is very often more convenient to store everything in one file, since many projects do not differ in size.

Table of contents

In a small project, everything is simple with this - it is done with standard document tools. Or not done at all, which also happens. If you have a large project, and even with a hierarchy, then in the main file it is better to paint its entire structure with links to all other files. If you have a hierarchy in your project, then you should not put a link to the farthest TK only in the intermediate one.

In my first month of work, I had a nuisance: I posted the aircraft specifications for World of Warplanes in one subsection (I don’t remember which one since years ago), and the programmers were looking for it in the next one (by the way, the artists didn’t miss). At first I wanted to duplicate the links so that they could be found everywhere, but then I realized that it was more correct to simply lay out all the links in the form of a structure right in the main document. Then an understanding of the project structure immediately appears and you do not need to make extra clicks to go to the desired page.

Introduction

Place for a brief description of the game. In fact, a brief summary of the concept document: name, technologies, platforms, audience. This information is not for you and not for your team, but for producers who, when opening your document, should instantly understand what they have in their hands. And at the same time understand if you messed up with positioning and your capabilities.

Basic gameplay

It is necessary to identify for yourself which part of the game you have is basic, that is, what the player will spend the most time in. For example, in the sensational Gardenscapes, the player mainly plays match-3, although this is not emphasized. There, the creators focus on arranging the garden, and match-3 is, as it were, a secondary occupation that serves to earn stars. But in fact, in this section it is necessary to describe it.

For Wolfenstein, it's all about walking and shooting. This section should also include basic gameplay controls. Look with the mouse, move forward-back-left-right, shoot on the left button, bind skills on three buttons, and one more - ult, when hit by a character, life is taken away from him, then respawn and so on.

At this stage, the question often arises: how to structure what is written so that it is easy for the programmer to read. After trying many different options, I came to the conclusion that the best thing to do is to use a different numbering with a hierarchy in each section. That is, write a statement. The next number is another statement. If you have a clarification or addition to the main statement, then go one level deep and write there. For example: 1. The character moves in isometric view using WASD. 1.1 If the player directs the character into the wall, he stops when colliding with the wall. 2. When you click on the LMB, the player shoots. And so on.

It is important to describe everything not beautifully, but precisely, without missing the slightest aspect. A bug made by a programmer is repaired by him in a limited time. A design bug (an ill-conceived moment) can wipe out many months of team work at once. “The one who does nothing is not mistaken” is a great phrase for this situation, because it’s not realistic to foresee everything, but it’s one thing not to think through one screen, and quite another is a mistake in the basic mechanics, due to which everything is unplayable.

In the first three or four years of work as a game designer and in the first three or four months in a new job, you are obliged to make friends with the lead of programmers in order to send him freshly written technical requirements with the question: “Is it okay?”. This significantly improves their quality and reduces the time spent on proceedings.

Returning to the topic of a good game designer for a moment, I can say that every second he must put himself in the shoes of other people and ask himself questions: “What do I understand from this screen?”, “What will be clear to an ordinary gamer?”, “Where would I click , if you opened this menu for the first time?”, “How can a person interpret this icon?” and about a billion more. The main question of a game designer (if you go into the wilds) is “Why?” . From "Why is PUBG so popular?" to “Why is this feature that I came up with going to be in demand?”.

HUD or base game interface

Head-up display - all the information that a person sees when playing a first-person shooter. Health, ammo, markers on the screen and the like. In other genres, its counterpart can be called differently, but in any case, this is what the player sees during the basic gameplay. This is one of the most important things in the game - the player must understand what he is playing, but at the same time it should not distract him from the gameplay.

In fact, the art of creating a good HUD is a huge science, in which there are very few specialists. It is best to compile it together with the art lead and be prepared that you will probably have to redo it.

Interfaces and main menu

I want to start this section of the article with a story about what a mocap is. Or warframe. In the industry, very often the same entities are called differently in different studios, and if you have something from what I call in the article called differently, this is the problem of the lack of a single professional dictionary. So, this is a schematic sketch made in a graphics editor by a person who is as far from drawing as possible. Here the task is not to make it beautiful, the task here is to make it clear. So that the artist, without any questions, harmoniously arranges the buttons and everything else.

Personally, I use the Pencil Project program for this, but you are free to choose whatever you want. At least draw and photograph with a pencil on paper. Instead of pictures - rectangles, circles, arrows. Minimalism.

Now about what we will draw with these very programs. The best place to start is with the screen layout. Take all your screens and windows and lay them out on the screen. Draw arrows: from where to where the player can go. This is a kind of interface table of contents that will help to assemble the project.

Next are the mockups of all windows, starting with the main menu and ending with the smallest window with the OK button. Don't forget how to get out of them! Below each mockup, there should be a short and clear description of each button and other window element and what they do. A life hack for complex screens: put a circle with a number next to each element, and numbered points below.

When the artist draws this window, I recommend applying the same circles to his drawing and replacing it in the GDD. This keeps it fresh and understandable, especially if something has changed during the rendering process, such as the position of the buttons.

Other features

Then we just break the project into small components and describe each in its own section. Tutorial, inventory, dialogues, global map, leveling - everything you have. Everything is described in the same way as the basic gameplay. For each of the features in the section, you should put a mockup of what is connected with it.

Functional sections

Several sections can be inserted at the end of the GDD, which are very useful for some genres.

Balancing - a description of the way gd will balance the game. Needed for almost all games, especially f2p. The best option for me is an xml file that is converted and uploaded to a special address. A potentially terrible option is the web interface, in which each parameter must be entered manually.

Admin panel - the ability to ban and encourage users through the web interface. Required for online games.

Gathering statistics is a vital thing for f2p. List all points for collecting statistics and the format for obtaining them.

Minimum Value Product or MVP is a description of the minimum playable version that can be made available to the public to test how much your basic gameplay is in demand. Necessary if you are doing f2p and come up with original gameplay.

What should NOT be in the GDD?

First of all - descriptions of animations. This is the most common mistake newbies make. Name the actions specifically: "The gun shoots." Yes, you have a cartoonish style and the gun inflates before the shot, as if pushing - all this is not important for the programmer, and the animator knows the features of the engine better than you and how to make everything atmospheric. And it is better to convey wishes to him personally.

References. Pictures make files unbearably large, and those in turn reduce their size, so it’s better to upload them to a folder on a dropbox, svn or google drive. A separate folder for each entity, of course. It is better to upload the video to YouTube and give direct links.

texts. Select a separate file for them, preferably xml, so that programmers can easily pull it right into the game. And then you will localize it.

Literary descriptions - no one will appreciate.

What's next?

After you have written all the technical specifications and the lead programmers confidently said “Normal”, you move on to the main part of the game designer’s job – communication. If you like this article, then I will write another one - how to properly issue work to different specialists and accept the results.

Do not forget that everything described in this article is not the norms (although if you take them for yourself and make them the norms, I will not be against it), but the result of my many years of work as a game designer. Nobody is stopping you from doing better.