At Kolibri Games, we follow a lean approach to game development. What does that look like in practice? In Part 1, I explained that we develop a minimum viable product (MVP), test it on the market and keep on improving it if we see that players love it. We use the code architecture MVC (Model View Controller) to separate our business logic from our game engine, allowing us to easily iterate on existing code and test the game in the process.
So, we have created a successful MVP that players love — what now? Now the real work begins…
Saying “YES”
Although our MVP approach requires us to say “NO” to a lot of cool ideas at first, we are eventually able to say “YES” to most of them. Idle Miner Tycoon started with only a little more than the core mechanics, but developing the game as a service, we eventually added IAPs and localization, social features and LiveOps events.
Being player-centric means that we develop our games hand in hand with our community: we connect to players through a variety of channels and integrate their feedback and ideas very fast. Our players love the fact that they can voice feedback, and already see it implemented it the game the next week.
Our continuous update policy prescribes one update per development sprint, which is one week long. In that one week, we do all the developing, planning and testing. To be able to follow this schedule, game design and artists have to work ahead of the development sprint and plan new features about a week in advance, so that the developers are not held up by anything. In addition, QA can start testing already early on in the sprint if some sub-parts of features are done, to avoid extended test sessions at the end that could prolong a successful release.
After that sprint has been finished, we execute a staged rollout, which works really well on Google Play. First, one percent of our players get the new update. For two days we check for bugs and problems with the game that the new feature might have introduced. On day three, we look at more user feedback and store reviews and on day four we send it into full release on both, iOS and Android.
Update, after update, after update, after update…
On the technical side, continuous integration helps us maintain this weekly update schedule. The workflow here looks as follows: During the sprint, developers produce a feature and test it in the Unity editor. At some point, the feature is implemented and the developer pushes the changes. Later our CI platform Jenkins gets notified and creates a build that can be downloaded on test devices. Our QA can then pick up a phone or tablet, download the latest build and see if the feature works and is fun to play.
Continuous Integration helps us maintain a weekly update schedule.
Our weekly update schedule puts a lot of stress on our QA team: we generate a never-ending stream of features for them to test. To make their life a little easier, developers already start testing certain aspects of the feature we are introducing. How? Simply by playing the game. That, on the other hand, means that playable versions of the feature need to be accessible as fast as possible.
To facilitate and speed up this whole process, we generate cheat savegames. While cheating in games is usually considered to be a bad thing, it is actually super helpful for our testing process. The whole state of our game is always serialized in a JSON file that can simply be loaded to play the current state of the game. However, because our games contain a large number of features that take a long time to play through, we decided to integrate a save game button that is only available in debug builds, allowing a tester skip to any point in the game any time.
Creating cheats takes a bit of custom code, but with our cheat engine SRDebugger we have created cheats for almost every feature in our game, leaving us with around 100 of them.
So, is it worth it?
To some, this might sound as if, like Sisyphus, we are doing the same thing over and over again, sprint by sprint trying to improve a product that will never be perfect. We don’t see it that black and white. Instead, we see our games as a service that we continuously provide to our players.
For us, player-centricity is a benchmark that we work by, starting even before the official release and carrying on forever. We want our games to be as accessible as possible — we want them to be played by everyone, across nations, and generations. For the start, that means no complicated tutorials that could act as an entry barrier. We want everyone to come back the next day. And for later, it means that we have to structure our work and development processes around this approach. Building an MVP and continuously improving it, based on player feedback is by all means not an easy task — especially not from a technical standpoint.
At Kolibri Games, we have found a way to make it work, allowing us to keep our promise to over 70 million players week by week, sprint by sprint.