Documentation is the basis of the game.

In this article I want to talk about how my friend and I prepared the documentation for our first game. And also about how much she had and how she helped save money and time in the development process. In the article, I will pay a little less attention to the initial chapters of the document design, and I will talk more about our experience in writing documentation related to the content of the game.

We had a desire to make a game for a long time, and many attempts were made. We took various ideas, got together with spirit and sat down to implement them. And each time the development lasted no more than a month. And all because we made the same big mistake.

Having in our hands a couple of sentences with a description of what the game is like, we started to do something violently. Each of us sat down to create our own working prototype, someone to write our own engine. We were looking for artists and composers willing to work on enthusiasm. Each of them had his own idea of ​​the project and each tried to convince the other of the correctness of his vision.

Everything went unorganized, no one had an idea of ​​what other project participants were doing. And, of course, such an approach did not lead to anything good. The enthusiasm quickly faded away, the desire to do it is not clear what the hell was completely lost. None of these projects have been implemented.

However, a year ago, we gained valuable experience in creating our escape room. In order not to lose investments, I had to plan everything, organize, set deadlines and bring the project to implementation. Only a detailed description of each riddle and careful thought over of the details allowed to complete the project.

And now, using the experience gained, this winter we began to make our own game. From the very beginning, we decided to approach the development process thoroughly and first prepare the documentation.

Design paper

As already written more than once, the design document is the basis of the future game. Using the well-known “Ryaba” disco , we have compiled several main sections.

The first contains a description of the concept of the game. This is necessary in order to determine the main points that should be followed throughout the development. After reading the first chapter, any other person should immediately understand what the game is.

Determining the genre and platform for which the game will be created helps to choose a game engine. A brief but comprehensive description of the game is very useful for marketing, as it allows you to quickly familiarize any person with the game. It came in handy many times: when designing a group, pitch documents, etc ... A full description of the game contains the gameplay: from launching a level to its completion. It is useful in order to further describe all the game elements and not to miss anything.

In our case, 3d arcade battles with a top view became the genre. A brief description looks like this: arcade network battles on boats. It was decided to make the game on a PC with the ability to build a version for Mac and Linux. As the game engine, we chose Unreal Engine 4.

We devoted the next section to game elements. For each, they determined the functionality, characteristics, behavior and features. Some things seemed obvious, but only a full description allowed us to have an accurate idea of ​​what is needed to implement a particular game object.

Game object harpoon
Общее описание:

“На носу лодки находится пушка из которой торчит гарпун. К гарпуну прицеплена веревка, которая соединяет его с лодкой.”

Используемые параметры:

  • Максимальное расстояние;
  • Сила притягивания;
  • Время перезарядки;
  • Время действия крюка;
  • Количество использований.

Поведение гарпуна:

  • Поворачивается вокруг своей оси в направлении прицела;.
  • При выстреле — по направлению прицела вылетает гурпун, тянет за собой веревку;.
  • Если длина троса больше или равна максимальному расстоянию, он рвется, количество использований уменьшается на 1 и происходит перезарядка;.
  • Если снаряд натыкается на скалы или берега — притягивает лодку к ним;.
  • Если снаряд натыкается на объект окружения (бревна, другие лодки) — притягивает их к лодке, а лодку к ним;.
  • По истечению времени действия трос гарпуна рвется. После этого количество использований уменьшается на 1 и происходит перезарядка;.
  • Когда количество использования крюка становится равным 0, текущий бонус у лодки заменяется на отсутствующий..

After describing the elements, we dedicated the chapter to the menu and game interface (HUD). We compiled block diagrams with which we showed which interface elements will be in each menu, what information they will display and what actions will occur when interacting with each of these elements.

The final chapter was filled with marketing information and competitor analysis. This allows you to understand at an early stage what steps and when should be taken to promote the game. For example, the developer's diary and the project group can be created and filled almost immediately after the start of development.

Description for the artist, modeler and animator

Since my friend and I are programmers, to work on the content of the game, we needed the help of people who can draw and animate. We decided to avoid past mistakes and not offer to work on enthusiasm. And in order not to constantly overpay for corrections and changes, it was decided to make as detailed a description of what we want to see in the game.

First, we formed a detailed view of how the game should look.

Each game object (which needed concept art), we devoted a separate paragraph in the document. They described their ideas about the object, attached photographs or images that helped better convey our thoughts.

Of particular note is the description of the character. We had no idea how he should look, whether it will be a person, an animal or some creature. But to require the designer to try to guess what we like would be quite time-consuming and financially expensive. To get the desired result, we decided not to describe the appearance, but the character and behavior of the protagonist, which allowed the artist on the first attempt to offer us a version of the character that came up with the game. By character, the hero must be agile, quick, fun, cunning and mischievous. As a result, from a number of proposed options, the main character was a lemur, who, with a boat in his hands, runs to the battlefield.

Character Options Outline

Final character concept

Example weapon and character concepts in a boat

Having completed work with the artist, we proceeded to the creation of documentation for the 3d modeler and animator. All game objects were re-described, but this time they came with ready-made concepts, information about where, how and when this object is used in the game. For each model, its technical parameters were indicated: the limit of polygons, a list of textures and their resolution.

Boat engine model
Краткая информация:

Двигатель крепится к задней части лодки. Персонаж будет держать его за конец ручки и поворачивать, тем самым задавая направление движения лодки (поворот будет делаться в движке, а не анимацией). Двигатель будет с винтом, но винт вращаться не будет.

Количество полигонов: 1000-1500;
Текстуры: Diffuse. Разрешение: 512x512;
Анимации: Не требуются.

For some models, a list of animations was required. Each description of the animation contained the duration, type (single or looped) and our most detailed representation of it. For example, the paddle strike is described as follows :.

Paddle kick
Персонаж левой рукой отпускает двигатель, берет правой рукой весло, которое лежит в лодке справа от него. Берет за самый край, чтобы произвести удар как можно дальше, привстает, замахивается веслом за спину. Перед началом атаки (после замаха) забавно подрыгивает для большей силы удара и бьет наотмашь вниз-вперед. Конец анимации — правой рукой кладет весло обратно в лодку, левой рукой берется за двигатель. Анимация одиночная. Длительность 0.5 — 1 сек.

As a result, it turned out that three different people worked simultaneously on models and animations (two modelers and an animator). And only a detailed description of each game object made it easy to coordinate their activities, to avoid inconsistencies in animations or object sizes. It also made it possible to get all the models practically the first time without corrections and comments.

Description for composer and sound player

The documentation for the music and sounds of the game has much in common with the description of animations. Each game object has its own table. They recorded the name of the sound, type (single or looped), the duration and description of where and when this sound will be played. For the convenience of the musician and to make sounds better combined with animations, short videos were recorded with game situations in which this sound should be played.

Sounds for a game object paddle

When it came time to write music for the game rounds, we described our idea of ​​what it should be, the pace of the music, the mood, led several genres that seemed suitable to us. After which we had several games with the composer. We also prepared a special version of the game where you can play alone (since the game is designed for multiplayer and the default requires at least 2 players). This helped the musician better understand the style of the game and offer his ideas for musical accompaniment. As a result, we got fun and dynamic Hawaiian-style music and a combination of various musical instruments, depending on the situation on the battlefield.


The preparation of documentation and materials can be time consuming and nerves. I would like to sit down for implementation as soon as possible, and not mess with the bureaucracy. However, this allows you to greatly increase the development efficiency and not abandon the game in the first month.

Clearly defined tasks, a constant idea of ​​what stage the game is now, what is done, and what remains to be done, makes it possible to always be sure that the project is moving towards release.

In addition, it doesn’t matter if you are looking for people in a team for an idea or for payment, a well-written technical task will allow them to become interested in the project and correctly assess the complexity of the tasks and the time to implement them.

A detailed description of all game elements allows people creating content to make it efficiently and quickly. There is no need to spend time explaining each task, or making constant changes, which significantly saves money and nerves. In addition, the documentation will be useful in the future when promoting the game and compiling advertising texts. It is always pleasant to discover that much has already been done; all that remains is to take and use it.

Also popular now: