So, after much work and reflection, reading articles, maybe even my previous one , after analyzing the competitors experience, communicating with fellow game designers over a cup of coffee (or a beer?), Prototypes and iterations - a small feature design document or an entire game is ready . Victory?! As if not so.

This article will discuss the thorny path that game design runs from document to implementation in a game, and this is precisely from the perspective of the game design itself. As in the previous article, there is no task to show the whole process in detail. The text is aimed at those who are interested in the experience of game designer in a large team.

Stage One: Acceptance

If the game designer is not a creative director or head of the game, that is, one way or another, the main thing in a relatively independent developer studio (otherwise publisher’s approval is often needed), then his document has to go through an approval stage. It works everywhere in different ways. In the Allods Team, for example, after an oral discussion, a letter is sent to the mail (with a theme arranged according to a template) with a design. At Obsidian Entertainment, creative director puts approval on JIRA. There are also oral approvals, and mandatory meetings for the "acceptance of designs", in which game designers, as well as producers and team leaders participate.
')
In any case, it is worth remembering the three rules.

1. If a process of “approval” exists, then it is better to try to follow it.
2. It is necessary to prioritize. Often, a dozen of “complex and controversial” designs are under consideration by the approver, and it is not always possible to take time to consider the entire volume. Therefore, about the design, important for the project, it is worth reminding more often, but the design of a small feature for the next year can wait. But you should not forget about the latter at all, otherwise it may never be realized at all.
3. To perceive criticism constructively, understand its background and eliminate problems systematically, rather than simply doing “as said.” Often, beginner game designers, instead of understanding why this is wrong and how to do better, work according to the principle “tell me how to do it, I will count everything”, or vice versa - they argue simply for the love of the argument. Such behavior contributes little to professional and career growth. If there is some kind of mistake in the design, it is necessary to understand why it is made in order not to repeat any more. Only having accumulated sufficient experience, it is possible to discuss with the "host", if, of course, there are weighty arguments. In the end, everyone can make mistakes.

The period of passage of this stage can take from zero (when approval is not needed) to several weeks, depending on the situation. It is curious that in some companies a tight time frame is set for the response on acceptance or refusal of design. If there is no response within, say, five working days, then the design is considered accepted and can go to work. Of course, this system leads to curious situations, but the number of designs in an incomprehensible status decreases sharply.

Stage Two: Planning

At this stage, often a flight of fancy is confronted with the cruel reality of sprints, Milestone, ill programmers, lack of resources, and so on. A lot of articles and books have been written about the planning process from the perspective of a manager, and, fortunately, usually a simple game designer doesn’t need to understand it thoroughly, and when needed it will be enough experience. Nevertheless, even at a simple level one should be able to avoid some extremes, or at least raise an alarm when they are detected.

“Let's cut a couple of people-months of development” - often a game designer hears such words from a “butcher” - a manager or a producer in conditions of lack of resources, the need for testing and other things. Here the rule is simple: you have to be ready for them. Even before the planning phase, you need to understand (and it is better to document) which components of a feature / game are critically necessary, which should be cut off only if absolutely necessary, and which can be sacrificed altogether. Often, to understand this you need at least a minimal idea of ​​the cost of developing one or another part, because it also happens that a part of medium importance costs as much as ten less important ones, and in such a situation often ten parts outweigh one.

Similarly, it is necessary to understand which parts are really necessary (since it is not worth running without them) and be able to maintain this understanding in difficult conditions. From the standpoint of formal logic, if a feature is objectively not functional without part A, then it will not start working in its absence, even if “otherwise we fail the deadlines” or “there are more important tasks on this team”. In practice, of course, it is not always possible to fully defend a feature in the presence of many “butchers” (especially external ones regarding the development team), but it does not cancel attempts to get a working and effective option. At the same time, such a “cutting off” (face-to-face) is more often a necessary and useful process than a harmful one.



There is another argument: "Too expensive, let's cheaper." Of course, for game designs, cheapening does not always mean a loss of quality (and in this case everything is good - at the expense of one more iteration we managed to get the same result more efficiently), but often this is just another cut-off option, when instead of deleting the whole part, the amount of saved ones decreases. But the rules here are essentially the same.

“Let's break the feature into 10 phases”

An alternative to “cutting off” is often “separation”, when at first some basic part of the feature is given to players, after some time its advanced functionality, etc. This approach is very rational, since in addition to the general convenience of planning and the earlier timing of hitting the game, the players will have more time for "live" testing and the opportunity to change the course of development in time. But it is easy to make mistakes in it.

Unlike the game designer and producer, the player will not think that the castle walls can not be built yet, because programmers promise functionality in the engine in two months. Instead, he will write on the forum: “Why did they introduce these locks? Just built, and the walls can not be built ... Some schoolchildren came and all demolished. Return the money!". Proper division into parts gives players an interesting gameplay at each stage and makes them look forward to the next. What was done incorrectly causes only irritation with the finishing touches and disappointment in each subsequent stage, with comments like “they haven’t been able to do it for a year now.”

Feature Creep ( https://en.wikipedia.org/wiki/Feature_creep ) - yes, it exists at this stage!

Surprisingly, sometimes there are situations for large features when “there are free resources for artists, and there is nothing more to borrow” or similar “resource”. The reasons may not be directly related to the price of development, for example, “this is a cool feature, marketers need to tell about it, I need to add here to make it look better!” Or “we will use the necromancer to undead for this mechanics!”.

This can be turned into a benefit, and it can be to the detriment. The main thing is to preserve the integrity of the feature, complementing it with a useful one, rather than inflating a feature that requires a lot of effort without the benefit of the project. Remember: the feature is close!

Violation of relationships and causality

In an ideal world, the feature will be planned out in such a way that no team will block the other, and you can start testing as soon as possible. The reality is dark and full of horror. Although this is the prerogative of managers of various kinds, the game designer also needs to participate, at least, to check the sequence of feedback of the feature components. Because often it is only he who fully understands all internal communications and can raise the alarm: “until there is no functionality for the foundation, the walls will not be built!”.

After overcoming the above and other problems at the planning stage, development can finally begin. Here comes the first “Frankenstein threshold”: you need to take a sober look at the feature that has been subjected to “cheapening”, “cutting off” and “adding more functionality to the side”, and to understand what happened. And, if necessary, try to fix something. And then, when everything is ready, do not forget to update the documentation on the basis of all the changes adopted during the planning process.

Stage Three: Implementation

For a game designer, the implementation of game design consists of two parts - the work of programmers, artists, and other colleagues, and the work, in fact, of the game design itself. The second point may seem unexpected, however, and in many Russian and western companies (for example, the author personally observed this phenomenon in Obsidian Entertainment, Raven Software, The Workshop Entertainment), game designers themselves bring all the data into the game: spell damage , booking tanks, the number of victories for achievements and so on. In addition to the data, scripts of the form “doused with oil - set fire for additional damage” are collected on the internal toolkit. Sometimes it happens that there is a separate game designer who contributes data to the game, but this is the exception rather than the rule. Even in Western companies, where specialization of game designers in areas is very strong, usually the idea that came up with the idea itself enters the data for it (of course, with the help of programmers, where necessary). In small teams, this is also common, but, surprisingly, less, it is often possible to find cases of "exclusively inventing" game designers.

In a large company, usually all game designers with the rank below the creative director (and sometimes him!) Will have to master the tools, deal with commits in the repository, in error tracking systems and with other technical parts. It is rather difficult to describe all this briefly, therefore, those interested should read more on their own, or take a course on the Basics of Technical Project Development, which is part of the comprehensive program Gaming Internet Projects .

With regard to the work of colleagues - programmers, artists and other professionals, it is worth remembering two basic rules:

1. Check the task for compliance with your design, reading it as if from the side, and imagining that you do not know anything about the game as a whole or about its design. Often, technical specialists (including good ones) may not even suspect that there are any features in the game, accepted practices, etc. And if the task is not formulated with this in mind, the result is extremely different from the intended one.
2. Questions of the performers “what exactly to do” are good, and it is worth answering them quickly and accurately. There is, of course, the opposite situation, when there are too many clarifying questions. In this case, it is necessary to understand exactly where the problem is - in the written design, in communicating the vision of the game and specific features to the performers, or in a specific employee? Only by understanding this, you can consciously solve the problem. What exactly you should not do is to ignore such questions or advise yourself to sort things out.

As you implement, you need to test yourself what you get, and help QA in this matter, pointing out weaknesses that need additional verification, and answering questions. Early testing makes it easy to identify potential problems and fix them.

Often in companies there is a practice when game designers, at least not the youngest, also become a kind of “owners of the features” invented by them, and are encouraged to monitor their development. For example, a game designer can approach any executor on tasks for his design, request status, find out current priorities and even freely change them within tasks according to their features (for example, “make first support in the code for the new abilty of the boss so that we can test it , and then fix the bug with loot from it "). Thus, the game designer becomes a little producer for his feature.

Stage Four: Analysis of Results

As a result, one day the day comes when the feature is made, tested, and ready for delivery to the players. At this stage, however, there are several other tasks for the game designer: check the process of its presentation to the audience (in Patchnotes, in the articles “in development”, in the preview of the game, etc.) and then follow how it works according to the collected statistics . Some features are made once before the game starts and then practically do not change. But many, including the concepts of the type “balance of game classes,” “in-game economy,” and “social activities,” can change many times over the entire life of a project. For them, you need to be able to work with statistics and with player reviews in order to make the right decisions.

What a game designer should be able to do

The reader can see a kind of contradiction: if a game designer must simultaneously be able to technically work with tools, understand priorities as a producer, find potential problems like QA, perceive players' moods and understand statistics - how can all this be combined? And at the same time, in fact, write designs?



Here lies the second most important skill of a game designer (after the ability to invent a game) - not to try to be all the development participants at the same time, but to understand the situation correctly, manage it, to the best of your ability, and correct problems.

Very difficult to understand for the players mechanics, which can not be simplified? It is worth helping the community manager to write an article about her.

Fitch difficult to test? It is worth helping the QA-department.

There are many components in the feature with complex interconnections, in terms of both the development sequence and the ability to run the feature without them? It is worthwhile to follow the priorities of these components from the performers.
Even with complex features at a particular point in time, there are rarely more than two problematic areas, and if you don’t disperse forces where everything is going on by itself, then bringing the feature to readiness is not so difficult.

It is also necessary to be able to cope with the psychological temptation to "let them do as they like, I thought up everything cool, and if something goes wrong, they are to blame." Yes, maybe it is psychologically convenient not to interfere with the implementation of the design, and then say: “everything is done not in my design, the deadlines are not surprising, everything is bad”, but ... This usually does not work in the long term.

Of course, it is argued that in small dream-team-teams it happens that the performers understand everything perfectly, terms do not break (or move away freely), QA find all the problems of balance themselves, and there are no mistakes in patchouts - you can just create! However, the word “dream” is key here, and in almost any large company, both Russian and western, you will have to face a harsh reality. But even getting into the "dream team", the above development skills will come in handy sooner or later. After all, as Lao Tzu wrote: “Under the sky, everything is only temporary.”

In conclusion, I would like to add a simple observation: although at the beginning practical work as a game designer seems difficult, but if everything is done correctly (which is described at the initial level by the previous and this article), all difficulties can be overcome. The main thing is not to be afraid of them.