- After almost a decade of making games solo Rockbite Games were on the cusp of having to shut its doors
- The team were reluctant to work with a publisher but joining up with AppQuantum gave the team the support they needed to find renewed success
Rockbite Games was founded in 2016 as an indie games company by Avetis Zakharyan [pictured left] and Gevorg Kopalyan [pictured right]. The studio is responsible for games such as Sandship, Idle Outpost and DeepTown Idle Mining Factory, which has over 10 million downloads.
However, it hasn’t always been easy. Rockbite Games had early success with DeepTown, but like many start-ups, they faced a series of mistakes that nearly led to the studio’s closure. Despite initial reluctance, partnering with a publishing company helped Rockbite bounce back and return stronger than ever.
In this guest post, the company’s founders share the story of the studio’s journey.
Not too long ago, we were on the brink of closing Rockbite Games after more than a decade of making games on our own. We were literally out of cash, burning through funds at an alarming rate, and had dozens of games in our portfolio.
Fast-forward to now, and we’ve got Idle Outpost with over 7.5 million installs and the highest net profit among the competitors on the market. The project is scaling like crazy.
If we hadn’t made some typical startup mistakes and faced a few fears, we might have hit it big sooner. We had one successful project before, but the profits from that went in the wrong direction. We’re sure other studios can learn from our experience.
This isn’t a guide or a set of recommendations; it’s just our story, straight up, with no unnecessary fluff. Everyone can take away what they find useful.
First startup, first success, and first mistakes
Back in 2010, the two of us (as in studio founders), Avetis Zakharyan and Gevorg Kopalyan, quit our jobs to chase our dream of making games. We were both programmers, pooled together $4000, bought some desks and computers, hired two more people, and started from scratch.
We started making some money, hired a few more folks, and moved from remote work to the cheapest office we could find – classic startup style.
Over the years, we made several dozen games – at some point, we stopped counting after about 50. Looking back, we know those early games were as far from great as it gets, but the market was just starting out, so it all worked out.
We started making some money, hired a few more folks, and moved from remote work to the cheapest office we could find – classic startup style.
Our games were improving bit by bit, and eventually, we hit it big with our idler game, Deep Town. It’s still on the Editors’ Choice list on Google Play.
Development took nine months, and honestly, by the end of it, we were almost out of money. But the game was a hit; we made it through, and the project earned over $5 million.
Maybe we could end the story here? We tried many different things and eventually got a successful project and a fat check. I wish.
Then came the typical startup mistakes.
To celebrate, we moved into a huge office – 10 times bigger than the old one – and did a fancy renovation. We even looked at photos of industry giants’ offices to make ours just as stylish. In hindsight, we should’ve focused on creating more (and better) games, not on an expensive office makeover.
We were making a game for ourselves – hardcore gamers since childhood – and forgot about the players. The result? A huge CPI of $10.
But we didn’t forget about games entirely. We created Sandship, a hardcore game about building a factory, delivering, and processing resources. It wasn’t your typical mobile game – we aimed to capture the PC gaming experience, and it ended up being too complex and over-engineered.
We were making a game for ourselves – hardcore gamers since childhood – and forgot about the players. The result? A huge CPI of $10, though we didn’t even realise how important that was at the time. The game was good – what more did we need?
As luck would have it, Sandship would still play an important role later, but at that point, we were running out of money again.
We even ended up spending more on traffic than we earned from it, sinking into debt. Our burn rate was huge (about 25 people), office maintenance was expensive, and we lacked expertise in marketing and analytics because we didn’t have benchmarks or big data.
With just a couple of months of runway left, it became clear that something was missing, despite our quality projects and all the passion we had for game development.
New fears and hopes: Searching for a publisher
At this point, we were working on another Metropolis idler and started considering getting a publisher. Honestly, we really didn’t want to.
First off, we thought they’d just give us money, and we’d have to figure the rest out ourselves. But we knew money alone wouldn’t save us. I kept picturing this scenario: we get the cash, we can’t break even, and we end up handing over our 10+ years of hard work to some “greedy corporation.”
Second, we worried about losing control and becoming totally dependent on their decisions. Some of our team feared the publisher would push for layoffs to replace our roles with their departments.
Third, there was the money issue. We thought that if we succeeded, we’d give all the profits to the publisher and earn less than if we worked alone (spoiler: we were wrong).
We were straight-up convinced it would all go south, but we kept having meetings with representatives.
The big break
We met AppQuantum founder Evgeny Maurus, and this is where Sandship comes back into play. It turns out he was a fan of it. It’s a very beautiful and very hardcore game, but it didn’t make much money.
We started to think the publishers wouldn’t put up with this, given the investment was already way higher than agreed.
We met in Dubai, and he had some ideas on what we could try because he was impressed by the deep level of development and attention to detail. He offered help not just with money but with everything else as well.
Another mistake: we jumped to the other extreme and got too optimistic. We thought, “That’s it, these guys will help us a bit, and we’ll sort everything out in three months.” Naturally, that didn’t happen.
We kept working on Metropolis and DeepTown. We made several iterations but couldn’t hit our target metrics, and costs were through the roof. We went over budget and spent way more of the publisher’s money than planned.
Our expenses were sky-high, DeepTown brought in a bit of profit but not enough, and Metropolis was in the red. We started to think the publishers wouldn’t put up with this, given the investment was already way higher than agreed. I’m not even sure the industry has seen a case like ours before.
Shocked that we were still afloat, only thanks to investments, Avetis sat down to create a new prototype because something had to be done. He spent two weeks working on it, and it became Idle Outpost. The idea didn’t just pop up; it was the result of a new workflow.
Choosing an idea (and a little ChatGPT)
By the time we started developing Idle Outpost, we had a lot of discussions with AppQuantum about various projects and what worked in the market.
Without good analytics and the ability to invest in marketing tests, we would’ve been moving on intuition and personal preferences like we used to, which isn’t exactly a business approach with guaranteed results.
Step one: After analysing various art styles and the cost of installs, we realised the artwork we later made for Idle Outpost would be easier to market. For us, it also had a nostalgic feel reminiscent of old flash games. We figured there might be a bit of nostalgia among older audiences, and the visuals would catch their eye and make them want to play, chasing that familiar vibe.
Step two: Find interesting gameplay. Evgeny Maurus and the publisher team sent us interesting high performers from the current market. We played these games extensively and saw how much had changed since Deep Town.
As a result, we got really hooked on two of those games and couldn’t stop playing them. More importantly, we began to understand why we liked them and what to focus on (tutorials, balance, core loop, progression, content types, etc.). We tried to remember everything worth remembering.
Step three: That’s where the fun started. We brainstormed with Chat GPT to find the setting. Why not? We looped it in on the details we had and asked for setting ideas. It came up with dozens of options, mostly uninteresting.
But one was about survivors of a zombie apocalypse trading various items. I liked it. It seemed obvious – people forming a community from scratch, trading necessities, then luxuries, and, of course, weapons to fight zombies.
Ultimately, we decided to combine everything, add features, and make an idle game (since we had the most expertise in this genre and didn’t want to rely on luck).
The result was a unique game tested at every stage. Unlike Metropolis or Sandship, where we added tons of Easter eggs just because we wanted to, this was a scientific, meticulous approach from choosing hypotheses to implementing mechanics and polishing the look & feel.
Developing the idea and idler game-changers
Idlers are evolving rapidly in gameplay and growing in monetisation. New mechanics are popping up that didn’t exist a couple of years ago, offering a huge scope for playing with our ideas.
One game-changer for the genre is the trend towards parallel progressions, gameplay, and mini-games intertwined with the main mechanics.
These create good long-term retention because players are constantly discovering something new. There’s a sense of exploration and depth that keeps players hooked, wondering what will happen next.
We explored mechanics to add to our idle game. We watched a lot of post-apocalyptic movies incorporating trading, crafting, survival, and battles.
We explored mechanics to add to our idle game. We watched a lot of post-apocalyptic movies incorporating trading, crafting, survival, and battles.
All these elements made it into the game, such as the main character searching for loot and fighting zombies. Loot not only brings money for base development but also allows equipment upgrades to defeat stronger zombies, adding an RPG component.
We also added an arena where survivors fight each other. This was part of an update that gave one of the biggest boosts to our long-term retention metrics.
Making the players stick around for a long time
This is one of our favourite cases. We updated our internal analytics and close competitor analysis and noticed most players dropped off at level three. However, those who completed the level stayed for a long time.
The reason? After level three, players could fight in the arena with others based on their equipment strength (found during zombie raids and looting, that’s where our mechanics intertwine). But no one knew this mechanic was coming, giving the impression that nothing new would happen.
You might say, “That’s easy, just move the arena earlier.” Trust me, we would do the same thing if the first three levels didn’t have a finely-tuned balance introducing core mechanics, which we built by deconstructing other successful projects.
Instead, we decided to weave a narrative into the first three levels to hint that more exciting things were coming. We added a storyline, cutscenes, short stories, and subtle hints to lead players toward future adventures. Overall, this made the game feel richer and more engaging from the player’s perspective.
At the start, a cutscene shows the main character, Mason, explaining the game’s lore, saying he just wants to trade. Then, you meet a girl, and you progress through the game together.
At the end of the level, she gets bitten by a zombie and turns into one. Mason cries, leading to a drama in which he now hates zombies and seeks to destroy them, needing the best equipment.
This transformation from trading to battling in the arena, searching for loot, and fighting zombies significantly improved retention. Actually, let me rephrase: we were shocked by how much it helped.
This success allowed us to fully focus on monetisation development.
Feedback and 400-page GDDs every major update
It’s hard to pinpoint one difference between this game and other idlers. Thousands of elements make up the final product.
Everyone’s already sick of hearing about competition and growing player demands. Even though all of it is true, it only means we need to be meticulous in development and polishing. There’s no magic pill to add a mechanic and have the game take off.
Everyone knows an idle game must have a healthy economy so players understand the whole cycle. Setting up such an economy is no longer trivial. If you do it right, metrics improve.
We constantly called the publisher team and AppQuantum founder. I’d get an idea and call them anytime.
At the end of the day, you just sit down and do it, but on the backend, it takes a huge amount of expertise accumulated over time and continuously updated.
The same goes for monetisation. We constantly called the publisher team and AppQuantum founder. I’d get an idea and call them anytime.
In return, I received multi-page feedback documents from Evgeny. We tried to figure out why certain monetisation features didn’t work.
Here’s an excerpt (about 3% of the total text) from one of his documents. Updates based on these tips helped increase ARPU by 20%:
“We need to work with balance – players have no incentive to make purchases, and this doesn’t change throughout the game. Leading projects in the niche have tighter balance, allowing progression without payments but giving bonuses to those who buy.
The chest purchasing process should clearly show drop chances and the maximum value of items. This simple change greatly improves the clarity of value for players.
Introduce mythical items and a complex crafting system, showing recipes and exponential profit growth (x15-20, not just 2-3 times like it does now). This gives players satisfaction as they see and feel their profit grow. We should mark equipment with exclamation signs to clearly demonstrate to players when to upgrade modifiers for quick and comfortable progression.
We can tie this to game world inflation, showing that income is falling and prices grow as the world falls apart, and players need to boost profits at each level.”
We also initially got the arena wrong. Yes, it provided long-term retention, but we didn’t understand matchmaking. It turned out to be a science we had no expertise in.
We started writing extensive documentation. Each major update turned into 300-400-page books detailing goals, changes, task lists, logs – everything.
For one, we didn’t know not to throw everyone on one server but to build a competent system. We divided players into small cohorts with a mix of weaker, equal, and stronger players, but not so much stronger that they were unbeatable. This seemingly simple update in the 14th version showed excellent improvement.
As a result, we started writing extensive documentation. Each major update turned into 300-400-page books detailing goals, changes, task lists, logs – everything.
I know that very few studios, even the largest, do this. Why is it necessary for us, then? Optimising our workflow based on feedback showed our performance was like a sinusoid. We’d do well, then forget something and decline.
Now, with all this documentation, if someone asks, “Why did we add this button? Doesn’t it look bad here?” we can find when and why it was added, the result, and say: “The button’s nice, don’t remove it, please.”
Final thoughts: Easter eggs and guilty pleasures
To wrap it up, a little personal note. Our past projects were overloaded with Easter eggs, details, and non-obvious things. At one point, you could go to a website, solve puzzles, get a code, and enter it into the game for an item. That’s great and all, but when the game lacks balance and retention, it’s better not to overdo it.
But since we’re developers and love games, we’ve got some weaknesses. When we want to add an Easter egg, we sneak in at night and add it ourselves when no one’s watching. This way, we don’t distract the team, and we get some peace of mind.
These little things also boost engagement and long-term retention. Some hidden mechanics don’t directly affect gameplay but are discovered after several hours of play.
Polishing games like this is our speciality, and, coincidentally, it’s now crucial in the market.
For example, zombies might be hiding in the forest and can be destroyed by tapping on them. This gives players some money and acts as a mini-game, even though it’s not explained anywhere. When a player accidentally taps a zombie and sees the cool animation and sound, they realise just how deep the game really is.
Or, at the beginning of the game, when the main character and his girlfriend (before she becomes a zombie) are together, hearts appear above their heads. We’ve read tons of feedback from players who noticed this and thought it was rare.
It might have seemed like an accident to them, but that was the plan. And when the girl becomes a zombie, it adds emotional attachment.
Polishing games like this is our speciality, and, coincidentally, it’s now crucial in the market. Raw projects without a sense of depth from the start rarely take off anymore.
We’ve always thought about the studio’s mission: bringing the thrill of PC games to mobile. So, we came prepared for it.
Unfortunately, without the publisher’s expertise in marketing and balance, all these details would have gone unnoticed because we just wouldn’t have been able to attract and engage so many players.
I’m not even going to get into how many attempts we made and how many times we blew past the budget again. But once we started sharing experiences and changing our approach, including working with partners, everything started looking up, even with all the setbacks.
Edited by Paige Cook
