Why the Pay Per Prototype Model has Stopped Working and harms Mobile Game Developers

Dmitry Yaminsky, co-founder of Azur Games, shares in his column the reasons for the emergence of the Pay Per Prototype model and explains why it no longer makes sense in the current conditions.

Dmitry Yaminsky
Long story short: The market has changed, it has become more demanding on prototypes, and the quantitative approach no longer works.

Against this background, some studios that have not been able to release a hit for a long time fall into a trap: to make money here and now, they shift the focus from the quality of the product to the number of paid prototypes. But now there are other rules on the market, and if you follow them, then getting into the tops is a matter of time, not luck.

To trace the entire “prototyping evolution”, let’s go back a bit. And then let’s move on to the approach of how to successfully cooperate between a publisher and a developer in our time.

As it was before. “Monopolists” and robots

A few years ago, the developers of hyper-casual games were completely at a disadvantage. You send a prototype to major publishers for free in the hope that the first test will show good metrics. Well, if you were unlucky and the metrics were lower than the passing ones, then the build was coming back. This usually happened without discussing the conditions, understanding what else can be finalized in the project and live communication. You send a project to a robot by mail and dream that it will be taken for scaling.

And if you were unlucky, there was no feedback either. What exactly didn’t work, at what point the players left and whether it was possible to somehow finalize the project – it remained to be guessed. I had to either abandon the project, or try a new iteration by intuition.

Several such unsuccessful projects in a row and the studio could have ceased to exist without cashflow. But there were publishers who started paying for the development of prototypes, and this was a big step for the industry.

What happened next. Competition and accumulation of expertise

The market was developing, there were more publishers, competition increased. Azur Games was one of the first who was not looking for a ready—made hit, but began actively helping developers – giving feedback, sharing analytics, attracting their own specialists to improve even those prototypes that other publishers had already abandoned.

The approach has borne fruit. There were more successful projects, and developers were able to choose who to go to. The internal expertise of publishers and the comfort of work came to the fore. At the same time, large publishers began to take on maximum functions — from tests and creating creatives to attracting their game designers, producers, artists, and so on.

The developers did not lose anything, but they could also accumulate their own expertise due to feedback and access to the publisher’s tools (if he gave such an opportunity).

Another distinctive feature of this stage is the focus of publishers on long-term cooperation with studios. The focus has shifted from finding a hit to building a workflow in which a hit will appear sooner or later.

Paying for the prototype was the main way of cooperation. If the project took off, everyone felt comfortable, and the publisher took on all the costs of scaling. If not, the developers at least covered their costs and continued to do what they like (games).

And everything seems to be fair, but even this approach has become outdated over time.

What has become now. More demands and less chances

The GC and mobile market as a whole is no longer young. It continues to grow, but the audience has become more discerning, because of this, the requirements for prototypes have also increased.

Chances to release a hit are now less. Firstly, a huge number of mechanics have been invented and it has become more difficult to hook players. Secondly, the number of games released daily has increased many times. We need to pay more attention not only to marketing, but also to engagement with user retention.

Against this background, the approach when studios and publishers are chasing the number of prototypes, not their quality, no longer works. If earlier it was possible to safely focus on a specific “fork” for a prototype, now we are ready to spend several times more money and time — if only there was a quality product at the output.

So the chance to release a hit is much higher.

What we have come to. And why the PPP model began to harm developers

If you work as before, then the development of the game has to be divided into stages, each of which costs a certain amount of money. For example, the development of a prototype is on average $1500-2500, each iteration for revision is about $ 1500, and so on.

But counting by stages exhausts everyone and greatly shifts the focus from the quality of the product to the survival of the studio. That is, if the cost of maintaining a small studio (salaries, etc.) costs $10,000 per month, and you want to earn the same amount from above, then with an average cost of a prototype of $2,000, you need to make 10 projects per month. Quality is out of the question here.

Why is this happening:

1. For 6-9-12 months, the studio fails to release a successful product.
2. It begins to seem that it is better to make more prototypes and earn not as much as planned at the beginning, but here and now.
3. The stronger the prototyping pipeline is built, the more the quality of products suffers.
4. As a result, the hits either move far away in time, or do not appear at all. Although successful products could completely change the life of the studio.

The model of recent years has not just stopped working — now it harms developers in the future.

Now PPP is rational to use when the publisher and the developer only want to understand whether they are suitable for each other. And if everything is fine, then we, as a publisher, are already interested in the growth of the studio level, and not in the number of prototypes.

To do this, we need to offer a new form of cooperation that will ensure creative freedom and focus on results in the first place, and not endless sifting of new projects.

The current workflow looks like this: at the start of cooperation, we make 1-2-3-4 products according to the PPP model. Both sides estimate how they work with each other, we look at the comfort of work and current results. If everyone is satisfied with everything and the potential is visible, then we offer to fully cover the monthly expenses of the studio without reference to the number of prototypes. It depends on many factors: the number of employees and the level of prototypes.

Instead of a conclusion. And some internal statistics

The success of the product now directly depends on its quality — it is unlikely to get into the top with a run. By quality, I mean both stylistics, and effects, and the overall look & feel from the gameplay, which eventually affect the metrics. There are exceptions, but this is more like a casino than a predicted result.

But if a developer consistently shows a cool level, then sooner or later he will have a project that can be scaled, which will lead to the success of the entire studio.

If we take all the prototypes on the market that are developed jointly with publishers using the PPP model, then the chance to shoot is about 1 in 100 (prototypes that are developed independently are not taken into account, there is an even lower chance). But if you take the studios of a good level, which began to work for quality, then they have 10 times more projects in the tops — about 1 out of 10.

At the same time, the growth of studios with long-term cooperation is almost guaranteed when developers take into account not only the “live” feedback, but also metrics. Not everyone immediately gives the best result, but moving from project to project, you can grow skills and internal expertise at the expense of the publisher’s infrastructure, access to all reports, analytics, the help of game designers and producers, through whom hundreds of projects have passed. The growth of the studio becomes a matter of time and accumulation of expertise along with hard work.

Even after the success, some developers have a desire to go on an independent voyage — quite a normal practice. You should not interfere, you even need to offer investments.