What lessons did I learn from the not very successful f2p socials
About two and a half years ago, I was hired by a company not related to the development of games to take part in their pilot project - the development of f2p social programs with product placement. Prior to that, my whole experience in game development was limited to a dozen small flash games and unpretentious iOS applications.
The team got as compact as possible: server maker, client maker, designer, animation artist. 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 business well and was really good at it. It would seem that everything should turn out!
There was no overwhelming success, retention and payment indicators turned out to be extremely modest (although the money was not invested in the promotion - estimates were made on the first 200k players who came into the game in the first weeks simply from the Vkontakte catalog, while the game hung in the "new" section ). In matters of monetization and game design, I still didn’t gain much experience, but 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 can clearly see how clever and experienced people avoid my "children's" mistakes.
')
On the same topic, by the way, I can still recommend the wonderful articles " How to manage to make 14 mistakes by developing one social game " and " Purposeful collection and analysis of the rake in developing games for social networks ."
The following, I repeat, is purely my personal conclusions (largely captain) based on my own observations and (often) mistakes. So…
When embarking on the project, I had no previous experience in developing games of this size and scale and thoughtlessly saying to myself: “Well, to make a game in which five times more features and content than in games that I did before will take five more time, ”and was greatly mistaken. As a result, a great many nuances and pitfalls came out, which I did not even guess about and, by and large, could not know. “We don’t need a game designer, read articles, look at similar games - and figure it out for ourselves”, “the alpha version will be ready by September, because it seems to me that this will be quite enough”, “other companies have long terms for bureaucracy, bloated staff and overly formalized processes, and now we are like real indies and we will do everything. ”
A possible way out: 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.
Pretty general recommendation. If it seems that the problem can be solved in a week, it is better to schedule two weeks for it. And even three. It is better to take more time and do it ahead of time (proving to be prudent and quick) than try to establish yourself as a skilled hero, taking time to go and working in a harder job and still failing (reducing trust in yourself in the future and ensuring that your words will not be listened to as before).
The lack of a dizdok and plan has delayed the development of two to three times. We had only a general idea of ​​what the game would be like, at the level: “This will be a simulator of that, where you can do this and that ... well, and I would also like 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 the project itself made everything less similar to the original vision and full of protruding pieces from distant features. It turned out sometimes like in a comic book , only within one project.
We had an object in the game - a sink in the bathroom and in the kitchen, an ordinary wash basin. They decided to make it so that you could click on it, and some water began to flow from there. The artist painted the animation, I added an action and two states on 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 maintain the state of the object so that the water would flow even if you restart the game without closing the tap.
And only then, after all this, came the realization: the hell is all you need? It adds absolutely no value to the gameplay or monetization - and time is wasted.
This has already been voiced by me 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 - and after all in them there are no RPG-elements, a kind from the first person, support DirectX 11, anomalies and swag. Otherwise, it creates only questions like: “But why are there XXX and ZZZ items in the game?” - “Well, we thought to add the YYY feature associated with them once, but we never really got to finish our hands.”
Many who are not connected with the development of games will have a desire to give advice and recommendations regarding the gameplay - but this does not mean at all that these people should be listened to. Even an investor should not become a producer - being a product owner, he can make decisions about financing, the overall project scope, permissible terms and other requirements, but not about balance, art and feature set.
We did a good gameplay, which was understandable and quite comfortable. Well, it is 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 someone was put to the computer to poke into the game, they constantly had to say: “No, no, this is not necessary”, “Well, look, to get the card, you need to press the button, is it unclear "," No, it will not work like this, you have to press it differently here. And it was our peer, periodically playing computer games. And we planned to go to social networks, and target people in general of different ages and with different backgrounds!
And one more - as I read, a fairly common - thing: the criticism of testers should be perceived with gratitude, without offense and attempts to defend themselves (“well, they say, the game is good, they just noobs do not understand anything”).
Potential ground for disputes, but my personal opinion and conclusions drawn from experience: if the code works and there are few bugs in it, then you should not touch it at least until release. The project has an investor, every day development costs money, and competitors during this time produce three similar products. Refactoring becomes an unprofitable onanism to the beauty of the code, and the optimization results in the spirit of "now this config is not parsed in 0.3, but in 0.1 seconds - three times faster!" Turn out to be doubtful given that the mentioned config is loaded only once when the game starts; despite the fact that this optimization was spent three days with the unfinished project. I want an ideally beautiful code - write in the evening an open source engine on a github.
In a commercial project, it should be remembered that every action takes time and delays the release - and, accordingly, costs money. Very simply: suppose a week of your work is worth 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 the amount, or possible bugs can cause damage by more than a thousand dollars.
Everything is simple here: no matter how reliable and fast the server may seem - it most likely will not withstand the load in the first few days. Similarly, no matter how reliable and efficient the client’s interaction with the server may be, most likely, with a slow or disconnecting connection, something in the client will not work as it should, or not at all.
I will not say for the other team members, but personally I constantly refused to offer “hand over part of the project to outsourcers, we will allocate as much money to you as possible, let them write part of the code in parallel with you.” Just because I was not sure about my code. Here, I thought, I have such a disgusting code structure here that other people probably don’t even want to work with it, or will be criticized; and in general, everything here is so closely tied to me that it is impossible to rule one thing without rewriting pieces throughout the code - therefore, it will be inconvenient to work with more than one person at all; Yes, and I have a little left here - here’s another little thing I’ll add in a couple of weeks, and then everything will be easy, then you can think of outsourcers. In a word, I was engaged only in those that came up with excuses, why I don’t need any help. And in fact - I was just afraid to ask for help.
This is a fairly general tip, voiced many times in articles and games. The player should in one form or another to provide information about what he can influence and what depends on him. If the game responds directly to its actions - the player must have a clear idea of ​​how and why. Just imagine, for example, Counter-Strike without a health indicator or ammunition, or World Of Warcarft, in which the level of mobs or the amount of experience remaining until the next level of the hero will not be displayed. The mechanics will not differ, but the player will be unhappy that the game is inconvenient and does not give him all the important information.
This is still Sid Meier said, 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 have gone anywhere. This is primarily due to the lack of planning and the lack of a clear dizdok, which would initially describe the list of features needed for the release, and those that will be added with updates. However, even in the presence of dizdok, a face-to-face may be necessary if deadlines are tight - and this is perfectly normal, and often useful, allowing you to remove the optional husks.
Having created a Vkontakte group for the game, I left a link to my profile in the “Administrators” section. After that, players constantly wrote me personal messages (almost all of them are our Central Asian: girls under 14 years old), among which there were often questions about plans for the next updates and planned content. Trying to answer as briefly as possible, sometimes I still talked about something that only soared in our far-reaching plans at the level: “Maybe if hands reach, add features XXXXX and YYYYY”. Alas, the very next day in the Vkontakte group there were already messages from the same player: “The developers told me that there would be XXXXX in the game”, and henceforth the question “and when will you already make XXXXX? You promised! ”From the players became regular.
By the way, Sergey Galyonkin in his excellent book on marketing talks very nicely about communicating with players, and among other things says: “If you start a representative office on a social network, be ready 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 thought that by creating a topic in Public: “Technical issues about the game” - I will only see them there. Nothing like this! Questions, comments, feedback and complaints were everywhere: in personal messages, under the news in the group (completely unrelated to the subject of the question), and even in the comments under the personal photos in my profile. Feeling a desire to write, users write wherever there is a form of fasting.
The team got as compact as possible: server maker, client maker, designer, animation artist. 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 business well and was really good at it. It would seem that everything should turn out!
There was no overwhelming success, retention and payment indicators turned out to be extremely modest (although the money was not invested in the promotion - estimates were made on the first 200k players who came into the game in the first weeks simply from the Vkontakte catalog, while the game hung in the "new" section ). In matters of monetization and game design, I still didn’t gain much experience, but 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 can clearly see how clever and experienced people avoid my "children's" mistakes.
')
On the same topic, by the way, I can still recommend the wonderful articles " How to manage to make 14 mistakes by developing one social game " and " Purposeful collection and analysis of the rake in developing games for social networks ."
The following, I repeat, is purely my personal conclusions (largely captain) based on my own observations and (often) mistakes. So…
Do not overestimate yourself
When embarking on the project, I had no previous experience in developing games of this size and scale and thoughtlessly saying to myself: “Well, to make a game in which five times more features and content than in games that I did before will take five more time, ”and was greatly mistaken. As a result, a great many nuances and pitfalls came out, which I did not even guess about and, by and large, could not know. “We don’t need a game designer, read articles, look at similar games - and figure it out for ourselves”, “the alpha version will be ready by September, because it seems to me that this will be quite enough”, “other companies have long terms for bureaucracy, bloated staff and overly formalized processes, and now we are like real indies and we will do everything. ”
A possible way out: 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 deadlines as pessimistic - so you will not lose
Pretty general recommendation. If it seems that the problem can be solved in a week, it is better to schedule two weeks for it. And even three. It is better to take more time and do it ahead of time (proving to be prudent and quick) than try to establish yourself as a skilled hero, taking time to go and working in a harder job and still failing (reducing trust in yourself in the future and ensuring that your words will not be listened to as before).
Game design and planning are essential.
The lack of a dizdok and plan has delayed the development of two to three times. We had only a general idea of ​​what the game would be like, at the level: “This will be a simulator of that, where you can do this and that ... well, and I would also like 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 the project itself made everything less similar to the original vision and full of protruding pieces from distant features. It turned out sometimes like in a comic book , only within one project.
Do not get involved in non-gameplay things
We had an object in the game - a sink in the bathroom and in the kitchen, an ordinary wash basin. They decided to make it so that you could click on it, and some water began to flow from there. The artist painted the animation, I added an action and two states on 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 maintain the state of the object so that the water would flow even if you restart the game without closing the tap.
And only then, after all this, came the realization: the hell is all you need? It adds absolutely no value to the gameplay or monetization - and time is wasted.
Do not try to do a lot of things and it’s bad
This has already been voiced by me 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 - and after all in them there are no RPG-elements, a kind from the first person, support DirectX 11, anomalies and swag. Otherwise, it creates only questions like: “But why are there XXX and ZZZ items in the game?” - “Well, we thought to add the YYY feature associated with them once, but we never really got to finish our hands.”
Not to give game design decisions to people with no game design
Many who are not connected with the development of games will have a desire to give advice and recommendations regarding the gameplay - but this does not mean at all that these people should be listened to. Even an investor should not become a producer - being a product owner, he can make decisions about financing, the overall project scope, permissible terms and other requirements, but not about balance, art and feature set.
Test on uninterested people as early as possible.
We did a good gameplay, which was understandable and quite comfortable. Well, it is 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 someone was put to the computer to poke into the game, they constantly had to say: “No, no, this is not necessary”, “Well, look, to get the card, you need to press the button, is it unclear "," No, it will not work like this, you have to press it differently here. And it was our peer, periodically playing computer games. And we planned to go to social networks, and target people in general of different ages and with different backgrounds!
And one more - as I read, a fairly common - thing: the criticism of testers should be perceived with gratitude, without offense and attempts to defend themselves (“well, they say, the game is good, they just noobs do not understand anything”).
Do not refactor ahead of time (the product is important, not the beauty of the code)
Potential ground for disputes, but my personal opinion and conclusions drawn from experience: if the code works and there are few bugs in it, then you should not touch it at least until release. The project has an investor, every day development costs money, and competitors during this time produce three similar products. Refactoring becomes an unprofitable onanism to the beauty of the code, and the optimization results in the spirit of "now this config is not parsed in 0.3, but in 0.1 seconds - three times faster!" Turn out to be doubtful given that the mentioned config is loaded only once when the game starts; despite the fact that this optimization was spent three days with the unfinished project. I want an ideally beautiful code - write in the evening an open source engine on a github.
In a commercial project, it should be remembered that every action takes time and delays the release - and, accordingly, costs money. Very simply: suppose a week of your work is worth 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 the amount, or possible bugs can cause damage by more than a thousand dollars.
Stress testing and weak compound testing
Everything is simple here: no matter how reliable and fast the server may seem - it most likely will not withstand the load in the first few days. Similarly, no matter how reliable and efficient the client’s interaction with the server may be, most likely, with a slow or disconnecting connection, something in the client will not work as it should, or not at all.
Do not be afraid to ask for help.
I will not say for the other team members, but personally I constantly refused to offer “hand over part of the project to outsourcers, we will allocate as much money to you as possible, let them write part of the code in parallel with you.” Just because I was not sure about my code. Here, I thought, I have such a disgusting code structure here that other people probably don’t even want to work with it, or will be criticized; and in general, everything here is so closely tied to me that it is impossible to rule one thing without rewriting pieces throughout the code - therefore, it will be inconvenient to work with more than one person at all; Yes, and I have a little left here - here’s another little thing I’ll add in a couple of weeks, and then everything will be easy, then you can think of outsourcers. In a word, I was engaged only in those that came up with excuses, why I don’t need any help. And in fact - I was just afraid to ask for 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 to provide information about what he can influence and what depends on him. If the game responds directly to its actions - the player must have a clear idea of ​​how and why. Just imagine, for example, Counter-Strike without a health indicator or ammunition, or World Of Warcarft, in which the level of mobs or the amount of experience remaining until the next level of the hero will not be displayed. The mechanics will not differ, but the player will be unhappy that the game is inconvenient and does not give him all the important information.
Sooner or later you still need to release
This is still Sid Meier said, 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 have gone anywhere. This is primarily due to the lack of planning and the lack of a clear dizdok, which would initially describe the list of features needed for the release, and those that will be added with updates. However, even in the presence of dizdok, a face-to-face may be necessary if deadlines are tight - and this is perfectly normal, and often useful, allowing you to remove the optional husks.
Tell all players the same thing.
Having created a Vkontakte group for the game, I left a link to my profile in the “Administrators” section. After that, players constantly wrote me personal messages (almost all of them are our Central Asian: girls under 14 years old), among which there were often questions about plans for the next updates and planned content. Trying to answer as briefly as possible, sometimes I still talked about something that only soared in our far-reaching plans at the level: “Maybe if hands reach, add features XXXXX and YYYYY”. Alas, the very next day in the Vkontakte group there were already messages from the same player: “The developers told me that there would be XXXXX in the game”, and henceforth the question “and when will you already make XXXXX? You promised! ”From the players became regular.
By the way, Sergey Galyonkin in his excellent book on marketing talks very nicely about communicating with players, and among other things says: “If you start a representative office on a social network, be ready 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 thought that by creating a topic in Public: “Technical issues about the game” - I will only see them there. Nothing like this! Questions, comments, feedback and complaints were everywhere: in personal messages, under the news in the group (completely unrelated to the subject of the question), and even in the comments under the personal photos in my profile. Feeling a desire to write, users write wherever there is a form of fasting.
Source: https://habr.com/ru/post/247763/
All Articles