What lessons did I learn from the not-so-successful f2p social

About two and a half years ago, I was hired by a non-game development company to take part in their pilot project - the development of f2p social media with product placement. Prior to this, all my experience in game development was limited to one and a half dozens of small flash casuals and unpretentious iOS applications.

The team was selected as compact as possible: server, client, designer, animator. The investor did not want to inflate the staff, because he himself was not sure of the expediency of this enterprise. Moreover, everyone (except, perhaps, me) knew his job well and was really good at it. It would seem that everything should work out!

There was no overwhelming success, retention and payment indicators turned out to be extremely modest (however, they didn’t invest money in promotion - the ratings were made for the first 200k players who came into the game in the first weeks just from the Vkontakte catalog while the game was hanging in the “new” section ) In matters of monetization and game design, I still did not gain much experience, however I made some conclusions for myself and would like to share them - maybe someone will come in handy. Moreover, now, working in a large gaming company, I especially clearly see how smart and experienced people avoid my “childhood” mistakes.

On the same topic, by the way, I can still recommend wonderful articles “ How to manage to make 14 mistakes by developing one social game ” and “ Purposeful collection and analysis of rakes in the development of games for social networks".

The following, I repeat - this is purely my personal conclusions (largely captain's), based on my own observations and (often) mistakes. So…

image

Do not overestimate yourself


Starting the project, I had no experience in developing games of this size and scale before and frivolously told myself: “Well, to make a game in which there are five times more features and content than in the games that I did before will take five times more time, ”and was greatly mistaken. As a result, a great many nuances and pitfalls came out, which I did not even know about and, by and large, I could not know. “We don’t need a game designer, we read articles, look at similar games and we’ll figure it out ourselves”, “the alpha version will be ready by September, because it seems to me that this will be quite enough”, “other companies have long deadlines "for the bureaucracy, bloated staff and too formalized processes, and now we, like real indies, will pounce and do everything."

Possible solution: ask for a detailed consultation of those people who have already done this and ate a dog. Even if you have to pay money for it, it will pay for itself.

Calculate the timing as pessimistic as possible - so you will not lose


Pretty general recommendation. If it seems that the task can be solved in a week, it is better to plan two weeks for it. And even three. It’s better to take more time and do it ahead of schedule (proving to be prudent and quick), than try to prove yourself a skilled craftsman, taking end-to-end time, working in exhausting crunch and still not keeping up (reducing confidence in the future, and ensuring that your words will no longer be listened to as before).

Game design and planning are crucial


The lack of a dzdok and a plan delayed the development of two to three times. We had only a general idea of ​​what the game would be like, at the level: “It will be a simulator of this and that, where it will be possible to do such and such and such ... well, I would also like to do that and that.” Everything else was invented on the go: features, balance, interface, graphic style. As new ideas came to our minds, we often abandoned old ones, cutting out pieces of ready-made functionality, and making the project less and less like the original vision and full of sticking pieces from remote features. It sometimes turned out like in the comic , only within the framework of one project.

Do not get involved in things not related to the gameplay


We had an object in the game - a sink in the bathroom and in the kitchen, an ordinary washstand for ourselves. We decided to make it so that it was possible to click on it, and a little water started to flow from there. The artist drew an animation, I added an action and two states to the subject: open and closed. Then he was puzzled by how to make the water continue to flow, if you go to the map and then return home again. Then it was thought that it would be nice to keep the state of the object so that water would flow even if you re-enter the game without closing the tap.

And only then, after all this, the realization came: to hell is all this necessary? This adds absolutely no value either to the game process or to monetization - and time is wasted.

Do not try to do much and bad, better little and good


This has already been voiced by me here in a different form. The bottom line is that you should not try to chase the maximum content - it is better to make sure that the existing one works well. Tetris and Bejeweled are beautiful - but they don’t have RPG elements, first-person view, DirectX 11 support, anomalies or swag. Otherwise, it creates only questions like: “Why do you need XXX and ZZZ items in the game?” - “Well, we once thought to add the YYY feature associated with them, but we didn’t get our hands on it properly.”

Do not let people with game design not make game design decisions


Many who are not involved in game development will have a desire to give advice and recommendations regarding the game process - but this does not mean that these people should be listened to. Even an investor should not become a producer - as a product owner, he can make decisions about financing, the general subject of the project, acceptable deadlines and other requirements, but not about balance, art and a set of features.

Test on disinterested people as early as possible


We did a good gameplay, which was understandable and quite convenient. Well, it’s clear that everything is simple there - which is ahead of time for people to show an unprepared game.

But the alarming bell was that when in the later stages they put someone to poke a game at the computer, they constantly had to prompt: “No, no, it’s not right here”, “Well, look, to go to the map - you need to press the button, is it not clear "," No, it won’t work out here, you have to press it differently. " And it was our peer, periodically playing computer games. And we planned to go to social networks, and aim at people of generally different ages and with different backgrounds!

And one more thing, as I read, which is quite common, is the thing: criticism of testers should be taken with gratitude, no offense and attempts to defend oneself (“here, they say, the game is good, they just don't know anything”).

Do not refactor ahead of time (the product is important, not the beauty of the code)


Potential ground for debate, but my personal opinion and conclusions drawn from experience: if the code works and it has few bugs, then you should not touch it at least until the release. The project has an investor, each day of development costs money, and competitors during this time release three similar products. Refactoring becomes an unprofitable masturbation for the beauty of the code, and the optimization results in the spirit of “now this config is parsed not in 0.3, but in 0.1 seconds - three times faster!” Turn out to be doubtful given that the mentioned configuration is loaded only once when the game starts; despite the fact that three days were spent on this optimization with an unfinished project. I want a perfectly beautiful code - write in the evenings the open source engine on the github.

In a commercial project, it should be remembered that each action takes time and delays the release - and, accordingly, costs money. Very simplified: suppose a week of your work costs a thousand dollars, and you spend it on refactoring. In this case, you should do this, being sure that the maintenance and debugging of the non-refactored code in the future will take more than a week in total, or possible bugs can cause losses of more than a thousand dollars.

Conduct stress testing and testing on weak connection


Everything is simple here: no matter how reliable and fast the server seems, it will most likely not withstand the load in the very first days. Similarly, no matter how reliable and effective the interaction between the client and the server seems to be, most likely, with a slow or torn connection, something in the client will not work as it should, or not work at all.

Do not be afraid to ask for help


I will not say for the other team members, however, I personally constantly refused the offers “hand over part of the project to outsourcers, we will give you enough money for this, let them write part of the code in parallel with you.” Just because I wasn't sure about my code. Here, I thought, I have such a disgusting code structure here that other people probably will not even want to work with it, or they will criticize; and in general, everything here is so closely tied up with me that it is impossible to edit one thing without rewriting the pieces throughout the code - because working with it will be more inconvenient for more than one person; Yes, and I have a little left - here I’ll add a trifle in a couple of weeks, and then everything will be easy, then you can think about outsourcers. In a word, he was only concerned with the fact that he came up with excuses why I did not need anyone's help.

In the game you need to provide the player with information on what he can influence


This is a fairly general tip, voiced many times in articles and games. The player should in one form or another provide information on what he can influence and what depends on him. If the game directly responds to its actions, the player must have a clear idea of ​​how and why. It’s enough to imagine, for example, Counter-Strike without an indicator of health or ammo, or World Of Warcarft, in which the level of mobs or the amount of experience remaining to the next level of the hero will not be displayed. The mechanics will not be different, but the player will be unhappy that the game is uncomfortable and does not give him all the important information.

Sooner or later, you still need to release


Sid Meyer said this, but the man knows the matter!

The game always seemed to us unfinished, empty and completely unprepared for release. It seems to me that we could work on it for years, and this feeling would not go anywhere. The reason for this is primarily the lack of planning and the lack of a clear dzdok, which would initially describe the list of features needed for the release, and those that will be added with updates. However, even if there is a dizdok, a fichekat may be necessary if the deadlines are running out - and this is completely normal, and often useful, allowing you to remove the optional husk.

Say the same thing to all players


Having created a VKontakte group for the game, I left a link to my profile in the Administrators section. After that, the players constantly wrote personal messages to me (almost all of them are our CA: girls under 14), among which there were often questions regarding plans for the next updates and planned content. Trying to answer as briefly as possible, sometimes I still talked about something that only hung around in our far-reaching plans at the level: "Maybe if our hands reach, we add features ХХХХХ and YYYYY." Alas, the very next day in the VKontakte group there were already messages from the same player: “The developers told me that the game will have XXXXX,” and now the question “when will you do XXXXX?” You promised! ”From the players became regular.

By the way, Sergey Galenkin in his magnificent bookHe talks about marketing very well about communicating with players, and says, among other things: “If you start a representative office on a social network, be prepared to answer questions and provide technical support there. Players will not use the tools that are convenient for you - they will always choose what is convenient for them. ” I naively believed that having created a topic in the public: “Technical issues on the game” - I will only see them there. Nothing like this! Questions, comments, reviews and complaints were everywhere: in personal messages, under the news in the group (completely unrelated to the topic of the question), and even in the comments under personal photos in my profile. Feeling the desire to write, users write wherever there is a form of post.

Also popular now: