Kolibri Games on rapid development for idle games

[Music] as I said I'm here to talk a little bit about how we actually build idle games but then also what we do with them after their life in the market and Mike talked a little bit about his definition of life ops and he had this list of what life ups is not for him and actually I think we take all of those boxes because of that for us is actually life works anyway so we are Calibri games we do idle games and daniel stammered co co and one of the cofounders and we have those two games which some of you might know idle monitor-kun and i'll factory tycoon an american was our first game we released it in july 2016 after two

months of initial development idle factory the kunais our newer game that we just launched last year and to Gharib both games have more than 60 million downloads and more than 10 million monthly active users so what is our approach actually and before I want to go deeper into how we build things I want to talk a little bit about the game industry as a business and as you all know gaming the gaming industry is a hit driven business what does this mean this means that many many big projects with big hopes will fail in the end because the games will not work out and people will not play them or if they play them not pay for them and this is a huge risk for the industry because as you can imagine if you spend millions into building a game and it does not work out this can put out studios out of business so for us we figured out we should learn as fast as possible if the thing we're doing if the game that we're building it's actually something that players

want to play instead of investing a lot of time and energy into it and then finding that out maybe too late so that's why we try to find out as fast as possible if we should continue or not now how do we actually do that this is the example of I will take you in the second game and the very first iteration consists of basically text boxes so we think about game mechanics or games are very mechanic terrific so we try to build that into boxes and then we actually play the game and if they is not fun at all in that session if we cannot imagine the game to be good or to become good we will stop there and the stations may be like one week of development or so if it's fun we go on and build some basic graphics because for every game of course you need kind of like a setting to make it useful we play it again if it works with your on iterate on mechanics iterate on graphics and then in the end we finalize that you exit graphics however this is all within

the first eight weeks so when I talk about finalizing UX mechanics it doesn't mean to polish them with data and everything but just finalize them to the stage where we think it's good enough to release it to the to some players and learn if the game itself has some value in it or not and while this process seems very obvious and looks kind of easy for us it was really really hard to actually follow through with it because as you know when you build a game you have so many ideas about what you want to build in the game and there are so many things where you are very sure that if you implement them into the game the game will be better and yes you might be true the game would probably be better if you implement multiplayer if you implement Facebook if you implement more levels but it's super important to remember that the goal here is not to build a very good game but the goal here is to build a game with which you can test if you should actually spend the time to make the game better so it's really really important in the end to say no to a lot of things on the example

of idle monitor-kun saying no meant for example not having cloud safe so we have players in the beginning with the early version that lost their safe game we had players that left the game because we hadn't didn't have any social features and also there was no localization the game was only in English and we didn't even build in the localization framework because this would have cost us like a few days which are not necessary to test if the game is worth investing further into it or not we had no inner purchases and this was actually something where people out of the industry told the SEC hey guys you will burn through your first cohorts you will not earn any money with them but we are totally ok with that we do get the first all notes to earn money with them but we get the first owners to validate if the game works or not and then of course if the game works there's still enough time there will be many many millions of players later on that we could monetize so you should not not be scared of burning through players this also applies to no long-term

motivation so the game was basically finished after one or two days for hardcore players and then they of course quit the game and deleted it and probably never downloaded the game again but that's fine because in the end it's not about building a great game in that stage but it's about building a great core gameplay and not building anything that's not related to the core gameplay now of course if you have to the MVP you need to kind of need to somehow measure it if you want to spend more energy build a proper team or if you rather want to kill it and try something new so for us we had two mechanics to measure it one Organic was on the marketing side if we get any organic downloads and to see if there's like an organic appeal on the market if players actually look for that kind of game and the second important thing for us was the day 1 retention meaning new players actually come back on the second day or do they forget about the game or not and we've got both games we got lucky and got a

day 1 retention of 75% which for us meant ok this game is something even though we had no daily rewards no push notifications so there was no extrinsic motivation for players to come back but they just came back on their own so we knew this core gameplay actually works there is something in the game and now we can start building a proper game a big game with in-app purchases and with levels and so on onto it when we do this process the first important things to have a small team so for us it's basically one product manager who's responsible for the team one game designer one one artisan one developer and the reason why the team is so small is because they are agile if you have a small team they will not discuss everything for hours but they will just go through with everything you need to cover of course every core area of the game for our games its development art and game design fingers is true for most of the games out there but then you have just one person for each area and this person should just go

through with it and not discuss everything for weeks and try things out because if you do that and in the end you will not be able to test the game after eight weeks but then it will take you years or at least half a year or so to validate your idea second step Minimum Viable Product I talked about it what the Minimum Viable Product means for us but it's basically a playable version that you can then test and play internally then everybody plays the game we go on to polish it to fix critical bugs and after those eight weeks we release the game and there it's important for us to reach a broad number of players so what we did with Idol Factory second was to release it on Google Play with another developer account and the reason for the other developer account was first to not to not bias our organic downloads because of idle monitor-kun because of course if you release with the first with the same developer account you will get downloads because players know your first game and then they will just see it in the list and the second reason was because of

course idle monitor combined now is a big game it's very successful and our players of idle matter couldn't have a certain yeah they want they expect some kind of game and idle factory after eight weeks of course that's not that kind of game so we wanted to release it with another account to not disappoint players but to get actual market feedback and then after us four weeks we got our retention numbers we saw you're getting downloads and we knew ok this game has the potential to become big and then that's when actually scaling starts and then that's when life works or proper game development however you want to call it starts for us we do this with weekly updates this is something that this rather uncommon in the industry I think it is super important to be close to the players and to reduce the time from feature development to market because we don't want to work on something big for multiple months and then release it and then see if it works

out or not so here we apply the same thinking of the MVP to every update so see like and to be able to react to each update very fast if it's not working out as we expected it with an American we had over 120 updates by now and for us this is the definition of games as a service for us a game is not finished when we release it but for us a game as a constant service that will never be finished as long as players play the game we continue improving it we continue doing life of events new feature development new game mechanics new monetization everything so if you look at the game of mine released in July 2016 it was very very small compared to what it's no no it's like for like 20 times bigger in terms of features and this will also continue forever as long as there are players actually playing it to do one update per week um you need to be very focused on

pushing it out you cannot let a few days pass without actually delivering because then in the end it will be longer so for us each update is one sprint and one week of course like it happens in reality sometimes you're faster sometimes no slower then we will extend the sprint by a day or two or finish it earlier but in the end every sprint for us is a deliverer as a deliverable it we will push out to the market and this also helps the teams to really focus on building everything for the players and not building internal sprints that will never be released in full of parks because I think then if you have like for example an uptick update cycle of two months with sprint cycles of one week then the first few Sprint's will not be user oriented but they will be more like not polished half box and then in the end in the last few Sprint's you will have to catch up all of that so for us one sprinters one update one week

now if you want to do that there are a few things that need to be in place so first we need to decide about feature design early on so before the sprint starts games and art already talked about what should be in the sprint how how we should do this of course they will still continue in the sprint and assist the developers for smaller decisions but the core idea is there and now another very important concept that we implemented was to have QA testing the game while developers are still developing on the Sprint so for us it's not like we're developing for five days and then QA starts to test it but from the very first day QA starts to test everything that's there like on the first day they will start to create their test Maps then when the first push is done from the developer stable already tested continuously and with this we can ensure that there will not be this huge gap at the end of the sprint where QA tests find some bugs needs to go back to the dev team and the

dev team is already on the next sprint and then this will create a lot of chaos so for us the sprint and it's basically one smoke test that takes like an hour or so and if that goes well which is usually does because everything is tested continuously then we can release the sprint in the game now to be that fast I believe technology and continuous integration is really important to support the development process if you do like one update every three months it's not that big of a hassle to build the build send it to QA s push it to devices if you do it weekly I think you should really build some tag to have a rebuild every commit built and automatically pushed on to your devices otherwise there will be so much manual work and so many errors due to repeating the same thing again and again we do this by using Jenkins every built that every commit that is pushed to get will be built in Jenkins and then will automatically be pushed to all of our test devices so that QA s like it

usually takes like 10 to 15 minutes for one built so 15 minutes after a developer changed something in the game some somebody out of QA will have it on the device and will be able to test it already and then another step that's also important for us is to not only automate the internal process but also automate the upload and the deployment to Google Play and Apple because we had many issues when doing this manually and it's a lot broke a lot of fast you do wrong things you upload the wrong apk this kind of stuff happens as you know so for us it was important to automate it and then put it into staged rollout now staged rollout is a concept that works very well with the lean approach because we have states rollout you are able to release your update to only a very small number of players in the first few days or in the first day so what we do is we release every update to 1% of players first and we have around like 1.5 million daily active users so if 1% we already get very calculate

correctly 15 thousand users which is enough to figure out really bad technical box and technical issues if we don't find any there we move on to 5% there we can then also find like not so critical issues but still issues with the update we got to 20% of 20% we're already able to gather player feedback like our community team will actively ask players that have the new version a what do you think about that update we will screen the store for comments with that new version and this is the point where we are also able to roll the update back if the feature that we built isn't as good as we expected any players don't like it and then if everything runs smooth we roll it out to 100% and then also push it out to iOS and I think by now iOS or Apple released a feature to do something similar and I think our teams are testing that right now to also have to face rollout on iOS now a little

bit about how we actually do this regarding our tech stack so crash reporting is done with fabric earlier basic analytics like retention daily excuse us with fabric I think fabric is owned by Google now so there might be some changes people have integrated in the firebase but for us fabric was - it also nor MVP it's super easy to integrate that you get to tense you get your daily active user numbers and you get crash reporting now once we implemented inner purchases we had to have in-app purchase validation because otherwise your analytics are completely wrong due to cheaters we're using clap for that Iren thirst for at mediation one signal for push notes plays up again for cloud safe eventually of course you want your players to have to be able to save their safe game in the cloud if they get new devices if they play over multiple years you need to have this and then when it comes to scale eps flyer for marketing

or marketing attribution play feb for life up events get social for social invites and then assure for our data platform and then in the future for machine learning when we founded a company we had no idea how to build games so we of course as the founding team played games as consumers but we never worked in a gaming company we only one of us ever heard of unity and tried it out so we didn't know how to build games we only knew how to play games basically so for us from the very beginning it was super important to get as much player feedback as possible we really had no idea and we fought our players if we asked them if we really engage with them they're going to tell us what they like and what they do not like and here of course there's a common misconception so it's not like we do everything our players tell us if they tell us like hey your in-app purchases

are too expensive you should make the game easier of course we're not going to just do it but the important thing there is to really try to understand why players want certain things why players play our game or why players do not play our game and with that knowledge we are able to then adjust our game based on the understanding of our players and so basically we're not doing what the players tell us but we're solving the issues for the players by thinking about what their actual issue is and with that approach we were pretty successful so far so I'm Google Play we're four with 4.8 stars and last time I checked from the top 500 downloaded or most downloaded games we were in the top 5 based on the player or in the ranking so it looks like this approach there is working the hard part of course is what do you do with that quantitative player feedback because you have thousands of players telling you every week what they want to do in the game what they like

what they do not like and it's super hard to get that feedback to the product teams and to the developers so what we do is we have a weekly company community presentation where the community managers sit down with the developers and and the product managers the game designers to show them what the players like and what the players do not like and have this in this kind of like quantified list where they then are able to show it on one slide basically and one thing there of course is to to have a list to prioritize but I think the even more important thing there is to basically connect the community with the developers because it's really really easy as a development team to just sit there not really connect to players and have no idea what the players actually want and with having this regular update meeting everybody needs to see everybody will see what the players like about the game but also what the players like hate about the game and with this they are far more connected to the players and

will I believe in the end make better product decisions so how does this actually look like in the timeline this is the example of idle manor tycoon so when we released the first version 2016 it basically had only one line and players finished it after a day or two then it was clear after we saw the retention numbers the first thing we should do is build something in the game so that players can actually continue playing and we did this before we implemented in their purchases then the second thing we are a company we want to earn money we wanted to hire more people move into a proper office and so on so it was clear for us we have to implement the shop this is what we did then in 2016 at the end of 2016 then we aren't proper money we were able to hire people it wasn't only the co-founding team but like actual programmers and actual artists that we

hired and then we have the capacities things like life of events so in the beginning we started to really build it manually to ship one update where players had to download the update and then they were able to build to play that weekly event but now of course this is all automated and like Mike said there are many many things you should do when you do events we built a social light feature which helped us with download retentions it's not like a proper clan system but you can go on expeditions with your friends we implemented this year and the mainland and the Superman is just where we added multiple more points of content and basically a repeatable game with RPG element so that's it are there any questions so this happens of course some

players posted on reddit in the forum's wherever and what we basically do is we explain our players the process we tell them that we do a staged rollout that everybody will get the same version at the same time and well there are always some players that don't care about that and our chests hating I have two feeling that most of our players are understand understand that and are totally fine with that but that's also a good sign for us if we see okie players really want a new update because they heard from others that it's going to be awesome so we didn't know okay there's a hype about it and it's probably something good yep so for now we only do a/b testing on the store not in the game yet but this is something that we're going to take off this year prototypes but what's the point it's like just a few weeks so the first point

where games are supposed to be killed us after the eight week release if you push it on the market and see your day 1 retention is bad nobody wants that game then that's nothing clear and then the second point is doing soft launch if you're they're not able to get this 7-day furtive attention if you're not able to get proper monetization I think then you should also kill the game yes or I mean if the very first iteration is bad then of course not yeah so we basically split it up then in multiple updates for some features you're logically able to release it so sometimes we when we had the API main land mines there was a certain reward so we implemented domains but the reward was useless for now and then later we shipped the rewards and for some others we do hidden updates that are not shipped

[Music]