This material is inspired by discussions on various topic-related resources - how should one lead production managers with one’s own community? Based on a long comprehension of all the above, this article was born, i.e. quite spontaneously. As always a small remark. The article does not pretend to any manual on the "how to do right." Also, the material in no way affects the importance, relevance and usefulness of PR-managers, community managers, etc. And even less trying to teach them something. Employees on a regular basis dealing with information background and the community will be needed always and everywhere. Without them, I think, the ecosystem of development is incomplete and very sad when people try to plug this hole with non-professional staff, and “get out with that free junior programmer.” But more on that later

Introduction….

... Or a little about "why he tells us something at all."
The point is very important, because often we have a sad situation when a speaker or just a speaker shakes his shoe in a dreadful way, tells how to live correctly, work and in general ... and everything would be fine until you start to check - and on the basis of what experience it all sounds. Very often - without any basis. Clever thoughts without practical experience, of course, are found in the open spaces, but they are usually flavored with too large a portion of idealism.

During my work in the gaming industry, which I love in every way, I had to play different roles. I wrote reviews of one quality or another (the readers are our main judges, it seems to me, but it was at least tolerable), I was involved in a community of well-known and not-so-many projects (I want to believe that it was my work that I did from unknown people - well-known, but this didn’t quite true) and with time began to move in the direction of developing a standard, very simple way - assistant DG, DG, co-producing, producing, etc. Not because it's better, it's just different and it is closer to me in terms of mind and character. We will not go to the listings - anyone will be interested in finding a profile both here and on other resources and will decide for himself whether to listen to my words or not)
')
One way or another, this transition in different areas of gamedev gave an interesting idea of ​​how the project itself and the project (!) Are served by fellow managers before the players, which methods are correct, effective and useful, and that only harms the reputation ... Let's try to figure it out, or rather even discuss a number of observations and approaches to this case.

---

Approach 1. Harsh reality

There is an old practice - not to show anything to the players until the “X” hour. Community managers rush through the offices, trying to select any art, God forbid, screenshots and come up with everything they can, in order to show the audience something tangible. Such an approach, when the “evil producer of the publisher” without 3 seals and 7 signatures does not allow spreading at least some information about the project, is slowly becoming obsolete, but it is still inherent in some commands in the old memory.

The issue of positioning the project in front of audiences arose before us once again quite recently - in the very early stages of the development of Metal War Online (this is 4 months with a team of an average of 5-6 people). Then we launched the first version of the site and a small, if I’m not mistaken, not even a skinned forum, and also sent out press releases to known / friendly resources. Some users have gone and left, some (a lot) are gone. In the dry residue, a certain backbone has been formed, which will most likely remain loyal to the project for a very long time, if you show due respect for its enthusiasm. At first we entertained a small but active audience with a bunch of renders, fake screenshots, illustrations, etc. with the promise "that's how the development process goes." It lasted until we began to receive quite a lot (relative to the general audience) wishes to see what actually happens there, because any sane person realizes that even the production of games cannot consist entirely of creative tasks and beautiful picchas.

For some time we got crushed, but then we came to the conclusion - it’s better to show the players how it is, i.e. immerse them in the harsh reality of the very early stages of development and no matter how risky it is to get feedback immediately. The very next day, we accepted the players at the current time version (between the prototype and the early alpha). The functionality was truly modest. For example, you could choose only one of the 3 ready-made machines. There was no pumping yet, so in the bar of the cars there were, for example, three identical “Asuka” with different towers, so that users could compare with which weapon it was more convenient for them to fight.

It is clear that the interface was not even basting - but simply a mock-up, sketched out of the bluish dies left after our test project on Unity3D - “Carrier”.


Fig.1. Progress interfaces.

Effects, scene tuning, levldizayn were also only on RC builds, so you had to ride among the semi-built city level, which even by early ideas was balanced by 32 players, later rebalanced by 24, and now it is completely reconstructed because of the shift fighting dynamics ...


Fig.2. While the players rode across the expanses depicted in Figure 2, the builds of individual employees were working on such settings.

We let in this version of the game about 60 people. With a stretch this solution can be called the formation of test groups, but in truth, at that time, the work and problems were so obvious that there was no particular need for testing with a large number of unprepared players. It took a lot of time and vapidly to “pounce” many aspects and systems, so that 100 bug reports about a bad button would most likely have simply distracted us ... And if there were doubts about the importance of mass tests at that stage, then in the formation of testers' culture these first players turned out to be a big part, painstakingly arranging topics in the correct way, grouping similar bugs with tags, etc. From that first backbone that got into the game, almost by chance almost everyone is alive and extremely active at the moment. Then we added another bunch of people almost every month, until after 3 months the more official classic Closed Alpha Tests, Open Alpha Test, PTA, and finally, more recently, MBT, did not start. The essence of this text is not in trying to impress someone with numbers, to impress, of course, there is nothing, because it is too early to judge the product as a whole ... the importance of thought in another - almost everyone who was ready to wait for the project, but did not understand what he was waiting for - could go in and see everything - both promising and extremely unattractive . Eliminating this for all the time of such sets in private is minimal, and the loyalty of the players is extremely high. Separately convenient feature - the players see all the progress of the project and give their assessment of what is happening, starting from “you didn’t show the new scene settings so much and the result wasn’t worth it” or “why you haven’t switched to such a UI style before, now I realized that I did not like in the past. "

It can be argued that such feedbacks are not important, we can insist that they should be carried out by unknown focus groups or colleagues. But in fact, the best feedback you get from people who are interested in the product, and not pay for it or beer for the service. As soon as the developers themselves are usually focused on the eyes, and colleagues in the workshop do not always make a constructive (checked by the same example) - remain, oh, horror, your players.

Why show something deliberately doomed to criticism? Well, for example, in order to unexpectedly receive not devastating comments at all, but quite an intelligible constructive from Central Asia, in order to immediately establish contact with it and its future replenishment. Well, if neither the first nor the second comes out at all - maybe it's time to think about the expediency of all further development and change something in time?

---

Approach 2. Facing the audience

Once upon a time I worked on one protracted domestic industry, at that time in the role of a PR-manager. I found the whole “moving” after many years after it began, and in terms of working with the audience - in a very poor condition. There were several problems:

• there was no qualified or simply diligent community manager who was accountable to the studio management. There was a fan who seemed to be actively answering certain questions of some users of certain resources;
• studio managers themselves in every way refused to communicate with users. Both from the simple (apparently due to laziness and a little bit of pathos), and to a very branded one, such as interviews and other stories about past “saques-story”;
• to questions about how the work with the audience is going - they nodded at the publisher, who knows better, and if nothing is done, then simply do nothing. The options that the publisher is busy with dozens of projects and physically do not have time to keep track of everything, somehow they were not even considered;
• the general policy of communication in every way arranged under the "only an apology, only the conviction of someone on the Internet wrong" ....

The result at the time of the start of the state of the community was very sad. There were many fans, and many, but they were full of interviews of many years ago and wrote to the official mail, which we all know how most people read. The time of my colleagues at that time really did not have enough to cover all the resources, topics, etc. related to the project. All would be nothing, but to heighten the scope, ordinary employees are strictly strictly forbidden to show any activity on any resources, to try to communicate with the audience even unofficially, and even more so to show something. It is probably impossible to imagine a larger information vacuum bordering on frank sabotage ....

From this situation, its aftermath and the long, hard search for solutions, several conclusions could be drawn. Which, it seems to me, is easier to follow and simply not to bring the situation to a critical one.

Conclusion 1. Give personal (!) Time to your customers.

It does not matter if you are responsible for the community or not. If you are working on a project with a small team (albeit within a large company), then take personal time to your clients, from whom you are waiting for money - get at least one closed topic on the forum on your behalf, in which you report the latest news from the front every couple of weeks (pic.3). This will show, if not a bridge between developers and players, then openness to dialogue ... why openness is so limited, each one thinks about himself or asks the community manager. An experienced CM will competently justify the rare occurrences of “those who have the power” and will benefit both those who have it and the project as a whole.


Fig. 3. Exposure from the forum with a fairly simple, requiring about 10 minutes per week, the topic “Brief notes of developers”

Conclusion 2. Reduce the number of excuses

... especially in the style of "yes, what can you tell now, write code, draw pictures". There is always something to talk about, unless you are sitting at a gambling table in Vegas, trying to increase the development budget recently given out by the investor ... and even that can be wrapped in a great topic for a forum about the leisure of developers who have left for a week of rest after completing a large layer of work. In this case, it is very convenient to immediately take a layer of work and demonstrate that the players see that on the other side are also people who need rest after a job well done.

Conclusion 3. Always show progress.

We all want to show the players for more than excellent, perfectly licked pictures. Since Few people can provide such a flow of high-tech promo art, many take the decisive step - not to show anything at all ... It is much better, having looked at all the sketches, sketches and rejected handwritings, put them in order and spread them in the so-called “work on ...” topics .


Pic.4

On the same forum and the VK group, a bunch of topics and albums with very different stages of working on machines, arenas, guns. We do not see anything wrong in showing the players what path we took in working on the interfaces, telling what the difficulties were and why it is better than before, but not as steep as we would like ... Players see what mistakes we made, understand why now they have what they have, and they believe that if we promise high-quality processing, we will make them, as we have done many times before. The example is relevant for many projects with which I had to work; Metal War is only the most vital of them at the moment. Your KM may not personally provide such contact with the audience, since he does not form your plans and evaluates what the team will master and what is not.

Conclusion 4. Try to give clear and most specific answers.

Many people sin with the desire to respond to any request from the player as soon as possible, “there will definitely be, but not soon / we don’t know for sure when.” And what's even worse is to rush from side to side, when different players start to respond differently about, for example, the proposed feature. If you are in one degree or another production manager (and they are generally talking about them), then you are very sinful not to know the nearest plans for the development of the project, to give lengthy statements and try to please everyone. You are the personification of that very “king-father” who does not know about the riots and if he came, he will clarify everything, decide everything ... it’s better to have a clear position and convey it to the players than to rush in search of the golden mean. As soon as the players notice your uncertainty, they themselves will catch it. In the eyes of your consumers, the team should be the team that knows almost exactly what is better, but listens to different “fluctuations of power” and can correct the vector of work in a timely manner. You should be rooting for you like your favorite football club and forgiving minor failures, because you are about to lose the megavin, and with the active participation of the community ....

Conclusion 5. Show that the team also consists of living people.

Try to pull on the internal resources (of. Forum, of.group on VK) - artists, game designers, programmers. Let the game designer listen to and discuss planned balance adjustments with players. Let the programmer himself hear all about the physical model he has implemented.
That it is important not to get carried away and do not let things take their course. More importantly, do not start replacing KMs with production employees (more on that below). Developers, both ordinary and not, should adhere to some basic regulations, as well as understand about what they can tell players and what they do not. The list of prohibitions in our teams is minimal, I would say even simply absent, because teams have repeatedly shown their adequacy and understanding of the ultimate goal - to make an interesting product for this very audience. The ultimate goal of an entire business is, of course, different, but they are usually closely related ...

Why is this item listed in the article about the management approach? Yes, just an ordinary KM will not force / motivate your gamediz to go to the forum and talk to the players properly. He can offer this, and he will be right, but only the manager can allocate the time of the employee, especially on a certain regular basis. In the end - who is responsible for possible subsidence on the work plans.

Conclusion 6. Do not move away from personal communication

If more precisely - among the players there will always be intelligent and adequate people who want to at least have the opportunity to speak with you directly. At least in the mode of "Estonian chat", but personally. No need to carefully hide your contacts or start some workers, which you can reach at least the most loyal of your users.

Moreover, try to integrate into the life of the community at least small meetings for discussion. NOT mega tusy on holidays, not birthdays of projects and striptease at exhibitions - this is undoubtedly necessary and very cool, but beyond the scope of the article. It's about much simpler things - choose delegates from different groups of users and have a Skype conference with them. For example, on Metal War, we phoned this with a number of employees after the holidays for a couple of hours. We discussed the plans, the results of the year and simply congratulated each other "face to face." You will spend on such a thing for no more than an hour or two a month, but the benefits of such an established contact cannot be overestimated.

If the simple, the moral is - players should be able to at least occasionally raise the issue at the highest level. This will immediately prevent a bunch of small hotbeds of conflict on the forum and other resources. Users should know, even be sure, that a great leadership is following one way or another in what is happening and will not allow a mess.

---

Approach 3. Communication on external resources.

Of particular interest are external general game resources. Often their manager can be just skipped. But if the discussion of the product is still important, then you should be interested in the quality of the dialogue and, possibly, take a personal part in it. Moreover, for some resources, this is generally the most effective way, otherwise the conversation risks quickly turning into a farce with the participation of a dozen or so local trolls — all frequents.

Here you can cite many examples and stories from life, but I think everyone understands very well that for any project there is a resource on which they love and expect it, and there are also those where every news is perceived as a pretext for an aggressive discs. Work with the mood of the audience on such a scale is already more in the competence of professional PR-managers. We can also single out several theses that will be useful to PMs, fruit producers and their ilk.

Thesis 1. You are not here to convince anyone

Users of many forums are accustomed to the guys and girls sent to them at the mercy, in an attempt to tell the world about some cool project. The charter is simple: if someone does not believe - you need to convince. If someone does not believe so that Hamit and insults - you must be silent, smile and convince again. In theory, this tactic ends on the conviction of an inveterate troll or on a nervous breakdown of the unprepared for combat KMa. The probability of the first is extremely low ...

There is a grain of truth in this approach - yes, customers cannot be rude, even if they show the height of inadequacy , and you are the boss of all development. But it is definitely worth it to say goodbye to the tactics of putting everyone on the right path and to represent each opponent as a potential client. The most effective behavior of a manager is to conduct a neutral conversation in general, while responding to criticism with a neutral “thank you for your opinion, time will tell”. NO, of course this is not a universal phrase to appease forum activists. But here the standard pattern will work - “you work out the bread here, here and convince me. And not that .... The trick is that you are not here to convince anyone of anything, not to try to tell why a similar project is bad (this is generally the road to where it is) and not even for working bread. You are here for a dialogue - a banal, general information. For your own pleasure, if you will. Your project is what it is, you do not ask for money in advance, do not sell the cat in a bag (that is, an unknown game on the disk), did not charge players for the development of money, etc. Strangely enough, when a forum member understands that his negative impact is minimal - they will either leave the topic, try to keep the last word, or disperse without any limits, after which the administration will cover him or her in this or other topic for hyperactivity.

Thesis 2. A good producer, an evil producer

Try to avoid what the players will consider "differences in your mood." If you are strict and official, then observe this style to the end. No need to throw apologies for the mistake and a minute later run into the players with the words that you are not enough for everything and you should generally enter into the position and the other “get first”. If you really want to play the trick with the bad and the good - communicate on the forum together with KM, choosing one of the roles. As soon as the players feel that it is easy to break you in the direction of defense, to make them apologize for non-existent damage (your shit free anal game was not released with the anal donate - parry) - the case of communication can be considered failed ... ...

Thesis 3. What are we better

Favorite conversations of any forum - “And what are you better than project X released from company Y?”. My sincere opinion is that there is one correct answer to this question, especially from the manager - “nothing, we make a bias towards ....”. Especially if your project is still under development. And simply - whatever you think about the product of your colleagues, express your loyalty. The best way to divert the conversation in an uncontrolled direction is to begin to deconstruct the flight of the “competitors” on an external resource, where there probably will be more than one fan of this project. Nobody has canceled elementary ethics either - show neutrality towards the works of colleagues in the workshop, who else can understand how difficult the development path is.
This thesis has little to do with internal resources, since within their framework, dialogue can have a completely constructive hue — comparisons, improvements, exchange of impressions, etc.

---

Approach 3. Who is more free?

As mentioned above, the problem of many managers is an attempt to grease under the "communication of developers with the community." This is expressed in the fact that they don’t hire normal PR and Community Managers, but they send someone who’s not very busy to “talk to guys” ... they also saved money and a representative of a developer who knows everything is fresh and useful. It sounds crazy, it works even worse, but it occurs too often not to mention. Usually, the junior assistant to the senior deputy chief programmer is sent to this execution because “It has few cases and in general” ... if your developers have few cases - maybe they are simply not needed?

The result of this dialogue is often embarrassing, contradictory statements, the absence of any planning, etc. Sometimes, very rarely, the chosen one of the team manages to capture and hold the attention of the audience, but more often it turns out such an intermediate person who is too small to “insider”, too “large” to talk to everyone, and really knows too little experience, to play up in talking about the plans and aspirations of the team.
The problems of the approach are also in the fact that it is not enough just to slip someone and hope that you show your closeness to the people, while for some reason you don’t want to see and hear him (otherwise, why find intermediaries). The players are not stupid and the impostor will figure out quickly enough ...

Frankly speaking, only one conclusion can be drawn from this situation - call KMa, or play the role of the team. And saying “hire”, it’s not necessarily about a mega professional with a big salary. To get started, just select one or two of the most appropriate active users and spend N-time on their instruction and control. Otherwise, there can not be - either N time, or M money. Sly, fast and free almost does not work.

---

What's next

Suppose an experienced or not so manager has added some ideas from the material above to his idea of ​​working with the audience. What next? Everything is adjusted and will work like a clock? Of course not. If you pay attention, the material is divided into several completely independent blocks with a set of observations. In fact, there are certainly more of them, but the material does not pretend to be a scientific work and does not bear the role of discoverer of any truths. Rather, the above is such a set of reminders, the essence of which everyone knew and used, but perhaps it did not bring them together. And I would like to note once again separately - you should not confuse the communication of the development management with its audience, and the presence of regular, at least responsible for the work with the community of people. It is unlikely that your activity and enthusiasm will cover all the necessary aspects of interaction with players. And this is, in a sense, the service of your product, according to which customers build an idea of ​​what to expect in the future. If you immediately leave a bad impression (slow response, rudeness, inability to resolve any issues, etc.), then you, as well as from poor service, will start to leave. And it is quite another thing when users see the efforts of the team, the activity of KMs and PR-managers, and especially nice - the personal participation of the leadership in the life of the community. We really hope that the material, if not reflected the importance of the last component, at least made me think about it. And whether to follow the above tips or not - everyone decides for himself.