The founders of Rockbite Games, Avetis Zakharyan and Gevorg Kopalyan, shared their success story with App2Top.
Avetis Zakharyan and Gevorg Kopalyan
Not long ago, our studio Rockbite Games was on the brink of closure after more than 10 years of creating independent games. The money had literally run out, with a huge burn rate, and a portfolio of dozens of games.
But now, everything is different. We have Idle Outpost: 8.5+ million installs, the highest profit among competitors in its niche, and active scaling. It’s also the only new title to make it into the top 10 grossing idlers in a year.
If it weren't for a series of typical startup mistakes and certain fears, we might have succeeded earlier. Especially since we already had one successful project, but the profit from it went astray. We believe that this experience can be useful to other studios even today. This is not a guide or recommendation, just our story without unnecessary digressions, where everyone can find what might be useful to them.
The First Startup, First Success, and First Mistakes
In 2010, Avetis Zakharyan and I, Gevorg Kopalyan, quit our jobs to pursue our dream — making games. We were both programmers, pooled $2,000 each, bought a couple of desks, computers, hired two more people, and started from scratch.
Over time, we made several dozen games, at some point even lost count, around 50. The first ones were of terrible quality, but back then, the market was just emerging, and it was the norm. We started earning our first money, hired a couple more people, moved from remote work to the cheapest office in the world, as befits a startup.
Gradually, we improved in quality and eventually created the idler Deep Town, which still features, for example, in Google Play’s Editors’ Choice. Development took nine months, and honestly, by the end of it, the money had started to run out. But the game ended up being successful, we survived, and the project earned over $5 million.
Deep Town
It could be the end of the story, right? Dozens of attempts, then a successful project, and a decent paycheck. If only.
Then came the typical startup mistakes.
In our excitement, we got a big office, ten times larger than the previous one, made a beautiful renovation. We even looked at photos of giant industry offices to make it as stylish. Now, of course, we realize we should have been making more (and better) new games, not an office with expensive renovations.
But we didn’t forget about games, either, creating a hardcore title Sandship about building a factory, delivery, and resource processing. It wasn’t like typical mobile games – we literally tried too hard to bring the PC gaming experience, and the game became too complicated and over-engineered. We got caught up in creating a game for ourselves — hardcore gamers since childhood — and temporarily forgot about the players. As a result, a huge CPI of $10, although we didn’t even understand its importance at the time. The game was good — what else was needed?
Sandship
By a stroke of luck, Sandship still played an important role later (we’ll return to this), but at that time, our money started running out again.
At some point, we were even buying traffic for more than we earned from it and went into debt. All this with a huge burn rate (about 25 people), maintaining an office and lacking sufficient expertise in marketing and analytics because we simply didn’t have benchmarks and big data.
The company only had a couple of months left, and it became evident that something was missing, despite having quality projects and all the love for developing games.
New Fears and Hopes — Seeking a Publisher
At that moment, we were making another idler — Metropolis — and began considering publishing. Honestly, we didn’t really want to.
Firstly, we thought they’d just give us money, and we’d have to get out on our own. But we understood that just money wouldn’t save us in that situation. We envisioned this scenario: we get funds, can’t break even, and just "give away" the company we’d spent over ten years on to a greedy corporation.
Secondly, we worried that we might immediately lose control and become entirely dependent on decision-making. Some employees feared that the publisher would insist on layoffs to replace their functions with its departments.
Thirdly, we were concerned about the money. We thought that in case of success, we’d give all the profit to the publisher and earn less than when we worked independently (spoiler: no).
We were convinced it would all go badly, but continued to meet people in this area.
We met Evgeny Maurus, the founder of AppQuantum, and here we return to Sandship — it turned out he was a fan of the game. It was very beautiful and very hardcore, but didn’t bring much money. We met in Dubai, and he had suggestions on what we could try, because he was impressed by the game’s level of detail. So, it wasn’t just about money, but help on all fronts.
Again, a mistake: we went to the other extreme and became too optimistic. We thought, great, these guys will help us a bit, and in three months we’ll sort everything out. Naturally, things didn’t go that way.
We continued working on Metropolis and DeepTown. We made several iterations, but couldn’t meet target metrics, and expenses were astronomical. We exceeded agreed limits, spent much more of the publisher’s money than planned. Our expenses were sky-high, DeepTown brought some profit but not enough, and Metropolis was running at a loss. We started to think the publishing folks wouldn’t tolerate this much longer because the investment had already exceeded the initially agreed amount by several times. I don’t know if there are such cases in the industry.
In shock that we were still operational only due to investments, we (specifically Avetis) sat down for a new prototype because something needed to be done. We spent two weeks on the prototype, which became the future Idle Outpost. Of course, the idea didn’t come out of nowhere; it was also the result of a new workflow.
Choosing an Idea (and a Bit of ChatGPT)
By the time we started developing the future Idle Outpost, we discussed various projects extensively with AppQuantum, observing what worked in the market. Without established analytics and the ability to invest in marketing testing, we would have to rely on intuition and personal preferences (as we used to), which isn’t much like a business approach with a guaranteed result.
Step One. Analyzing diverse art and install costs, we realized the art that later appeared in Idle Outpost was easier to promote in the market. Additionally, for us personally, it was a reference to old-school, cozy flash games. We also hypothesized that among the adult audience, there was a slight nostalgia, which the visual style immediately tapped into, evoking a desire to play and immerse in that atmosphere.
Step Two. Finding interesting gameplay. Evgeny Maurus and other guys from the publisher constantly sent us interesting projects that were performing well in the market. We had never played games this much before. Thanks to this experience, we saw how much had changed since the times of Deep Town.
In the end, we got hooked on two games we genuinely liked, couldn’t stop playing, but most importantly, we started understanding why we liked them and what to focus on (tutorials, balance, core loop, progression, types of content, etc.). We tried to remember the best features.
Step Three. Then it got interesting because we started brainstorming with ChatGPT, looking for a setting. Why not. We told it the situation and gameplay — what setting ideas do you have? It gave us dozens of options, mainly not very interesting. But one point was about survivors after a zombie apocalypse who trade various items. We liked it. It seemed so obvious — not just about survival but about how people form a community from scratch, trading essentials, luxury or leisure items, and of course, weaponry for battles against zombies.
In the end, we decided to combine all this, add features, and create an idler (since it's the genre we have the most expertise in, and we didn’t want to rely on luck and start from scratch again).
We created a unique game that was tested at every stage. Unlike Metropolis or Sandship — where we added tons of non-obvious Easter eggs just because we wanted to — this was already a scientific, meticulous approach, from choosing each hypothesis to implementing mechanics and polishing the look & feel.
Developing the Idea and Game-Changer for Idlers
Idlers are rapidly evolving gameplay-wise and expanding in terms of monetization. Features appear that weren’t around a couple of years ago — this offers immense room for experiments.
One of the genre’s game-changers is the trend for parallel progressions, gameplay, and mini-games interwoven with the primary mechanics.
They create good long-term retention because players constantly unlock something new, there’s a sense of exploration and understanding that the game is much deeper than it first seemed — prompting curiosity about what comes next.
We considered what mechanics to add to the idler. We watched a lot of post-apocalypse movies, featuring trade, crafting, survival, and battles. We literally added all this into the game, like the ability to go on loot runs and fight zombies as the main character. Loot not only brings in money to develop the main base on the core loop but also allows upgrading the character’s equipment to advance further and defeat stronger zombies, adding an RPG component.
We also added an arena where survivors fight each other. This, too, was linked to an update that gave one of the biggest boosts for all long-term retention metrics.
Idle Outpost
How We Got Players to Stay Longer
This is one of our favorite cases of how we made changes based on internal analytics and analysis of close competitors. We noticed that most players dropped out on the third level. At the same time, players who passed the level stayed in the game for the long haul.
The point is that after it, the opportunity to fight in the arena with other players appears, with the strength of both calculated by equipment (which can be found during the zombie raid and loot search — tying back to the mechanic intertwining). But no one knew in advance about this mechanic’s introduction, and it might have seemed like nothing new would follow.
Idle Outpost
It seemed logical to move the arena earlier, but the first three levels featured a well-tuned balance engaging players in core mechanics — we structured it using deconstruction from other successful projects.
So we decided to add a narrative in the first three levels to seed the idea that something is ahead. We added a plot, videos, small stories, and hints gradually leading to future adventures. Overall, this made the game more thorough from a player’s perspective.
Idle Outpost
In the beginning, we created a video where the main character Mason explains the game’s lore and reveals he is a survivor who just wants to trade. Then you meet a girl and move through the game together. By the end of the level, a zombie bites her, turning her into one of them. Mason cries, creating a whole drama leading to his newfound hatred for zombies and his desire to destroy them, needing increasingly better equipment.
Thus, the game evolves from trade to arena battles, loot searches, and zombie fights. This truly fixed the retention issue. Actually, no, not fixed: we were shocked by how much it helped.
- R1 increased by 17%
- R3 increased by 30%
- R7 increased by 30%
From this point, we could fully focus on monetization development.
Feedback and 400-Page GDDs for One Update
Picking one difference that sets this game apart from other idlers is challenging. It’s thousands of details that make up the final product. Everyone’s tired of hearing how competition and player demands have increased — it’s true, but it merely means approaching development and polishing more meticulously. You can’t find a magic bullet, saying you added a specific mechanic and the game flew off.
Everyone knows an idler should have a "healthy" economy, so the player understands how the entire cycle works. But setting such an economy is not a trivial task. If you accomplish it, you get a boost in metrics. Just sit and do it, but in practice, it comes down to enormous expertise that grows over time and constantly replenishes.
The story with monetization is the same; we constantly connected with the publishing guys and Evgeny, the founder of AppQuantum. I’d have an idea — call them anytime.
In return, I received multi-page documents with feedback from Evgeny. We tried to understand why certain monetization features weren’t working.
Below is an excerpt (roughly 3% of the overall text volume) from one of the feedback. Updates based on these advices helped increase ARPU by 20%:
"We need to work on balance — currently, players have no incentive to make in-game purchases, and this does not change throughout the gameplay. Looking at leading niche projects, their balance is much tighter, allowing progression without payments but offering many bonuses for those willing to buy.
Also, the chest purchase process should clearly demonstrate the drop chance and the maximum bonuses items can fall with. This simple adjustment will significantly enhance the player's understanding of value.
In our case, introducing mythical items and creating a complex crafting system for them, displaying recipes, showing that the profit will exponentially increase up to x15-20, not just 2-3 times as currently, is worthwhile. This also gives players satisfaction, as you can see and feel how profit from this grows. Clearly demonstrate to the player with an exclamation mark on the equipment at what level they should enhance the modifier for quick and comfortable progression.
You can tie it to inflation and say the game's situation worsens, inflation rises, and income falls, thus showing players that profit must be boosted at each level."
Our arena performance was also incorrect. Yes, it offered long-term retention, but we initially didn’t understand how matchmaking worked. It turned out to be a whole science, of which we lacked expertise.
For instance, we didn’t know that it’s unwise to throw everyone onto one server but rather create a competent system. When we divided players into small cohorts with some having lower strength, approximately equal strength, and stronger players, but not to the extent of being unbeatable. This seemingly simple update in the game’s 14th version demonstrated significant growth.
As a result, we started writing a lot of documentation ourselves. They turned into full-fledged books of 300-400 pages per major update. Each such "book" had dozens of sections: what we wanted to achieve, how, what changed, task list, task log, basically all possible questions.
I know very few, even among the largest studios, maintain something similar. So why bother? When we optimized workflow based on the feedback, we noticed our performance assumed a sinewave form. We understand something, start doing it well, then forget something, and go down. But now that we have all this documentation, and if someone asks me: "Why did we add this button? It seems bad here, doesn’t it?" We’ll go, find in the GDD when and why we added it and what results it produced: "This is a good button, please don’t remove it."
Easter Eggs and Guilty Pleasure Instead of a Conclusion
So, instead of a conclusion, something personal. We mentioned that our previous projects were overloaded with Easter eggs, details, and non-obvious elements. At some point, one could even visit a website, solve puzzles to receive a code, and enter it in the game to get an item. It’s all cool, but when the game’s balance, retention, etc., aren’t set, it’s better not to spread too thin.
But as developers who deeply love games, we have a certain weakness. For instance, if we want to add an Easter egg, we just sneak in at night and add it ourselves without anyone noticing. We can avoid distracting developers and keep our souls at peace.
These are small things too, but they influence engagement and long-term retention. Some unobvious mechanics, not directly impacting gameplay, go unnoticed for several hours of play. For example, zombies might be hiding in the woods and can be tapped with a finger to destroy them. This gives some money and is essentially a mini-game, though this mechanic isn’t advertised anywhere. A player who accidentally taps one and sees the pleasant animation and sound begins to understand how much deeper the game truly is.
Or, for example, at the start of the game, when the main character and his girlfriend (before she becomes a zombie) stand together, hearts appear above their heads. We read countless reviews from players who noticed this and thought it was accidental. They believed they saw something rare, but it was intended this way. Afterward, learning she turns into a zombie evokes additional emotional attachment.
Polishing games in such a way is our "weakness", and it coincidentally turned one of the most critical elements in the market. Raw projects that don’t create a sense of depth from the start almost never succeed anymore. We built this into our path from the very beginning. We truly pondered the studio’s mission, wanting to bring the joy of PC games to mobile devices.
Unfortunately, without the publisher’s expertise in marketing and balance, all these details would have gone unnoticed because we wouldn’t have been able to attract and engage such a large number of players. I'm not even mentioning how many attempts we made and exceeded all budget limits several times. But once we exchanged experiences and changed our approach, including collaborating with partners, everything turned upwards, even despite failures.
