With Idle Miner Tycoon constantly updated since it launched in 2016, Kolibri Games are averaging almost one update a week. Founder and CTO Oliver Löffler explains the challenges and advantages of this iterative approach to development…
Making a game is a long and difficult process. You spend years crafting the perfect product, you ship it and then you move on to the next project. But it doesn’t have to be like this: at Kolibri Games, we launched our first game after just eight weeks and we have been building on that foundation ever since with weekly updates based on community feedback. In order to keep up with this fast update cycle, we had to structure our entire company around quick iterations. Today, I’d like to tell you about the advantages and challenges of this iterative approach to development.
Ready for Take-off
It all started with an ambitious goal: in our last semester at uni, we decided to create a game from scratch in just two months. That’s eight weeks to come up with a concept, code everything, create all the required assets and plan our launch. A short time frame like this comes with some obvious limitations: we needed an MVP, something that we could get ready quickly and expand later depending on the metrics we’d get. On the upside, this fast launch also meant we would know immediately whether or not it made sense to keep developing our game, Idle Miner Tycoon. After all, we didn’t have any outside investors, so we had to pay for everything out of pocket. We even turned our shared flat into a makeshift office, something we tried to hide from our landlord by masquerading as a study group.
Fortunately, Idle Miner Tycoon ended up being very well-received: The original version of the game already reached great download figures and a Day 1 Retention rate of 75%, meaning that 75% of the people who installed our game opened it again the next day. The first step of our experiment was a success: after eight weeks, our game was out and generating positive feedback. The success of Idle Miner Tycoon allowed us to keep working on it and laid the foundation for our company. Soon, we were able to move into a real office. Today, more than 75 people work at Kolibri Games and we relocated to Berlin at the start of 2018.
Stage 2: Updates, Updates, Updates!
Producing a game quickly and then adding to it with weekly updates is kind of an unusual approach. In fact, it’s the opposite of what most people do: In traditional studios, you spend a lot of time working on a game before it launches, but once it ships the majority of that team is reassigned to new projects with only a few people left to take care of bug fixes, updates and possible expansions. At Kolibri Games, however, everyone is focused on one goal: making Idle Miner Tycoon better. The reasoning behind this approach is simple: we are making this game for our players, not for ourselves. That’s why we want to respond to their feedback quickly with frequent updates, which in turn generate new feedback from our players. This cycle allows us to keep improving our product to give our community exactly what they want.
Judging by the good reviews we get in the store, users clearly appreciate the fact that our game keeps changing and growing. We were initially worried what Apple’s and Google’s algorithms might disapprove of the number of updates we publish, but so far this has not been an issue. If anything, it seems that keeping our app highly active has improved our ranking, although there’s no way to know for sure what is going on behind the scenes.
In order to implement the changes our community asks for as quickly as possible, we had to structure our entire company around this weekly update schedule. It takes clear and strict organization, constant preparation and good teamwork to make sure our team members can thrive despite the amount of pressure we put on ourselves with these constant deadlines. Good project management is essential to prevent any roadblocks from slowing down development: to make sure our dev team can work as efficiently as possible during the weeklong sprints when they program the next update, our other departments prepare the required art assets, texts and design documents in advance, so everything is ready when we need it. Even within individual departments, we try to break down tasks as far as possible, so that you have one or two people working on a specific feature and the team around them is assisting with anything they might need. We switch these roles around frequently, but it’s important for everyone to know exactly what is expected of them at all times.
Open Heart Surgery
Of course, no matter how much time you spend preparing, there are risks involved in tweaking your game so frequently when it’s already on the market. However, you can minimize these risks by cleverly organizing your workflow around them. For instance, optimizing for speed because we need to get the next update ready for live also means we know how to quickly get it ready for testing. Even while our programmers are still working on the new version, we are already constantly testing it on our internal servers to check for bugs and errors. By providing immediate feedback to our dev team, we can ensure that the launch of the update goes as smoothly as possible. After all, we are pushing these updates to an audience of millions of players who expect continuous, uninterrupted service.
As an additional safeguard, we don’t push updates to our entire player base at once, but use staged rollouts to only deliver them to one percent of our active players at first. At this point, our team keeps a close eye on reviews and bug reports: Players tend to respond quickly if they encounter grave problems, like freezes or loading screen crashes on certain devices, at which point our stat tracking sounds the alarm. If there is no negative feedback and our metrics show we’re in the clear, we roll out the update to another five percent of our user base, then 20% and finally 100%. This way, our team always has the option to slam on the brakes if we encounter a major bug.
Some features are too big to be implemented in just one week, but that doesn’t mean they are too big to be implemented at all. Again, the key is to break them down into smaller chunks. We often spend multiple weeks and multiple updates ironing out the technical details for new features before finally adding them. Essentially, we follow the same approach with gameplay changes and major content updates that we took with the game itself: getting their smallest possible version out as soon as possible before building on that foundation with future updates. And even if a particular update doesn’t introduce any new features, we make sure to leave behind a few hints so our players know what we are working on. “Coming soon” signs and similar teasers create a sense of anticipation and discovery — there’s always something new to see when players log in — which helps keep the all-important retention rate high.
At the same time, we are still refining our approach to style of development. One of our current projects is to build the necessary framework to allow us to do A/B testing in-game. In the future, we will be able to show small groups of live users different gameplay ideas, art assets or store deals to see which of them works best. A/B testing has already proven to be a useful tool in the past. Using it to choose our game icon and store screenshots has led to noticeable rise in downloads. By continuing to use this method to improve our games, we continue to improve player satisfaction and thus, ultimately, increase the revenue of our games.
And everything we learn right now will help us make our second game, Idle Factory Tycoon, even better. Naturally, we stuck to the same philosophy while developing it: get the game ready in two months and keep improving it with weekly updates. Why change a winning formula?