From game design to gameplay
So, after much work and thought, reading articles, maybe even my previous one , after analyzing the experience of competitors, talking with fellow game designers for a cup of coffee (or a glass of beer?), Prototypes and iterations - the design document for a small feature or the whole game is ready . Victory?! No matter how.
In this article, we will talk about the thorny path that the game design goes from the document to the implementation in the game, and from the standpoint of the game designer himself. As in the previous article, the task is not to show the entire process in detail. The text is aimed at those who are interested in the experience of a game designer in a large team.
Stage One: Acceptance
If the game designer is not a creative director or the head of the gaming direction, that is, in one way or another, the main thing is in a relatively independent development studio (otherwise publisher approval is often necessary), then his document will go through the approval stage. It works differently everywhere. In Allods Team, for example, after an oral discussion, an email is sent to the mail (with a theme designed according to the template) with a design. At Obsidian Entertainment, the creative director places approval on JIRA. There are verbal approvals and obligatory meetings for the “acceptance of designs” in which game designers, as well as producers and team leaders, participate.
In any case, there are three rules to remember.
- If a certain process of "approval" exists, then it is better to try to follow it.
- Need to prioritize. The approver often has dozens of “complex and controversial” designs under consideration, and it is not always possible to set aside time to review the entire scope. Therefore, you should remind about the design important for the project more often, but the design of a small feature for the next year can wait. But you should not completely forget about the latter, otherwise it may never be realized at all.
- Perceive criticism constructively, understand its prerequisites and resolve problems systematically, rather than just doing “as they say.” Often, beginning game designers, instead of understanding why this is wrong and how to do it better, work on the principle of “tell me how to do it, I will calculate everything”, or vice versa - they just argue out of love for the argument. Such behavior contributes little to professional and career growth. If there is any mistake in the design, you need to understand why it was made so as not to repeat it anymore. Only having accumulated sufficient experience, it is quite possible to discuss with the "host", unless, of course, there are significant arguments. In the end, everyone can be wrong.
This stage can take from zero (when approval is not needed) to several weeks, depending on the situation. It is curious that some companies set strict time frames for the response to the acceptance or rejection of design. If there is no response within, say, five business days, then the design is considered accepted and can go to work. Of course, this system leads to funny situations, but the number of designs in an incomprehensible status is sharply reduced.
Stage Two: Planning
At this stage, often a flight of fantasy is faced with the brutal reality of sprints, milestones, sick programmers, lack of resources and so on. A lot of articles and books have been written about the planning process from the position of manager, and, fortunately, usually a simple game designer does not need to thoroughly understand it, and when needed, experience will be enough. 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 off a couple of development months”, a game designer often hears such words from a “butcher” - a leader or producer in conditions of a lack of resources, the need for testing, and more. Here the rule is simple: you have to be prepared for them. Even before the planning phase, you need to understand (or better document) what components of a feature / game are critically needed, which should be cut off only when absolutely necessary, and which ones 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 average importance costs as much as a dozen less important ones, and in such a situation often ten parts outweigh one.
Similarly, you need to understand which parts are reallynecessary (since without them you should not start) 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 if it is absent, even if “otherwise we break 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 this does not cancel attempts to get a working and effective option. At the same time, such a “cutting off” (fichekat) is more often a necessary and useful process than harmful.
There is another argument: “Too expensive, let's get cheaper.” Of course, for game designs, cost reduction does not always mean loss of quality (and in this case, everything is fine - due to another iteration, we managed to get the same result more efficiently), but often it’s just another option of “cutting off”, when instead of deleting the whole part the volume of saved ones is reduced. 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 the players are given some basic part of the feature, after some time - its advanced functionality, etc. This approach is very rational, since in addition to the general convenience of planning and earlier terms of getting the game to the players, there is more time for “live” testing and the opportunity to change the development course in time. But it is easy to make mistakes.
Unlike the game designer and producer, the player will not think about the fact that the walls of the castle cannot be built yet, because programmers promise the functionality in the engine in two months. Instead, he writes on the forum: “Why did you introduce these locks? He just built it, but the walls cannot be built ... Some schoolchildren came and demolished everything. Return the money!". Proper division into parts gives players interesting gameplay at each stage and makes you look forward to the next. What is done wrong - it causes only annoyance with imperfections and disappointment at each subsequent stage, with comments like "they have not 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 for large features situations arise when "there are free resources for artists, and there is nothing more to occupy" or similar "resources". The reasons may not be directly related to the development price, for example, “this is a cool feature, you need to tell marketers about it, you need to add it here to look better!” Or “on this mechanics we will still collect the undead from the necromancer!”
This can be turned in favor, or it can be harmful. The main thing is to maintain the integrity of the feature, complementing it with useful ones, and not inflating it with a featurekap, requiring great effort in the absence of benefit to the project. Remember: the feature is close!
Violation of the relationship and causality
In an ideal world, a feature will be planned so that no team blocks another, and testing could be started as early as possible. Reality is dark and full of horrors. Although this is the prerogative of managers of various kinds, the game designer also needs to participate, at least in order to check the sequence of the return of the features of the feature. Because often only he fully understands all internal connections and can raise the alarm: “until there is functional for the foundation, the walls will not be built!”.
After overcoming the above and other problems at the planning stage, finally, development can begin. Here comes the first "Frankenstein threshold": you need to take a sober look at a feature that has undergone "cheaper", "cut off" and "adding more functionality from the side", and understand what happened in the end. And, if necessary, try to fix something. And then, when everything is ready, do not forget to update the documentation based on the results of all changes accepted during the planning.
Stage Three: Implementation
For a game designer, the implementation of a game design consists of two parts - the work of programmers, artists, and other colleagues, and the work, in fact, of the game designer himself. The second point may seem unexpected from the side, however, in many Russian companies and in the western ones (for example, in Obsidian Entertainment, Raven Software, The Workshop Entertainment, the author personally observed this phenomenon), game designers themselves contribute all the data to the game: spell damage , booking tanks, the number of victories for achievements and more. In addition to data, scripts of the type “doused with oil - set fire to additional damage” are also collected on internal tools. Sometimes it happens that there is a separate game designer who brings data to the game, but this is more an exception than a rule. Even in Western companies, where the specialization of game designers in areas is very strong, who usually invented an idea himself enters data for it (of course, with the help of programmers, where necessary). This is also common in small teams, but, surprisingly, less, you can often find cases of "exclusively inventing" game designers.
In a large company, usually all game designers with a rank lower than the creative director (and sometimes he!) Will have to master the tools, deal with the commits to the repository, error tracking systems and other technical part. Briefly describing all this is rather difficult, so those interested should read more on their own, or take the course "Fundamentals of Technical Project Development", which is part of the comprehensive program " Management of gaming Internet projects ."
As for the work of colleagues - programmers, artists and other specialists, it is worth remembering two basic rules:
- Check the task for compliance with your design, reading it as if from the outside, and imagining that you know nothing about the game as a whole or about its design. Often, technical experts (including good ones) may not be aware of the existence of any features in the game, accepted practices, etc. And if the task is not formulated with this in mind, the result is very different from the intended one.
- The performers' questions “what exactly to do” are good, and answering them is quick and accurate. There is, of course, the opposite situation, when too many clarifying questions are asked. In this case, it is worth understanding where exactly the problem is - in the written design, in conveying the vision of the game and specific features to the performers, or in a specific employee? Only by understanding this can you consciously solve the problem. What is definitely not worth doing is to ignore such issues or advise you to figure it out yourself.
As you implement, you need to both test 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 there is a practice in companies where game designers, at least not the youngest ones, also become a kind of “feature owners” invented by them, and the supervision of their development is encouraged. For example, a game designer can go to any task performer for his design, request status, find out the current priorities and even freely change them inside tasks according to his own feature (for example, “first make support in the code for the new boss ability so that we 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 the Results
As a result, one day the day comes when the feature is made, tested, and ready to be given to the players. At this stage, however, there are several tasks for the game designer: to check the process of its presentation to the audience (in Patchnotes, in the articles “under development”, in the preview of the game, etc.) and then monitor how it works according to the statistics collected . Some features are done once before the start of the game and then practically do not change. But many, including concepts like “balance of game classes”, “in-game economy”, “social activities”, can change many times over the entire life of the project. For them, you need to be able to work with statistics and player reviews in order to make the right decisions.
What a game designer should be able to
The reader may see a kind of contradiction: if the game designer must simultaneously be able to technically work with the toolkit, understand priorities as a producer, find potential problems as QA, perceive the moods of players 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 the game designer (after the ability to invent a game) - not to try to be all participants in the development at the same time, but to correctly understand the situation, manage it, to the best of his ability, and correct problems.
A very difficult mechanics for players to understand, which cannot be simplified? It is worth helping the community manager write an article about her.
Is Fitch hard to test? It is worth helping the QA department.
Is there a lot of components with complex relationships in terms of both the development sequence and the ability to run a feature without them? It is worth following the priorities of these components among the performers.
Even complex features at a particular point in time rarely have more than two problem areas, and if you don’t disperse your strength where everything develops by itself, then bringing the feature to readiness is not so difficult.
We must also be able to cope with the psychological temptation of "let them do as they want, I thought up everything cool, and if something goes wrong, they are to blame." Yes, maybe it’s psychologically convenient not to interfere in the implementation of the design, and then say: “everything was done not as in my design, the deadlines failed - it is not surprising that 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 at a glance, the deadlines do not break (or move freely), QA finds all the balance problems themselves, and there are no errors in the patch notes - you can just do it! However, the word “dream” is key here, and in almost any large company, both Russian and Western, one will have to face harsh reality. But even once in the “dream team”, the development skills described above will come in handy sooner or later. After all, as Lao Tzu wrote: "Under the sky, everything only temporarily happens."
In conclusion, I want to add a simple observation: although at first practicalthe work of a game designer seems complicated, but if everything is done correctly (which is at the initial level and the previous and this article describe), all difficulties are overcome. The main thing is not to be afraid of them.
