Documentation - the basis of the game

In this article I want to talk about how my friend and I prepared documentation for my first game. And also about how important it was and how it helped save money and time in the development process. In the article I will pay a little less attention to the design chapters of the document, and I’ll tell you 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, gathered our 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 major mistake.

Having on hand a couple of sentences with a description of what the game is, we rapidly began to do something. Each of us sat down to create our own working prototype, someone to write our own engine. We were looking for artists and composers who are ready to work on enthusiasm. Each of them had their own idea of ​​the project and each tried to convince the other of the correctness of his vision.
')
Everything went unorganized, no one had any idea about what other project participants are doing. And, of course, such an approach did not lead to anything good. Enthusiasm quickly faded away, the desire to do is not clear what kind of just disappeared completely. None of these projects has been implemented.

However, a year ago, we gained valuable experience by 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 puzzle and careful consideration of the details allowed to complete the project.

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

Design paper

As already mentioned more than once, the design of the document is the basis of the future game. Using the well-known dizdok "Ryaba" , 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 provisions 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 succinct description of the game is very useful for marketing, as it allows you to quickly familiarize anyone with the game. It came in handy many times: when setting up a group, pitch documents, etc. ... The full description of the game contains the gameplay: from the launch level to its completion. It is useful to further describe all the game elements and not to miss anything.

In our case, the genre has become a 3d arcade battle with a view from above. The brief description looks like this: arcade network battles on boats. The game was decided to do on the PC with the ability to build a version for Mac and Linux. We chose the Unreal Engine 4 as the game engine.

The next section is devoted to game elements. For each defined functional, characteristics, behavior and features. Some things seemed obvious, but only a complete description allowed us to have an accurate idea of ​​what was needed to implement a particular game object.


After describing the elements, we dedicated the chapter to the interface in the menu and the game (HUD). They made flowcharts with the help of which they showed which interface elements will be in each menu, what information they will display and what actions will take place when interacting with each element.

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

Description for the artist, modeler and animator

Since my friend and I are programmers, we needed the help of people who can draw and animate to work on the game content. We decided to avoid past mistakes and not to 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 as possible 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 required concept art), we have dedicated a separate paragraph in the document. They described their ideas about the object, attached photos or images that helped to better convey our thoughts.

Of particular note is the description of the character. We had no idea how it should look, a human being, an animal or some creature. But to demand from the designer to try to guess what we like, it would be quite time consuming and financial. To get the desired result, we decided to describe not the appearance, but the character and behavior of the main character, which allowed the artist to offer us a version of the character who approached the game from the first attempt. By the nature of the hero must be agile, nimble, cheerful, cunning and mischievous. As a result, from a number of the proposed options, the main character was a lemur who, with a boat in his hands, is running on the battlefield.




Having completed the 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 were accompanied by ready-made concepts, information about where, how and when this object is used in the game. For each model, its technical parameters were indicated: polygon limit, list of textures and their resolution.


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


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

Description for composer and sound artist

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


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, brought several genres that seemed appropriate to us. After that we had a few games with the composer. And also, they prepared a special version of the game where you can play alone (since the game is designed for multiplayer and by default requires at least 2 players). This helped the musician to better understand the style of the game and to offer their ideas on music. As a result, we got a fun and dynamic Hawaiian-style music and a combination of different musical instruments, depending on the situation on the battlefield.

Conclusion

Preparation of documentation and materials can take a lot of time and nerves. I would like to quickly sit down for the implementation, and not to bother with the bureaucracy. However, this allows much more development efficiency and does not give up the game in the first month.

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

In addition, it does not matter if you are looking for people in a team for an idea or for payment, competently drawn up terms of reference will allow them to become interested in the project and correctly assess the complexity of the tasks and time for their implementation.

A detailed description of all game elements allows people creating content to make it high-quality and fast. No need to spend time explaining each task, or making permanent changes, which significantly saves money and nerves. In addition, the documentation will be useful in the future when promoting the game and writing advertising texts. It is always nice to find out that a lot has already been done, it remains only to take and use it.