How Flaregames and Kopla Games Doubled the monetisation performance of Nonstop Knight

right so thanks for joining everybody we're gonna be talking about a game called monster night and how we go about creating that game so first things first I'll obviously talk about myself so my name is autumn I'm a bit of a systems designer economic kind of a guy at the moment at Flair games so kind of an Excel designer obviously I work with non-stop night at the moment before this I have experience with working with quite a few different teams and quite a few different free-to-play mobile projects night for me for my career is a bit of an outlier and it's not just the case for me but that's how a lot of people working with this game feel that there's just something unique about how we make it and that's why I'm here today to give

you some insights into what I think is unique and cool about the process right so some basic facts about the game have you guys played this one right so one stoplight is a bit of a streamlined action RPG it has an incremental economy so overlap with games like tap Titans that venture capitalist and like we're doing it together with flagons a couple of games we launched it earlier this year it says here 5 million installs I believe we're over 6 at the moment but who cares it's a number that's growing in general we're all very very happy with the results so far for those of you who like numbers I have a few slides so this is the retention curve how as we had it at the early data points that are early soft-launched what we realized there even with a very early version of the game that the game had very strong early metrics early engagement metrics but at the same time at that point the game got failed pretty fast he ran out of things to do so the later extension was we considered that to suck and

something we needed to aggressively improve on and that is what we did and we did succeed to a point so by the time we went for launch we had more or less doubled the de 30 retention if you're wondering or evaluating if these are good numbers bad numbers know that these are not our averages or anything like this so had control for the install source to isolate effect and what this means is this is in fact pretty high quality install cohorts so if you see a number there that you don't believe that's that's the reason similar story for revenue so at an early stage the game had some promise so we had a fairly decent conversion rate at the time yet at the same time the monetization was very front-loaded so most of the money was coming from the first days after install indefinitely nothing happening after day 30 or so so it wasn't exactly game of war at the time this was also something we improved on quite a lot so the realized revenue at day 30 at launch time was more than

double of the early numbers and of course the shape of the curve is much healthier so we have much much more Eldar game revenue coming from outside the graph and this is also something we've improved on quite a lot and there's a very good trend there so we we're on a good track there right so my agenda for today is pretty simple I wanted to give you an intro on the game that we did it's also show you some graphs that we did next I'm gonna talk about who's making the game that will make it easier to kind of go into how we make the game and then finally I'll talk about design collaboration or working as a team in design in general and on one stoplight so first who's making the game I already mentioned it's a collaboration between Flair games and coppler games what that looks like on a timeline is this so couple of games they were doing the game for quite some time with a team of four and then you can quite clearly see the point in which we went all in and started staffing up both on the core

plus side and on Flair game side now if you work with project management this is probably a bit of a scary graph we did manage to scale up pretty smoothly I'll go into detail on what that meant for design but yeah you get the picture so with that knowledge just a warm-up question I'll do small and team small teams and big teams differ when it comes to making games so I listed some interesting differences big teams to begin with they have a bit of an advantage to their size so you have a kilometer of scale you might have multiple game projects so learning from one game carry over to the next one and also you can have the luxury of specialists all very powerful things at least in theory and if you use them right now smaller teams they have a lot of good stuff as well due to their size they have lower overhead less risk for politics or rather like doing things for

wrong reasons also very important there must much faster to react and adapt and larger teams and also much less scared to fail than larger teams tend to be then if we look at kind of like the typical products of these teams I think large teams tend to create these large games that are optimized but often have little to no soul and no innovation that definitely need not be the case but in the mobile feet of play spaces especially if you look at the games that larger teams are pushing out this is often just just the case and of course there's a risk of waste so larger teams you have all of that good corporate stuff going on with the endless meetings forward presentations initiatives that lead to little value in the actual product so there is a risk for that smaller teams on the other hand I think they have an advantage when it comes to creating games with a stronger product

identity yet at the same time small teams tend to make small games so that means a more modest feature set not that much content and ultimately they're somewhat limited in their revenue potential now I need to mention this because in this project we have a bit of both though player games as a larger company has some characteristics of the big team archetype here for the negative stuff I mentioned I think we're fairly good at avoiding them yet there's always a risk for that so it's good to acknowledge that stuff but more importantly if we look at nonstop night and how that game looked like let's say eight months ago it was very much described by this box here and even more importantly qapla games the way I described the small team archetype here I believe qapla is a very extreme example of that so all of these points absolutely apply alright so let's talk a bit about them so how does qapla game games develop their games first off this

isn't a team that's not very interested in making derivative games or being a like a follower in the market actually they're their intent is more or less to break the action RPG space on mobile so they want to create something new and how they do that first they accept that they don't know the unknown so to say they don't necessarily know what's good for their game either in the short term so what they didn't to do is they just try out all out a lot of stuff and let the process or the game rather teach them so this is very descriptive of how these guys think and think and develop the game right so long stuff not as well is the product of this mutation process that they foster the term for that that they use is brute-forcing luck and what that means for the game is that non-stop Knight has had like a million and one different experiments and different phases a lot of the iconic things about the game such as the portrait

orientation or the incremental economy those were things that all also were not there from the beginning but they were discovered on the way through some experiment right so how does this work forth first of all we tend to do very little upfront design so more often than not we design experiments rather than pull sensible features second you're supposed to move as fast as you can so quick and dirty is often enough to kind of learn something or validate a validate an idea third this is very interesting so if you allow for it you kind of tend to run into these happy accidents and we've seen this a lot so a lot of the cool things that are currently in the game we found out kind of as a byproduct of something else that was tested at the time so if you do test enough stuff and look for these things there there's a lot of value there and forth of course you're supposed to find out what doesn't work as fast as you can

and then move on right so I pretty much described iterative design there that's not a new concept these guys didn't invented what I think makes them special is just the fact they're so regimented about it and they're very good at it so these guys are really really fast at breaking their game and putting it together again so what I think makes this this team unique is just extreme hardcore approach to wanting to validate things not believing anything before they tried it and this humble approach when it comes to design that just shows on the product itself as well so this approach does have some limitations I listed one here so the experimental process kind of only makes sense when the results are instant so as an example we might have three four experiments going into the game on a Wednesday and then by Thursday we don't already know

what we like about them on what we don't like about them now in cases where you would need to play for a longer time or kind of wait for the data to come in from the player base all of these kind of loses its magic so for that kind of stuff you need to adopt another approach all right so with that in mind I want to talk about how we design things as a larger larger than one group these are I think pretty relevant questions for any design team I'll go through all of these and how we work on non stuff night so first it's good to know who does what independently second at least implicitly you kind of tend to know what are the topics that you design on design together or decide on together that certainly cannot be all topics and third maybe most importantly when you do work together how do you make it efficient this is not that easy there's a lot of stuff that

goes into the third point and there's a lot of you know risk for inefficiency there as well so first question food is what independently now I talked about the brute-forcing Locke approach that's represented here by team exciting what that is in in practice is one or two feature teams that kind of execute on that so just to make it clear the experimental processing is not a thing they did at the early stages of the game it's something that we constantly do even now as the game is live so what these guys would do is a bunch of experiments at the start of a sprint cycle then get the learnings from that and then focus on the good stuff ship an update and then repeat from there from the beginning now I also mentioned shortcomings that's why we have team slow and boring that's where I live so that's more focused on excel sheets looking to player data very much focused

on kind of the long tail of the game and these slow slow slower game loops and just a scaling of the whole thing as well as data-driven optimization so that's kind of the rough high-level split we do second what do we work on together non-stop not this is a bit of everything and nothing answer so we do try to get the input from the right people at the right time and how we do that is we allow for push feedback to transparency so you know you know what the other independent entities are doing at all time so you can just jump in with stuff you thought of while walking your dog second we have this culture of just asking for input but maybe most importantly it's a final point that in this project there is nothing that comes even close to like an approval process so there is not a point in which a piece of design gets this official stamp and then we move on with that and all that

stuff that is kind of a characteristic in other other teams so in the end what we have is setup where we do seek input but that's never a ball so in even in the absence of input everybody can move on as fast as they can finally what I think makes the collaboration efficient in this game and this is basically a collection of points I think are very good practices but in this case it's more or less things that are forced on us by the by the iterative nature of the process first I think it's very good or important to know when to put a design topic on hold to know when it's good enough because if not I mean design discussions don't have an end how this works our non-stop night is we basically have an experiment lineup on a topic that gives us a cube of just waiting on the info from that so we can kind of drop the topic for now move on to the next one this keeps us fast

second yeah I mean a lot of us try to create this environment we're offering critique and shooting down bad ideas this is as you know fiction less as possible so a lot of the wrong reasons like personality comes into the way most ignite again this comes pretty naturally because creating bad ideas or bad features is kind of a key part of the process so if something stupid goes into the game in this prod this game that's not because somebody was an idiot because they thought it would work but it's it's a fair fair guess third goal-oriented product management is something we try to do at flair with every project what that basically means is let's take the example of setting a strategic goal for for an update for instance so what we do is we try to spend some energy in just framing the problem as well as we can but leave a

lot of room for the actual solution so there's there's room for this discovery on the way so we we try to avoid being prescriptive on how to fix the game so to say again you can imagine this is actually the only way we can work on stuff I just do the fact that we want to try everything before before we believe in it and then finally I learned that high level of trust can really lead to productivity gains now what that means is if you can reach the state of multi-directional trust or whatever then you can kind of let go of a lot of unnecessary control structures and everybody can just work faster so this year was my final slide I think for me it's more or less the most important one as well so I think all very very good points I thought I knew before working on this project what they were kind of like force-fed to me these learnings once again cool you guys have any questions any

questions guys it's always best to get someone else asking alright we're gonna get a microphone to you just a second coming your way thank you for the testing do you do the testing I mean especially the one that you didn't go live you do it internally or do you have a some group that you test fit so we rely on the intuition of the team mostly so the process I mentioned earlier where on a Wednesday we explode the game with some stupid test and another Thursday we know what we like that that's just the core team playing the game overnight that's that's most of the info comes from there they're pretty good with their judgment they're kind of steering with with the gods so to say on top of that every now and then we do larger you know test groups and of course we look at the data but what I've mentioned first is kind of at the heart of the process thanks

any other questions I was one of the definitely high what did you actually do to raise the retention and monetization it's kind of a from building up from a million different components so there's a lot of feature development actually months of feature development there also we put in more content so at the time you just ran out of goals if you've played the game we focused a lot on this ascension loop it was in the game at the time as well but it kind of sucked like the upgrades you did with the ascensions where we're not as good as they are now and there was a lot of smaller tweaks we put in as the friends such as the frenzy phocians all of that stuff so gameplay were variety just giving the player goals for a longer time that those were the biggest things but on top of that there's a lot of balancing through a/b testing and smaller things that also add up so I was gonna I think cuz then we talked about this earlier on before we

started you know I think this game was shown off a being any pitch here last year or recently around that sort of timeframe and it's interesting because you know we we relatively informed judges we looked at things and we didn't pick it right and actually I kicked myself a little bit cuz you know we kind of why didn't we pick it and I think one of the reasons why think that happened is because we have a series of internal biases we see a certain number of trends and we assume those friends are done how does that process it you're describing this brute force process avoid those pitfalls of the wrong assumption making those assumptions well I mean you need to have good judgment and good intuition as a team I mean the wet is that yeah because I think the problem with good enjoy rain and why I like this process this is you're kind of to the extreme breakfast is he kind of forces you to go beyond some of your assumptions but it's it's really hard to step aside isn't it and and to at least give yourself the space to experiment in fact yeah I see

what you mean I mean I guess it's something that I believe these guys as well and us when joining the game and game a bit late had to get used to so you don't just assume you know everything but instead try to make the game better one step at a time and allow for the learnings there I mean if you have a misstep there you can always go back and discard that so it's a it's a good class is having the hump and being humble enough to to be willing to say yeah you were wrong about that let's try this again yeah yeah any other questions never pushing down here I think we can get a mic down to you reduce with me just coming around now on the front road thank you thanks hi gimmick got it from a rival games I worked previously actually in a

publisher which will hammer topped the days in France and and then I had a couple of times cases where I also supervise like extra proper to set up their game projects cases where there where you had a good game but then and then you think Forex a lot yes this user interface sucks but hey it's easy to fix that we will we will do that later but Dennis sometimes I realized that this skill is missing from the team hmm and and how how have you faced such a situation that some skill is missing and what what you're doing that those those situations with this team certainly I mean this team I think what they do right is first is pretty smart second they know what they they're lacking so they pick the kind of project that suits the game sure enough they were they were missing some skills and didn't have to focus for that so what

they could do it they could dump it on the publisher which is Flair games in this case but certainly I mean I think if we talk about design specifically I I've seen a lot of cases or we've seen this player a lot of cases where that's not the case so people kind of go on a project where they don't have the skills being just the manpower to do the content the game needs and very often economy design is also missing so they don't have the Excel guy and a game that is very very much dependent on that guy so those are some of the typical things that are are lacking in Flair games you don't personally really put your hands on to the game if if there's certain skill missing for example you don't truly start doing the game for them you have your more proposed but there's a problem right so that part is case one case we can't get really hands on whatever helps best on this act example we had four engineers work on the game so doing SDK integrations Android stuff

and all of the server stuff is fighter against engineer myself I do the balancing for the game so that is very very high and basically that's because we don't want we didn't want to hire five more guys a cop last night it's just easier for us to do it and cope so unfortunate up what we have to move on great thank you so much I think it was really really insightful useful thank you so much you very much