New midcore development workflow

Despite the lack of results, this case has taught us a lot. We’ve completely revised the midcore development process in favor of fast testing and shutting down projects with bad metrics. Now every project goes through a prototype stage that takes 3-6 months, and we never plan for the future or even think about monetization until we get an acceptable R1 on the prototype.

Nowadays, we break down midcore development into the following stages:

1. Idea selection and analysis.
2. Prototype development with a focus on R1.
3. Step-by-step product updates with a focus on R7-R14-R21-R30.
4. Monetization and further growth.

Most importantly, we’re not afraid to shut down midcore projects with bad metrics anymore. Conveniently, the cost of error went down after we introduced the prototype stage. We give the project a second chance only if the new ideas for it can be tested in less than a month.

Let’s take a closer look at each stage.

1. Idea selection and analysis

Before the development starts, we always take a good look at the market trends. Thankfully,  they don’t change as quickly as they do in hypercasual games.

Just a few years ago, the pay-to-win model was the norm for free-to-play games. Now, there’s a rise of F2P games that have competitive mechanics and don’t have the option of paid progress. Take any battle royale game — your skill is what matters the most, not upgrades and level ups. The point is, making a game with P2W monetization for a young audience is not a good idea in this day and age, so we discard outdated ideas like this one right away.

At the same time, new global trends tend to catch the attention of the industry heavyweights very fast. They invest a lot of money in development and it becomes very difficult to compete with the ‘Call of Duty’ of this genre. A good strategy would be to look into niche subgenres that still have enough room for you to become the number one player and make good money.

For instance, there was a game called Deer Hunter that was very popular at one point. On one hand, hunting games are very niche, but at the same time the project has become a hit in the sniper game segment.

There’s also an actual wolf simulator — the game performed really well and I doubt that any large company is going to make an expensive competitor to it. In other words, there’s a big chance some other developer is going to become the #1 animal simulator company and keep growing and developing in this trajectory. We have King of Sails — pirate ship battles are another uncommon theme, and we’re thinking of exploring this direction more.

Another way to find your niche is to combine mechanics and create a new genre with less competition. Why not combine Fall Guys with a shooter or city-building elements? Or seek inspiration from original indie games on Steam? Mobile tech has advanced enough to bring niche products popular on PC to smartphones.

After we’re done with the list of ideas, we begin to analyze how many users would want to play this game. There’s no single tool that will answer this question unambiguously; we have to consider a massive number of factors to make this decision. Here’s what we use:

• our own experience with launched projects and tested prototypes;
• store chart analysis;
• popular Google search result breakdowns;
• competitor research;
• doctored screenshots.

You can somewhat assess the future project’s potential only after you complete all these steps.

Still, even the most original idea doesn’t guarantee success, so we approach the development carefully, breaking it down into iterations and testing on a real audience as early as possible.

2. Prototyping

First you need to figure out if the players like the core gameplay, and if your game is even interesting enough for someone to play it. This is why we make prototypes with one goal in mind — to check Day 1 retention (R1).

Other metrics aren’t important at this stage. We don’t need to make high-level content, add social features or think about original bosses. All we need to do is figure out if the game is interesting enough for the players to come back to it again. However, there’s one small detail.

Players should get a sense of consistency when they first start the game — the visuals, the UI, and all basic mechanics should be finished. The content you have may not be enough for the coming days, but the first day should feel like the game is complete. If it’s a PvP shooter, the multiplayer should work, the lobby should be set up, and players should be able to connect and get a full gaming experience.

This is the reason why we allocate 3 to 6 months to develop the first prototype. During this time, we focus on crafting the day 1 experience and giving the mechanics the right feel. At this point, it doesn’t matter if the game makes money or how we’re going to monetize it in general — what’s important is that we get a good gameplay ‘filling’.

On average, we’re looking for a 35% R1 or higher, but this number depends on the genre and varies from case to case. For example, we know that auto battlers have a slightly lower acceptable day 1 retention (about 32%), while simulators have 40%.

If prototype testing shows lower numbers, we start looking for a quick and inexpensive experiment we could conduct to increase retention. This iteration shouldn’t take more than a month, otherwise we’ll end up with another long and expensive development cycle on our hands.

If the update didn’t help us reach the desired R1, we shut the project down without wasting any time. Worst case scenario, we lose 3 to 7 months on development and can switch to more promising projects right after.

And if everything looks good, the development continues and we start adding features for long-term retention.

3. R7 – R30

Next, we work on R7. At this stage, we add some content and work with the meta, paying less attention to the core gameplay.

We can add some kind of basic monetization like in-app purchases, but globally we don’t touch anything that will take us a long time to execute. For example, we can add weapons for sale to make the game feel more complete, but we’re definitely not going to start implementing shards or workshops. They don’t affect the day 7 retention, but they require a lot of effort from the team.

The kind of content we add depends on the genre. If it’s a simulator, we’ll focus on the meta and content, if it’s a shooter, we’ll pay more attention to social features, clans, and so on.

The first goal of this stage is to get 10% or more on R7.

If we’ve reached the desired number, we repeat the iteration to test R14, R21, until we reach R30, which should be about 4%.

Simultaneously, we add medium and long-term goals to the game. If winning a match is a short-term goal, then unlocking a character is a mid-term goal, and taking 1st place in a weekly event or winning a tournament is a long-term goal.

We take care of the product operation basis around the same time. This is especially for players who have completed the game’s basic flow — we come up with things like events and additional content and think how we’re going to apply it.

Also, when it becomes clear that the game is likely to show a good R30, we expand the foundation for monetization. For example, if we only made a basic weapons shop, but we’re counting on getting 50% of the revenue from upgrades in the future, we need to add tools to make it possible. So, we need to decide what kind of upgrade system it will be and how it will work.

When we reach R30, we continue to add meta, content and work on social features if the genre allows us to do so. We also start to work on retention features like events to keep things interesting for the players. We pay special attention to the game complexity and gradually increase it.

4. Monetization and further growth

Now we can tackle monetization for real. If you have an engaged audience, even the most basic monetization model starts to work by this point.

There are many options for subsequent monetization development, and that’s when we involve the analysts. There’s a direct correlation between retention and monetization, so some fine tuning is bound to happen, but that’s a whole different story.

As for marketing, we do test launches and A/B tests throughout the entire development cycle, starting with the first prototype. Large-scale user acquisition only makes sense if you do it when you have monetization and the R30 is ready. Otherwise, you’re going to lose a lot of money.

The outcome

After the Dark Days case, we revisited the workflow and now we rely on the numbers in midcore development as much as we do in hypercasual games. The only difference is that developing a prototype takes much longer.

We also stopped being scared to shut down projects when they underperform. You can try to fix them over and over again, but our experience suggests that if you can’t make it better in a month, you probably won’t be able to do it at all.

Sure, there are exceptions to any rule, but taking this time to make several more prototypes makes way more sense than chasing after an idea based on intuition.