Postmorthem: how to manage to make 14 mistakes, having developed one social game
In February 2012, it was decided to make a computer game on their own. Based on mixed experience, I didn’t focus on the greatest heights of gamedev, concentrating on achievable goals: a small social game on a pair of the largest Russian platforms. All the conditions contributed to this: the desire to develop games, the experience of running a project from idea to release and support, knowledge of the specifics of social networks, experience working with investors, good acquaintances who can always be asked if not help, then at least advice.
Therefore, the next one and a half years of development went through all the stages: the concept, the search for permanent team members, the development of alpha, beta, release, support - all this time we moved the development in the right direction, somehow solved all the problems that had arisen and ... The game "did not shoot." Yes, it happens, games do not shoot much more often than vice versa. After I got distracted from endless fixes, plans for development, discussions with colleagues and other hundreds of pressing issues, withdrew from the project, listened to smart people and simply rested - I realized that this experience can be formalized and even shared with similar independent developers. All those, and also simply interested - I wait under kat.
')
KDPV: the current distribution of projects in geymdev, one Snow White and seven dwarfs.
1. Complete secrecy
Initially, developing a game without advertising it is normal. In fact, you have your main job, your personal life - and you can also stick your own project here. Enthusiasm can pass in a month. Maybe you will understand that the game should be completely different and start writing it from scratch. With any of these options, telling others about your plans will be premature. On the other hand, when the development is already in full swing, you have spent more than one month on the game, you work in a team, there is a budget for freelancers and you can already see some kind of release - it’s stupid to hide from those around you. Especially at the main job where you can get professional advice. Yes, you do not disappear 14 hours a day at the main job, but you should not. You have your own project, but it's silly to call this competition - different weight categories. In addition, when a person engages in something enthusiastically for himself, he grows professionally much faster. And yes, if you work in a game dev, and read this article at work - take your eyes off the monitor and look at your colleagues: half of them have some home projects.
How would we do now: you are not unique, stop nurturing your pride, tell your colleagues and acquaintances about your undertaking. You can get feedback and useful tips. And yes, you are not alone.
2. Lack of experience in game design
We decided to make a game without a game designer. "Why is there such a thing, nothing complicated, everyone is doing social, and we will do." You will do something, but the quality could be better, if you ask a specialist for help. Yes, there are ten of them in Russia. Maybe twelve. But in general, without a game designer, a successful project will fail.
At a certain point after the release, we analyzed the detailed statistics and realized that we have much to strive for. Actually, there is always much to strive for, and when there are no professional game designers in the team - even more so. I asked familiar game designers to leave comments on the finished product.
It was cruel. It was a cold shower. We have done a huge amount of what should not be in successful projects - and it was no longer possible to fix all this at this stage. The results of the action “call a consultant and improve your performance” were disappointing: they only shook our motivation.
How would we do now: hire a game designer, the sooner the better. Calling a game designer for an audit after release is almost as senseless as an aircraft designer after the plane entered at its peak. If you are completely indie, arrange for regular consultations. It will pay for itself.
3. Separability of gameplay from monetization
There are wonderful games from which you can not remove monetization. In Candy Crush Saga you are not obliged to pay - just the game is trying to help you. For a dollar. And this will solve all your problems! You will really overcome this level and you will be delighted! On the other hand, remember some kind of DLC to the popular “big” game: everyone hates them, simply because it looks like such a system of monetization is unconvincingly screwed on the side.
We made the same mistake, without describing in five words why monetization would be invisible and natural for the player.
How would we do now: cunning guys advise - start writing a game with monetization, and then go on to the gameplay. Try it, then tell me how you did it.
4. Lack of gameplay test
The primary role of a game designer is to play the game under development in the head. But even if your head is excellent, your brains are multi-threaded, and your imagination skill exceeds 9000 units - you cannot imagine the experience of your entire target audience. Dirty advice to show mom and grandmother also does not help build a reliable statistical picture. If your gameplay is not interesting, then neither good art nor a great storyline will pull it out. A huge marketing - trite does not pay off. Changing the central idea of the game after a week of work is easy. After six months, you will only have to throw it all out and start over.
How would we do now: test the gameplay on living people. And the sooner the better.
5. Run immediately on the final platform, no soft launch
Thanks to Oleg Pridiuk, who at one of the seminars of the Next Castle Party clearly and distinctly explained how smart people start the game at the very beginning. You need a full primitive, but in which you can play. And the resulting prototype should be put on any platform and let people play. It is desirable for thousands of people. And collect feedback, at the same time forming the core of potential active players.
We had a working prototype, of course, in order to make sure that we are doing everything correctly. But it would never occur to us to lay out a completely non-working game somewhere on Vkontakte, on a standalone website or on any other platform. Just because the project was not ready. Actually, this was the mistake: when we launched the game on the release version, nobody knew about it, and we were not ready for the received feedback and their volume. When launching a prototype on a test platform, it would become clear that attracting a thousand people is not a trivial task, and it is time to clutch at the head and dig in the direction of the marketer / publisher.
How would we do now: make the first early game alpha without graphics, sounds, networking and monetization - and give it to people. Then rename and run on a real platform, nothing to fear.
6. The lack of a prototype for the publisher
Publishers are reasonable and cautious people. They met fanatics a hundred times with ideas. And we also fed them ideas. When it was necessary to make a prototype and provide them with specific numbers. For example: the number of potential consumers, the target audience, the growth of the playing audience. All this can and should have been learned on the prototype - and send proposals for cooperation to publishers. But on the basis of our useless secrecy, we decided - “We'll start up somehow ourselves, all of a sudden everything will be ok”. "Suddenly" did not happen.
How would we do now: send an offer of cooperation to publishers after you have at least something. When it is still easily changeable, but already exists.
7. Reaching the publisher months after release
We wanted to start by ourselves. And not because they wanted all the money in the world only for themselves or they wanted to get experience from the “from and to” process. Rather, everything is explained by banal fear: what if they refuse us? Or deceived? Or simply stop responding after signing the documents? All this happens, and these fears were based on the previous negative experience of communicating with the investor.
After understanding that if we could get a million installations on our own, it would not be after one year - we began to write to the publisher. Naturally, the game was ready and launched on a combat platform. Where is the mistake? We went to be published (it sounds almost like “giving up”, strange ...) after we found that we didn’t cope. This is a losing position because it carries the message “Save us!”. Business people want to invest their time, money and work in something promising, and not in something that no longer works.
How would we do now: if you have never published a game, then your chances of at least getting to zero are scanty. Find someone to whom you can charge the publisher of the game: based on what they have already published and what feedback they have. And if you have found the right options for “yes” - go before the release.
8. Different levels of developer involvement
Two people who developed the game from start to finish initially spent time playing after the main work. After some time I quit, including to spend more time preparing for the release. This was a key mistake that destroyed not so much a specific project as a partnership. Explain myself. Conditions when one person continues to devote the remaining hours of work to the project, and the other spends all her time on it in general — cannot but cause conflict: and not even because one works more than the other, this is just taken lightly if work brings pleasure . Much worse is the sharp conflict in thinking up further tactics: one wants a victorious assault, the second rightly suggests a planned siege. Why? Because the first resources will soon run out and save the project can only decisive breakthrough, and the second is not so dramatic, and therefore reasonable and less impulsive.
How would we do now: in the core-team (and this is always a person two or three) everyone should be equally interested in the success of the current project. Either everyone makes the game in the evenings and on weekends, or they make a leap of faith synchronously. There is no third.
9. Lack of a game development plan at least one year in advance.
If you watch the first WoW videos, you will find on the rotating globe in the logo two continents that did not immediately appear on Azerot: Northrend and Pandaria. Releasing the game in 2004, Blizzard knew how the world map would change by 2011. It is admirable, isn't it?
So, we did not have this. We did some kind of functionality, then we said what we would do next week: and so on until the end. For each update, there was some kind of update, for updating the patch. Yes, this approach can be called flexible and adaptive. But the lack of a medium-term strategy has also led to reworkings, hastily made decisions and aborted work.
How would we do now: come up with a single line of development for the year ahead and bring it to each participant. It is not necessary to decide what color the rose bushes will be in the scenery for next December, just sketch the line along which the project will move next year.
10. Overly soft marketing.
We underestimated the game, and many products were worth less than they could based on the position “Well, who will pay for this garbage? Let's even ask for the ruble. ” There is no need to talk about profits, so just a lesson for the future.
How would we do now: know what the players need and offer them the goods based on the position “You are a solvent player, and our product is good.” By lowering the cost, you won’t get any player love or income. Look at the monetization of other projects and the prices of their products.
11. Lack of work schedule
For us it was not a problem: the numbers did not crush, everyone knew what to do and everyone was happy. But in general, this is a big mistake: without a work schedule, you will not be able to agree on cooperation with other people, because for business, that project is good, which is predictable.
How would we do now: leave unpredictable players. In a business environment it is better to stick to a work plan
12. Wrong budget calculation: the cost of the game is not only the cost of content.
Everything is simple: the cost of promoting a social game is likely to block salary costs. We tried not to think about it at the very beginning, and then the budget didn’t go at all as planned.
How would we do now: realize that no one will notice your game without marketing. Plan for appropriate expenses. And better with an experienced publisher.
13. Approach to game production from a programmer's point of view.
You can not release the game well, if you think about it as a programmer: within the framework of internal relations, classes, dependencies, patterns. I constantly had to rise to a higher level and follow the deadlines and embedded features. The habit of writing good code sometimes blocked the addition of potentially interesting, but important innovations, and also slowed down the development.
How would we do now: if in your project you are both a producer and a developer, then the unpleasant role of an attacker on the throat belongs to you. Sometimes you have to say "this feature had to be done yesterday, so forget about the Gang of Four and write a terrible crutch" - otherwise there will be no one to say this.
14. Reluctance to throw a game, even if it is obviously failed
We missed the moment when it became clear that the game had failed and it was not worth wasting our strength on it. Just one day you break away from dizdok-code-correspondence, you look at all this and you are perplexed: if it gives me neither pleasure, nor money, nor experience - why do I continue to get up every day at seven, spend most of my time, kick people? Why didn't it end months ago?
How would we do now: if it stinks, most likely, it is dead. Bury it.
Conclusion:
The main problem of such articles is that people nod their heads: “Yes, all this is understandable” and “Thank you, cap”, but they do not get real experience. If I had read such an article a month before the release of the game under discussion, I would have agreed with it and safely forgot. On the other hand, I hope that it will help those who are currently thinking about their personal experience in game development, and do not rule out that even there will be lucky people who, pushing from our experience, will make the right choices.
I do not want to post a link to the game for several reasons:
1) This article is not PR, but the opportunity to share experiences.
2) Despite the need for feedback, now it will be of little use to this project.
3) The opinion of the average habrovchanin will be equally far from both the target audience of the game and the professional game designer.
4) Habraeffekt.
Answering the question why the author, having noticed these errors, did not correct them in the current project: “to give birth to the game back” will come out much more expensive in time and emotions, rather than having armed with new knowledge to take blues (this is paper, not what you thought! ) and sketch out the next project.
I want to say thank you to everyone who participated in the development of this game. Thanks to you and the new rake, the next game will be better. And the rake is more sophisticated, which only adds some kind of peppercorn to the routine cyclic development processes.
Therefore, the next one and a half years of development went through all the stages: the concept, the search for permanent team members, the development of alpha, beta, release, support - all this time we moved the development in the right direction, somehow solved all the problems that had arisen and ... The game "did not shoot." Yes, it happens, games do not shoot much more often than vice versa. After I got distracted from endless fixes, plans for development, discussions with colleagues and other hundreds of pressing issues, withdrew from the project, listened to smart people and simply rested - I realized that this experience can be formalized and even shared with similar independent developers. All those, and also simply interested - I wait under kat.
')
KDPV: the current distribution of projects in geymdev, one Snow White and seven dwarfs.
1. Complete secrecy
Initially, developing a game without advertising it is normal. In fact, you have your main job, your personal life - and you can also stick your own project here. Enthusiasm can pass in a month. Maybe you will understand that the game should be completely different and start writing it from scratch. With any of these options, telling others about your plans will be premature. On the other hand, when the development is already in full swing, you have spent more than one month on the game, you work in a team, there is a budget for freelancers and you can already see some kind of release - it’s stupid to hide from those around you. Especially at the main job where you can get professional advice. Yes, you do not disappear 14 hours a day at the main job, but you should not. You have your own project, but it's silly to call this competition - different weight categories. In addition, when a person engages in something enthusiastically for himself, he grows professionally much faster. And yes, if you work in a game dev, and read this article at work - take your eyes off the monitor and look at your colleagues: half of them have some home projects.
How would we do now: you are not unique, stop nurturing your pride, tell your colleagues and acquaintances about your undertaking. You can get feedback and useful tips. And yes, you are not alone.
2. Lack of experience in game design
We decided to make a game without a game designer. "Why is there such a thing, nothing complicated, everyone is doing social, and we will do." You will do something, but the quality could be better, if you ask a specialist for help. Yes, there are ten of them in Russia. Maybe twelve. But in general, without a game designer, a successful project will fail.
At a certain point after the release, we analyzed the detailed statistics and realized that we have much to strive for. Actually, there is always much to strive for, and when there are no professional game designers in the team - even more so. I asked familiar game designers to leave comments on the finished product.
It was cruel. It was a cold shower. We have done a huge amount of what should not be in successful projects - and it was no longer possible to fix all this at this stage. The results of the action “call a consultant and improve your performance” were disappointing: they only shook our motivation.
How would we do now: hire a game designer, the sooner the better. Calling a game designer for an audit after release is almost as senseless as an aircraft designer after the plane entered at its peak. If you are completely indie, arrange for regular consultations. It will pay for itself.
3. Separability of gameplay from monetization
There are wonderful games from which you can not remove monetization. In Candy Crush Saga you are not obliged to pay - just the game is trying to help you. For a dollar. And this will solve all your problems! You will really overcome this level and you will be delighted! On the other hand, remember some kind of DLC to the popular “big” game: everyone hates them, simply because it looks like such a system of monetization is unconvincingly screwed on the side.
We made the same mistake, without describing in five words why monetization would be invisible and natural for the player.
How would we do now: cunning guys advise - start writing a game with monetization, and then go on to the gameplay. Try it, then tell me how you did it.
4. Lack of gameplay test
The primary role of a game designer is to play the game under development in the head. But even if your head is excellent, your brains are multi-threaded, and your imagination skill exceeds 9000 units - you cannot imagine the experience of your entire target audience. Dirty advice to show mom and grandmother also does not help build a reliable statistical picture. If your gameplay is not interesting, then neither good art nor a great storyline will pull it out. A huge marketing - trite does not pay off. Changing the central idea of the game after a week of work is easy. After six months, you will only have to throw it all out and start over.
How would we do now: test the gameplay on living people. And the sooner the better.
5. Run immediately on the final platform, no soft launch
Thanks to Oleg Pridiuk, who at one of the seminars of the Next Castle Party clearly and distinctly explained how smart people start the game at the very beginning. You need a full primitive, but in which you can play. And the resulting prototype should be put on any platform and let people play. It is desirable for thousands of people. And collect feedback, at the same time forming the core of potential active players.
We had a working prototype, of course, in order to make sure that we are doing everything correctly. But it would never occur to us to lay out a completely non-working game somewhere on Vkontakte, on a standalone website or on any other platform. Just because the project was not ready. Actually, this was the mistake: when we launched the game on the release version, nobody knew about it, and we were not ready for the received feedback and their volume. When launching a prototype on a test platform, it would become clear that attracting a thousand people is not a trivial task, and it is time to clutch at the head and dig in the direction of the marketer / publisher.
How would we do now: make the first early game alpha without graphics, sounds, networking and monetization - and give it to people. Then rename and run on a real platform, nothing to fear.
6. The lack of a prototype for the publisher
Publishers are reasonable and cautious people. They met fanatics a hundred times with ideas. And we also fed them ideas. When it was necessary to make a prototype and provide them with specific numbers. For example: the number of potential consumers, the target audience, the growth of the playing audience. All this can and should have been learned on the prototype - and send proposals for cooperation to publishers. But on the basis of our useless secrecy, we decided - “We'll start up somehow ourselves, all of a sudden everything will be ok”. "Suddenly" did not happen.
How would we do now: send an offer of cooperation to publishers after you have at least something. When it is still easily changeable, but already exists.
7. Reaching the publisher months after release
We wanted to start by ourselves. And not because they wanted all the money in the world only for themselves or they wanted to get experience from the “from and to” process. Rather, everything is explained by banal fear: what if they refuse us? Or deceived? Or simply stop responding after signing the documents? All this happens, and these fears were based on the previous negative experience of communicating with the investor.
After understanding that if we could get a million installations on our own, it would not be after one year - we began to write to the publisher. Naturally, the game was ready and launched on a combat platform. Where is the mistake? We went to be published (it sounds almost like “giving up”, strange ...) after we found that we didn’t cope. This is a losing position because it carries the message “Save us!”. Business people want to invest their time, money and work in something promising, and not in something that no longer works.
How would we do now: if you have never published a game, then your chances of at least getting to zero are scanty. Find someone to whom you can charge the publisher of the game: based on what they have already published and what feedback they have. And if you have found the right options for “yes” - go before the release.
8. Different levels of developer involvement
Two people who developed the game from start to finish initially spent time playing after the main work. After some time I quit, including to spend more time preparing for the release. This was a key mistake that destroyed not so much a specific project as a partnership. Explain myself. Conditions when one person continues to devote the remaining hours of work to the project, and the other spends all her time on it in general — cannot but cause conflict: and not even because one works more than the other, this is just taken lightly if work brings pleasure . Much worse is the sharp conflict in thinking up further tactics: one wants a victorious assault, the second rightly suggests a planned siege. Why? Because the first resources will soon run out and save the project can only decisive breakthrough, and the second is not so dramatic, and therefore reasonable and less impulsive.
How would we do now: in the core-team (and this is always a person two or three) everyone should be equally interested in the success of the current project. Either everyone makes the game in the evenings and on weekends, or they make a leap of faith synchronously. There is no third.
9. Lack of a game development plan at least one year in advance.
If you watch the first WoW videos, you will find on the rotating globe in the logo two continents that did not immediately appear on Azerot: Northrend and Pandaria. Releasing the game in 2004, Blizzard knew how the world map would change by 2011. It is admirable, isn't it?
So, we did not have this. We did some kind of functionality, then we said what we would do next week: and so on until the end. For each update, there was some kind of update, for updating the patch. Yes, this approach can be called flexible and adaptive. But the lack of a medium-term strategy has also led to reworkings, hastily made decisions and aborted work.
How would we do now: come up with a single line of development for the year ahead and bring it to each participant. It is not necessary to decide what color the rose bushes will be in the scenery for next December, just sketch the line along which the project will move next year.
10. Overly soft marketing.
We underestimated the game, and many products were worth less than they could based on the position “Well, who will pay for this garbage? Let's even ask for the ruble. ” There is no need to talk about profits, so just a lesson for the future.
How would we do now: know what the players need and offer them the goods based on the position “You are a solvent player, and our product is good.” By lowering the cost, you won’t get any player love or income. Look at the monetization of other projects and the prices of their products.
11. Lack of work schedule
For us it was not a problem: the numbers did not crush, everyone knew what to do and everyone was happy. But in general, this is a big mistake: without a work schedule, you will not be able to agree on cooperation with other people, because for business, that project is good, which is predictable.
How would we do now: leave unpredictable players. In a business environment it is better to stick to a work plan
12. Wrong budget calculation: the cost of the game is not only the cost of content.
Everything is simple: the cost of promoting a social game is likely to block salary costs. We tried not to think about it at the very beginning, and then the budget didn’t go at all as planned.
How would we do now: realize that no one will notice your game without marketing. Plan for appropriate expenses. And better with an experienced publisher.
13. Approach to game production from a programmer's point of view.
You can not release the game well, if you think about it as a programmer: within the framework of internal relations, classes, dependencies, patterns. I constantly had to rise to a higher level and follow the deadlines and embedded features. The habit of writing good code sometimes blocked the addition of potentially interesting, but important innovations, and also slowed down the development.
How would we do now: if in your project you are both a producer and a developer, then the unpleasant role of an attacker on the throat belongs to you. Sometimes you have to say "this feature had to be done yesterday, so forget about the Gang of Four and write a terrible crutch" - otherwise there will be no one to say this.
14. Reluctance to throw a game, even if it is obviously failed
We missed the moment when it became clear that the game had failed and it was not worth wasting our strength on it. Just one day you break away from dizdok-code-correspondence, you look at all this and you are perplexed: if it gives me neither pleasure, nor money, nor experience - why do I continue to get up every day at seven, spend most of my time, kick people? Why didn't it end months ago?
How would we do now: if it stinks, most likely, it is dead. Bury it.
Conclusion:
The main problem of such articles is that people nod their heads: “Yes, all this is understandable” and “Thank you, cap”, but they do not get real experience. If I had read such an article a month before the release of the game under discussion, I would have agreed with it and safely forgot. On the other hand, I hope that it will help those who are currently thinking about their personal experience in game development, and do not rule out that even there will be lucky people who, pushing from our experience, will make the right choices.
I do not want to post a link to the game for several reasons:
1) This article is not PR, but the opportunity to share experiences.
2) Despite the need for feedback, now it will be of little use to this project.
3) The opinion of the average habrovchanin will be equally far from both the target audience of the game and the professional game designer.
4) Habraeffekt.
Answering the question why the author, having noticed these errors, did not correct them in the current project: “to give birth to the game back” will come out much more expensive in time and emotions, rather than having armed with new knowledge to take blues (this is paper, not what you thought! ) and sketch out the next project.
I want to say thank you to everyone who participated in the development of this game. Thanks to you and the new rake, the next game will be better. And the rake is more sophisticated, which only adds some kind of peppercorn to the routine cyclic development processes.
Source: https://habr.com/ru/post/201692/
All Articles