Why keep documentation when developing a game, how to do it correctly and what tools to use for this, – said Anton Podakin, the leading game designer of Rocket Jump studio.
The report, based on which the material is published, was read in early October at the Higher School of Business Informatics of the HSE.
Anton Podakin
Why is it important to write a design document?
For 8 years in the gaming industry, I have come across different points of view about creating game design documentation. Before working at Rocket Jump, where we built a competent structure for working with GDD, I had heard quite a lot of negativity about disdocks. Game designers found various inventive excuses not to keep documentation. Here are some of them:
What is the outcome?
- You get from the performer (for example, the artist) not what you wanted.
- In turn, the producer also gets the wrong thing from you.
- You are wasting time on unnecessary explanations and additions that could have been avoided.
- You forget what decisions were made. In this case, most likely, you will have to think over the feature again. And the deadlines are already pressing, and the result, most likely, will not turn out the way it was originally intended.
The compilation of game design documentation allows you to solve these problems. In fact, a design document, a disdoc or GDD is a complete description of the game with a constant fixation of the decisions made on the project. This is a developing document from which a team member can get any necessary information on the project.
Documentation has several types. This can be either a full description of the project, including marketing aspects, or a thorough description of one specific feature. In general, a game design document may contain the following information:
- Game description (CA, platform, genre);
- gameplay scheme;
- description of mechanics and interface;
- technologies used in the development;
- requirements for graphics/art design/sound;
- plot/ent;
- notes of a game designer.
GDD solves not only the task of informing the team about the state of the game. It is necessary for competent and effective task setting for performers (developers, artists, animators). Thus, documentation as a kind of litmus test allows you to track progress, evaluate the quality of work and plan work better. If there is documentation where everything is described in detail, it is easier to correctly estimate the development costs of a particular feature. In addition, it is the disdock that can be considered the result of the work of a game designer, the endpoint that sends a clearly formulated idea for implementation.
Documentation is written to simplify all processes within the team. One way or another, representatives of almost all project development and support departments will contact her:
- game designer;
- producer;
- QA;
- programmer;
- UI designer;
- screenwriter;
- artist;
- marketer / community manager;
- a new employee of the company.
In each case, a person “pulls out” the information he needs from the document. And it is from the game designer that its quality and integrity depend.
Of course, a design document is not a panacea. But it saves both your time and the time of your colleagues, and, as a result, improves the quality of the final product, eliminating the effect of a “broken phone”.
The Three Horsemen of the GDD Apocalypse
There are three mistakes that can negate all the benefits of drawing up a disdock. They are quite obvious, but, as practice shows, even the most obvious things sometimes need to be said. So:
Ambiguity/incomprehensibility
Everything is simple here — all your theses, ideas and results of calculations should be stated unambiguously. Do not let people think for you, do not offer several options for completing the task to choose from, do not hope that colleagues can read your thoughts and do not confuse colleagues with complex literary phrases.
Illiteracy
Reading documentation becomes much more complicated if the text is full of problems with spelling, grammar and punctuation. Take care of it.
The information is not substantive
In the creative process, it is quite easy for a game designer to afford a lyrical digression when it comes to a favorite character, mechanics or object. Remember about the “skeleton” — those things that must be specified in the disdock (for example, if we are talking about 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 should always remember who you are writing GDD for. For example, artists most often do not need exact formulas for calculating certain indicators, but for programmers they are necessary. For UI designers, interface diagrams, number orders, a list of necessary elements and transitions are very important, while for almost all other departments this information will be superfluous.
Selection of tools
There are many tools for working with documentation. Of these, a group of wiki engines can be distinguished:
They differ in the languages used, functionality “out of the box” (support for styles, accounts with different rights, filling and type of file storage, etc.), extensibility. There is even a large website where you can compare different engines in detail.
In addition to wiki engines, the following systems are used:
- Google Docs (or analogues — for example, the iCloud office suite);
- Evernote;
- GitHub.
You can also use regular offline editors with a version control or sharing system connected. In this case, the document itself is written, for example, in Word, and then uploaded to the cloud so that others can work with it. But this entails a number of inconveniences — for example, the lack of a normal search through all documentation and full version control.
In Rocket Jump, we use a bundle of Confluence and JIRA. The first service is a tool for maintaining documentation, the second is a well-known task manager. Both complement each other very well — for example, you can integrate a task from JIRA into an article in Confluence, track its status. When using other systems, it may be difficult to integrate the task tracker with the documentation.
The main plus of the bundle is intertwined with the main minus. The fact is that this is a very difficult system to set up (there is even a separate type of specialists who implement Confluence into the pipelines of large organizations). But all this pays off with impressive thoughtfulness and flexibility — if desired, Confluence can be customized for almost any needs. So it all depends on the size of your team and project tasks.
Tips from practice
Here are some tips from experience, which, I hope, will simplify the work with game design documentation.
1). Keep the information up-to-date and complete. An outdated or unfinished diesel engine is almost as bad as its absence. In order to understand the project and develop it correctly, you need to constantly see a general, truthful, detailed picture.
2). For paperwork, it is best to create a separate small regulation, according to which everyone will understand how to issue a GDD. This includes approved fonts, subtleties regarding formatting, what italics mean in the document, what needs to be highlighted with “bold” and so on. In the future, this will speed up navigation on the disdock and simplify communication in the team.
3). It is worth developing a uniform GDD design style and its structure for your team. Below is a simplified documentation structure that we use in Rocket Jump:
4). Working with configs, write down in the disdock those mechanisms and structures that you will want to vary in the future during the configuration of mechanics. If you do not do this in advance, there is a high chance that then you will have to ask programmers to “pull out” from the code what could be immediately brought to the surface. Here is an example of one of the pages of our documentation, which contains a piece of code that we will need to deal with in the future:
5). When working with tables, it is recommended to remove grouped table elements under the cat, as well as highlight the caps (so that it is always clear what type of data is written in a column / row) and structure the data correctly. It’s like a code here — if another person is working with your data, make sure that he doesn’t get bogged down in the wilds there. Well, you should not use nested tables — these are unnecessary complications.
6). When prescribing formulas, be sure to provide explanations (legend) — what each variable is responsible for, and how it interacts with other elements of the formula. In the future, if you use the same variable at different points of the GDD (and this will happen), it will greatly simplify the work.
7). Observe the unity of naming. Agree “on the shore” and fix in the documentation how the units, items, and so on will be called in the team. This will have a beneficial effect on further work with locales and will not lead to misunderstandings and unnecessary searches. No one wants to find out on the eve of the patch build that the same unit is called differently by four employees:
That is why we at Rocket Jump maintain a full-fledged glossary on each project, which contains the approved names of all entities.
Result
I will summarize everything with a fairly simple thought. The most important thing in working with game design documentation is that it should be, and be relevant throughout the life of the project. GDD support saves much more resources than it takes away. And this process, in fact, does not require as much time as it may seem at first glance. Plus, it is a key tool in the work of a game design specialist, and the final result of his work largely depends on the quality of the GDD.
See also: