The project that made us rethink the entire midcore development workflow
Overmind came up with the idea for the Dark Days game in 2018. Back then, I wasn’t a producer at AZUR GAMES yet. In fact, I was taking my first steps as a CTO on the project. We had an experienced development team confident in their abilities, which was our main advantage in negotiations with the publisher. As a result, they invested in the development of the game.
At that time, top-down survival games were the talk of the town, and we knew we needed to make something distinctively different from our competitors. That’s when we decided to make a third-person survival game. It took us a year and $1 million to develop. When we looked at the metrics after deploying the first version of the game, we immediately realized we were moving in the wrong direction this whole time.
We gave the game a second chance, completely redesigned the first hours of gameplay, reworked the mechanics, added a tutorial, but ended up rethinking the entire workflow for midcore in the end.
Let’s not get ahead of ourselves though.
Early stages of development
Overmind had a lot of experience in PvP games and had a firm grasp on the best ways to monetize them. This led us to adding a substantial layer of PvP global strategy to the original idea: users could see other players’ bases on the map, raid them and monitor their state in real time.
We didn’t check whether the audience likes this approach, or whether there’s an audience for something like this at all. We came up with ideas based solely on our extensive experience in the industry, never leaving any space to test them.
The development was going according to plan and AZUR GAMES wasn’t involved in the process in any way. In a year’s time, we managed to make the exact game we imagined when we started the journey. Here’s a small review of the alpha version in Russian:
We released the game on Android first and started monitoring the metrics. That was the moment when our confidence in the game’s success and ourselves started rapidly dwindling down. Seeing that 12% retention on Day 1 (R1) felt like jumping into an ice bath.
AZUR GAMES co-founder Dmitry Yaminsky said: “We spent a million dollars and an entire year on development and got less than half of the 35% retention rate we expected to see. The idea of abandoning the project started floating around. However, everyone involved loved the game dearly, there was hope that it could still be fixed.
Besides, AZUR GAMES had a lot of experience in working with midcore games. It made sense for the company to take the project in for revision, and a part of the original team joined us to help. We came up with a new roadmap, extended the deadline by almost a year, and increased the budget by $600,000.”
Plot twist: Let’s turn it into a shooter
The game got a new producer and a new team of game designers. Their first order of business was pinpointing the problems with R1 and working to fix them:
- The game looked too dark and had underdeveloped graphics.
- Players were leaving really early on into the game.
- The battles weren’t dynamic enough.
The development kicked into high gear again — we reworked the visuals and designed a tutorial. AZUR GAMES already had plenty of experience in session-based shooters which allowed us to implement the appropriate game mechanics right away. Now players had to aim instead of just picking a target to attack. We spent a lot of time adding the so-called filling — we made recoil, shooting and hitting the target feel really satisfying in order to get more players hooked.
We also completely removed PvP interactions from the global map. The idea sounded good on paper, but it turned into a problem after the release: new players were getting raided by experienced users right off the bat, and it was uncomfortable enough to scare off a lot of people. Instead, we added raidable camps to the global map, but now they belonged to bots, not real players.
Metrics started to actually get better with every update, albeit slowly. As a result, R1 reached 20%. So, it took us almost 4 months to double the retention rate. The question of whether the game should be shut down went on the back burner — sure, 20% was still far from ideal, but the dynamics were banging!
In hindsight, we should’ve shut the game down. But back then, with that kind of positive growth, it seemed like we were going to have a hit on our hands in a year.
One more year of development
That boost in metrics made the whole team regain their faith in the project. We launched another year of iterations and tested yet another few dozens of ideas. All of them were aimed at deepening the existing gameplay. Basically, we were building on the success we already had:
- Added new opponents, locations, weapons.
- Perfected the filling for shooter mechanics — namely, recoil, VFX, and camera behavior.
- Added arcade mechanics like dodging and shields.
- Changed the tutorial three times.
- Added a mech to the beginning of the game. Players could get in it and shoot mutants.
- Put “beacons of interest” on the starting location — non-functional content like broken vehicles for future reference.
- Added the ability to play offline.
This was enough to make the game pay for itself, but R1 never went past the 25% mark.
I happened to become a producer on the project around the same time. Now I had to decide what to do with it next. On one hand, we already produced a lot of content for the project, it was self-sustaining and had an established audience. On the other hand, we had low retention rates.
I decided we should shut down the project. However, it wouldn’t hurt to twist it up one last time before it goes and make another low-cost gameplay update that doesn’t require altering the existing graphics or code.
Last chance
The idea was that we could bring more players in by adding a storyline and challenges. We allocated 3 months to execute this stage.
We came up with a story, added friendly NPCs, dialogues, tasks and location markers. For the challenges, a new location was introduced — a bunker full of arenas, and players could get a reward for beating them all. They had to manage to avoid damage in a small room and start the generator that attracted hordes of monsters. Dealing with enemy waves when you had weak weapons was difficult, but you had to kill everyone in order to enter the next room.
We deployed it and started eyeing R1. It reached the highest point in the project’s history, but a miracle still didn’t happen — a several percent increase wasn’t going to change anything.
We’ve been coming up with ideas non-stop for over two years, shaped the game into what we wanted it to be, tested a lot of major updates, doubled the retention rate, and still didn’t achieve the desired result.
No one could figure out why whatever update we implemented had little to no impact on the metrics. Maybe we should’ve gone with a different setting or style right from the start, but testing this theory would’ve been too expensive by that point — we had an almost finished game with a whole bunch of content on our hands.
It became clear that the project couldn’t be saved and we shut it down.
Lessons learned
We started reflecting on the things we could’ve done better as soon as the project shut down. For instance, we’ve never had problems like that with hypercasual games because everything there is based on numbers and testing. Even if the project doesn’t become a hit, we close it without regret and don’t waste more than a few weeks developing a prototype.
We took a different path with Dark Days, and it didn’t pay off.
Mistake #1. We didn’t run any additional tests for the idea before we started development. We didn’t have doctored screenshots, didn’t test the visuals or the setting and just decided that third-person view would work for this genre. In other words, we largely relied on intuition and experience rather than serious analysis.
Mistake #2. We never made a prototype to test R1. The game was almost done, and we still didn’t know how the players would react to it on day one.
Mistake #3. We spent a lot of time and effort on high-level content during the first year. Regardless of how good it was, we were just wasting time — it doesn’t matter if our game designers made a perfect powerful weapon that becomes available on day 10 if there are no players to see it.
Mistake #4. Ideas that were supposed to fix the retention rate situation took too much time and resources to implement.
Mistake #5. We became so attached to the project that instead of shutting it down, we kept giving it new chances and testing more ideas.
Sure, we doubled the retention rate in the end, but essentially we just got an improved version of a bad product. If the project’s initial R1 was at least 30% and we spent the same amount of energy on updating it, it would’ve become a hit. But instead of developing that, we spent time on something that was doomed to fail from the very start if we really look at the numbers.