From Clash of Clans to Everdale: Scaling from Solo to Social

[Music] so i want to talk to you today about the journey of going from clash of clans to everdale from essentially solo game to an inherently social game my name is tristan williams i'm a senior programmer at supercell i've been there since 2014 before that i've been working at remedy splash damage rap bag on games such as alan mike quantum break and quake wars topics today intro we'll touch on the design i want to dig into that a little bit but the main meat of this topic will be the tech and some takeaways so in the beginning well you've probably all heard of clash of clans but in case you haven't we released it in 2012 and it's been effectively in the top 50 of the app

store ever since so near and 10 years now which is just amazing and everdail is one of our new software launch games released last year so a clash of clans if you haven't played it is a village builder where you gather resources with these elixir pumps and gold mines you build your own defenses and armies and then you take your armies and attack other people other players villages steal their resources in this inverse tower defense type gameplay and use their stolen resources to upgrade your own village and build more armies and gain trophies i scorch out so this is a game that's always got one village on screen at a time you never see multiple villages at a time the core gameplay is entirely solo in the game there's clans which is effectively an opt-in social layer you don't need to join a clan it will help you if you join a clan because then you can earn more resources through clan

wars which is yet another thing that feeds back into the core loop of the game but your progress at your village is still entirely your own it's still essentially a solo experience with a with a social added on layer there which is nice then moving to everdale so evideo is inspired by classics like settlers ii one of my favorite games when i was a teenager um so that inspired a lot of the village building gameplay where you you know you build stuff and you get people to go chop some trees and dig up some rocks and use that for building more things sims fallout shelter they were a big inspiration in terms of how we wanted the player to engage with the characters in their village they wanted to nurture them and build them as part of their own village identity another great inspiration was civilization not so much for gameplay but just for the sense of scale we wanted the game to feel bigger than any of our games before

so here's some gameplay as you can see we've got a village builder here we've got carolina here at the house we're going to build another house to attract some new villagers to stay in our village and so we assign her a job to do which is go work at that that work side so oh no i need some wood which will run over to the wood storage come back drop off the wood and start doing some building with some nice little critters around in the background then once that's done this is all sped up for debug purposes pick a new villager gabrielle here and here she comes to join in the village so there's all sorts of stuff to assign villages to do collect trees collect collect stone collect clay uh research at the library to make food for everybody to eat uh and we tried to make it all full of life but everything's related to each

other so you know first you have to get the trees and then you can start building building the buildings that's not all well there's the research the tech tree this will be familiar to you if you've played games like civilization or anything so you unlock from there all of the new buildings the upgrade levels and you get people to go and work at the library to study i should say to upgrade these things cool then from very early in our game the players are placed in a valley together so you zoom out from your village and here you go here's the valley and you can see other place villages right in this valley there's no transitions it's seamless so it's one they create one big world in the valley you create products for example here i'm assigning a villager to go and work at the wool farm gather some wool and then once we've got some wool we could go to the tailor and make some socks this is a valley

building this doesn't belong to the play it belongs to everybody in the valley these are unlocked at the great library here where you together work to research new stuff for your for your whole valley to work on together and you build those together as well and there's this trading element we have orders that come in from far away lands fulfill the orders and you from the orders you get resources you get valley upgrade points that's just kind of fun very relaxing chill vibes yeah so in avodah the valley is deeply linked to your village gameplay in the valley you'll be upgrading your villagers skills you'll be sending them out to guild to train so that'll help you with your village gameplay and you're also earning gold that you need for building new buildings in the valley so the village supports the valley and the valley supports the village these

two are deeply intertwined in the game design right from the very beginning it's not a new layer it's right at the core of the game and here we have shared progress and deep collaboration between the players it's a bit of background on our teams the way we do things at supercell before we go too much further it helps establish the context for the for the choices we've made so as you said we'd like to have small independent teams as small as possible so this game we actually started it back in 2016. so it's quite a long project but you have to understand that it was with less than six people for most of that time and only towards the end when it was clear that we were going to move towards soft launch for this game we started to grow the game towards 10 to 20 people ready for launch and at its peak it's only had four client programmers and two server programmers working on it so that's the backgrounds a bit of background next i want to talk about

the dream now every creative project whether be it a game or a painting a book it starts with some kind of dream even if you don't think of it that way there's some sort of idea in your head that you that you want to bring out and these dreams they come in all different shapes and sizes it could be small they could be big they could be mediums could be triangle it could be square but here i'm going to talk about small and big dreams so in my mind how i categorize them a small dream would be something like a cool mechanic like if you played heyday you know you to harvest your crops you don't tap them and press a button to harvest them you grab the scythe and you swipe your scythe through the through the crops and it's a cool little mechanic uh and it could be a unique gameplay idea like a game like portal where you take a first person puzzle game and you add this sweet gun that you can put a hole in one little hole in the other wall and pop

between them and adds a whole bunch of really interesting gameplay it might be something like an art style a game that comes to mind for that would be limbo so you get this what is a classic platformer at its heart but it's got this beautiful art style that creates a unique experience for the player another one might be an interesting piece of tech like a game i worked on many years ago alan wake it was uh the core idea of this light and shadow gameplay actually came from one of the designers seeing what one of the rendering programs was working on he was working on some nice lighting tech he's like oh cool maybe we should make a game about light and dark so these kind of small dreams i think of them a bit like this you've got the seed of an idea and you grow it into a big tree this is a really good way to build a game often you've got clear reference material that you can build from you've kind of got a little twist that

you're putting on an established genre perhaps but the the real challenge here is differentiation how do you how do you do something different but anyway it's cool stuff small small dreams are great to have then we've got big dreams and what i mean here by a big dream would be your lofty goals your big dreams are more user experience and emotion driven usually you're thinking about how does the player feel when they play this game do they feel like they're a space marine battling aliens in a galaxy far far away do they do they feel like they're a god playing populous or do they feel like like a chief managing a village starting from the high fantasy what we're selling the game that's kind of in some ways it's kind of the opposite instead of growing from the ground up

you start from the canopy you're looking at the tops of the trees of the forest and then you grow down and you see what branches do we need to build to support this and eventually you might find the seed and it might start to grow back up again it can loop in all sorts of crazy ways and you can have both big and small dreams in a game so dreaming big is quite daunting you may not have any idea what the mechanics are going to be yet you may just have this idea of like i want to have a game where i feel like a god how do you go about making that game there may be a lack of reference you may be inventing a new genre basically the check may not even exist yet so yeah sounds easy right well we do that anyway so getting back to everdale in the beginning

we felt like we wanted to reach a broader audience we wanted a game that wasn't wanted to make it make a game that was not necessarily about combat now if i could tell an anecdote about that it actually came a lot from me watching my wife play games like clash of clans and age of empires so if you play clash of clans at the beginning you've got this shield that lasts for several days that means that you can't be attacked nobody can come and steal your stuff for the first few games first few days that you're playing the game my wife installed it and she was loving it she was loving building her village loving laying it out upgrading things having a great time then a few days later the shield dropped and she was attacked she logged into the game and she saw you know everything's crushed and she's lost a whole bunch of resources and she was so upset she just uninstalled the game then with age of empires it's kind of similar she was playing the game she was loved sending people out to like hunt deer and build up her town she was really loving that

and then the war horn blue this is i think age of empires two that i'm referring to here some of the one of the old ones the warren horn warhol and blue and once she experienced the stress of being attacked for the first time she actually just started a new game and started playing another one up until the war horn blue and then she did the same thing she started again and played to the warhorn blue and then she uninstalled the game so that kind of raised my eyebrows and made me realize that actually there aren't actually that many village building games that don't have combat or conflict in them in some form and i felt like this was actually this was a challenge and a really interesting challenge that we should tackle um you know not all games have to be about fighting and sometimes you might have i play everdail in between other games so at the moment i'm currently going back and playing doom and uh in between some sessions of doom sometimes you just need to chill out play something nice and relaxing like a heyday or a or an evident

another dream we had was we wanted it to be more collaborative than anything we've made before and more immersive so that we can look at this now through the lens of the dream terms that i that i described before so we've got some small dreams here we've got a village builder there's clear reference for this there's a bunch of really good village builders out there we want something nice and peaceful and relaxing happy little villages happy little deer here's our big dreams this is the scary slide game with collaboration built in at the core we wanted from the very beginning that you're working with other people to achieve bigger goals and what you can achieve on your own i wanted it to be meaningful cooperation not just the layer on top we wanted it to be actually mean something to the core of the game

and we wanted to create a seamless world with multiple villages and as you saw from the videos before we got there in some form so the dream every game starts with some sort of dream it really helps if you can try to identify these early you might not even be conscious of what you're trying to do but you might have a feeling in mind a vibe that you're going for so try to identify these because actually these may form the core design pillars of your game and if you can write them down then you can always refer back to those and they'll help inform all of the decisions that you make from then on and especially in the case of this talk the tech choices so i want to talk a little bit about what is collaboration in a game and i'm going to use clash as an example here so here's a screenshot that i took of a offline build of clash in the in the uh alliance menu so you group up with other players this is what i think of as

collaboration 101. group up with other players and you have a menu where you can see the names of the other players maybe you can click on them and go visit their game states maybe you can chat with them that's cool next level above that might be where you've got something like clan wars where you've got what are still essentially solo battles but you've got some combined scoring that helps you get more points you know more resources out of this so in clan wars you've got the arranged battles from between one clan and another clan where you'll earn stars get resources based on your performance and those resources are still just yours there's still a solo element of the core loop but we wanted to go for collaboration plus plus seamless world watching the other people play in real time and real gameplay interaction in the real world not just in the menus we wanted to actually have as many of the things that you could do in the game as possible

centered around some real object in the world that you scroll over to and tap we didn't want to have to open too many menus and do things in menus sometimes it's unavoidable but we were trying to do as much as possible in the real world we wanted the teamwork to really mean something with shared goals between the players exciting stuff we're all pretty pumped about this idea but also pretty scared about this idea too because it's a big world it's going to be expensive to simulate and render and remembering remember we're targeting phones here phones and tablets not pcs and next-gen consoles a game like this we knew was going to be complex to design and even more complex to test so so we charged in of course so tech well in the beginning well we've got some technology that's fairly close it's village build technology so we uh forked clash of clans it's a bit of

background about clash of clans it's built on an in-house engine um it's got single village on screen at a time collaboration is effectively only in menus and its rendering is completely 2d sprite outer space these days it's not just 2d anymore but it was completely 2d and what that means with the sprite atlases if if you're not aware is that we've got the original models in 3d and then we render them out the artists render them out in a whole bunch of different orientations and every different every different pose and then we load those all up into the game as a pre-baked asset a bit more tech background is that it's a client server architecture as you'd probably expect the server's authoritative and it always asserts that the client is in sync with it and we do that by having this chunk of code that we call that we call logic code that we run on both the client and the server at all times and this code is designed to be as

deterministic as possible in fact it's designed to be absolutely deterministic we don't use any floating point values in our logic code so logic state is persisted by the server automatically into the database so you don't have to write any custom like queries or transactions to databases it's just all done for you the the client and logic code though in clash of clans relied very heavily on singletons so you know got your game object manager get instance get me the game objects that are a building uh shop offer manager get the offers and they're currently valid for the shop village just get and it would just be one of everything and it was hard coded which is nice it's convenient and very easy to code and obviously it's worked well for us for a very long time but you could only have one village

running at a time so the first step was to break that up so the first step of making the multiple villages work was to break it up into the concept of contexts so the context would bundle all the subsystems that the village needed to run into one class so you could get the context and that would effectively be a village it would have its own game object manager shop offer manager the village pointer what is the context um and you know it has some some downsides it means that every object has to have a way of knowing what context it is in but that's not a big deal so that was a fair chunk of refactoring but it's just work so there were some cool benefits that came out of this though for example we can now run the logic in the background as like a headless copy of the village we can just spawn one whenever we want spin off a copy of the of the village that you've got running and do whatever we want with it in the background we

could for example use it for some debug logic verification i'll mention that a bit more later we could predict it into the future if you've played the game you know that it gives time estimates of how long something's going to take so we can just when you user does something that changes the world we can just take a copy of the village and then fast forward it into the future for a long time and find out when that activity finishes so the design goal actually gave us some nice technical benefits so then next thing we want to do was achieve this seamless world we did that by giving each each village its own rendering world which has its own coordinate system which means we could move it wherever we want and it's still got the same coordinate system so every village like my village your village they all start at zero zero and go to whatever their maximum size is and we had one rental world for the valley same system just it was one for the

valley with the valley's buildings and all the ocean and the boats and things in it and the actual view we then composed by stitching together the worlds so each village would be rendered with an offset into the world and then this was nice because when you then moved to a different valley which is unfortunate but it's a design thing that we need to be able to cope with um we can then put that village in a different place in the new valley and everything's okay we don't have to do anything weird in the gameplay to like update everything's positioned or anything like that so great now we can see everything but uh back to the small dream it was the dream is to be a village builder so we want to have a diverse cast of villages from all sorts of different cultural drawing inspiration from all sorts of different cultural backgrounds uh with you know different hair colors different clothes we want them to be forming lots of different tasks so maybe

they're carrying a hammer maybe they're carrying a saw an axe or maybe they're you know wandering along with some logs or a pumpkin we also wanted to customize them we wanted players to be able to select what clothes each each villager was wearing and if you think about that in the context of the 2d sprite based content that's a lot of permutations every time we want to add a new set of clothing we need to go and back and re-render a whole bunch of stuff all the different animations any new animation just adds to the permutations so we made the choice to go to 3d but we didn't have a 3d engine we had some 3d rendering capabilities if you play brawlstars if you played that during the soft launch you may remember that it was actually a 2d background with 3d characters boom beach has some 3d background and there's also some 3d menu elements

in clash royale back in the day so we had some 3d rendering technology we had some pipeline so we just built a 3d engine a simple one a really simple one actually so we designed it to be as simple as simple to use as possible as close to our 2d engine as possible because actually a lot of people at superstar a lot of programmers at supercell don't have a 3d game background i did and a few other people at the company did um from working on our console and aaa games in the past but uh yeah it was important to make it so that people felt comfortable they could just jump in and start building new stuff as quickly as possible another actual surprisingly surprisingly tricky task was making the camera feel just as good as it did in clash of clans so if you play our games you'll probably you may not have noticed but you've certainly felt it that it's very very direct everything matches your fingertips if you put your

fingers on there and then scroll in and out or pan around your fingertips will still be touching the exact same objects so we we made it a goal to make sure that we match that one to one and one cool thing about this engine that we built was actually it made its way back into brawl stars so brawl stars is now is now 3d and uh our other games in software at the moment are also using that same engine and they're all 3d too and we now all improve the engine together and it gets better and better and better all the time so this little small dream actually ended up building a big piece of tech that benefited the company so probably the real meat here is the collaboration tech we want to have these multiple players in one seamless world so in the beginning we had that we had the multiple players in one seamless world

and we had it so that the the actions a player would do transmitted to the other clients so you could see you could see what other people were doing but you couldn't interact and you couldn't yet do something together in your own village this validation that you need to do is relatively simple on your client if you think you can do an action okay cool send it to the server server can confirm can validate when it send that this action is valid and apply it if not all we need to do is just say send back to the client the correct version of the village and it can just fix itself but when you influence shared state it's a bit trickier our other games in the past have gone about it in the way that there's manually persisted shared state that you have a database table with the clan and let's say that each one row per clan let's say you've got the column for the the name of the clan so that name is specifically

uh written out to the database this was done with manual message handling and manual error resolution for every feature so everything you wanted to do in the shared world required you to write the messages that you'd send from the client to the server to request to do it you'll require the server handling to redirect that to the right part of the server the right instances and the uh it would need to check that it would need to validate it on the server side in server code and send a response back an appropriate response it's like yes this change was made no this change wasn't made and the client would need to resolve that error if necessary so for a feature to be robust and good you effectively needed both a client and a server programmer to handle it because well usually when us client programmers start writing database code things go a bit wrong but so but we wanted to have far more

elaborate features than we've seen in our previous games and the previous way of doing things is kind of tedious and we felt that it would make the development time of the game prohibitive if we were to develop the shared gameplay that way so we need to improve so what we're going to do our first pass first thing we did was we added this shared logic state for the valley so this is the bundle of logic code and it had its own context as well it meant that we could now run game objects in the in the valley code in this shared code as well and we implemented a well-defined action object which is you know a class it was encapsulating the player's action and its parameters all the validation checks necessary on every step of the way all of the handling code for for validation failure and any rollbacks that would need to be applied

so if you're writing a new action you just derive from this class and implement the function in from the interface as long as you implemented it correctly it would it would work so how this worked in practice was it would validate the action on the client if the client think it would be it thinks it'll be okay it'll send it to the server the the village part of the server so for scaling purposes we were keeping each village separate and the values separate and communicating between them so the action will be sent to the village server if that failed then you could respond to the client with the failure the client could then run the appropriate rollback code it was okay cool send that onto the valley and let the valley server now validate if that failed then you'd have to get send it back to the server for the village run some rollback code then run it send that back to the client and run some

more rollback code if it's okay cool just apply it and distribute that to the other clients so you can probably already see that this is not great but it had some advantages it was much neater and easier to see all the handling in one place rather than having the whole whole flow of this action being spread between our client code and our server code and a whole bunch of different files along the way instead it was all bundled together into one neat little package um the setup that we've done meant we could share actually a lot of code between the valley and the village and one game programmer could now build a complete transaction without the help from a server programmer which is great because server programmers their time is usually best spent on things that they're amazing at like balancing loads and

managing databases and all this all this cool stuff disadvantages disadvantages we found were the onus was entirely on the programmer to foresee any potential failure case and implement appropriate rollback for any of these cases so at any of these points where that message was going through something could happen that make it so that your action fails you know someone else's action might have been applied first that makes yours fail it might just be that someone's running a hacked client perhaps all sorts of all sorts of things like this could happen and you need to have appropriate rollback for all of them so it was still tedious laborious error-prone code to write it was actually pretty much the old way just wrapped up in new packaging and all the client and ui code would need to be written so that all edge cases can be handled with all the various bailout scenarios

so let's say you are giving some wood to a construction project in the valley you'd say okay i've subtracted 10 wood and sent it off but it needs to come back and you need to get that 10 wood back again or a menu might pop up and you need to get rid of the menu or change the state of the menu completely so often this sort of stuff is not trivial to write and when you're dealing with a small team and you've got a lot of features you want to build and a lot of sub features within those features this consumes a lot of time and it's wasted effort so we decided to improve this what we did was he adopted a re-simulation based approach if you've if you've ever written any multiplayer tech before you'll probably be familiar with this way of doing things where the clients run ahead of the server and kind of just assume immediately that their own actions work and then if if something changes in their assumptions then they rewind back and

then re-predict re-simulate again to the current time and try and do it so quickly that the client the player never notices so here we changed it so that the server would be running all of the villages and the valley in each valley synchronously the clients will be running slightly ahead of the server and we made it so the clients could rewind to the last known good state and re-simulate so the server here is validating and applying actions against the whole the village and the whole valley at the same time so everything's in lockstep moving together one step at a time so advantage of this we didn't need we no longer needed any error resolution or rollback required it was inherent in the way the system works we need validation and execution so our action class that we had to find before the number of functions to implement dropped to basically validate validate with the village validate with

the village and the valley and execute this this is a very robust way of doing things because the service state is really well defined at any point in time the server's got in one instance in one thread it's got all of the villages in their current state all at the same tick the valley at the same tick and all of the actions that are going it's going to have to execute in the future in this case yeah as i said before error resolution and its predictions can be handled universally in most cases not all the time but most things can just drop out of this architecture i wouldn't necessarily recommend this architecture for every kind of game i wouldn't do it in an action game but it's uh it's good for this sort of slow paced game so disadvantages of this meant that we're going to have to store a lot more stuff in one thread and run a lot more stuff in a timely manner on the server than ever before

and the client needs to store this history information and be able to rewind and fast forward again without the player ever noticing some ui scenarios still need very careful handling you might have a dramatic change in state based on the misprediction you might have your menu up with you know you've selected that task to do and you started doing it and then suddenly you don't have that task anymore and that all that needs to be to clean itself up which um actually if you switch to more like polling style ui a lot of these problems kind of go away they kind of as long as your polling ui can handle any random change in state more like a true thin client then uh then it works quite well and we also found we need to avoid direct callbacks from logic code to client code in the past we've often had it so that you want to play a sound okay call there's a callback from the logic

to the client and then the client plays the sound but now if we were to do that exact same way with re-simulation then while you're re-simulating you might play that sound a whole bunch of times so this actually proved out to be a great success uh we were able to develop the systems that we were trying to develop much more rapidly than we could in the past we're talking weeks instead of months compared to the the way we would have done things in if we're doing them in clash of clans we only needed a single programmer per feature which is really cool because i can think of one time during the project where we had a brainstorming session coming up with some cool ideas and uh we had this idea of these trade relations with different ships going out like maintaining a relationship with different different nations different other countries and at the same time this other feature of

these challenges or events that would pop up in your in your land and you'd work together to resolve them so both of these are relatively complicated features when you dig into all of the different all the different things there and we were able to do them with one programmer on each of those features get the first versions that were ready for a proper play test in a couple of weeks most of that time is actually just implementing uis and well if you've been in the games industry for any length of time you know by now that iteration time is key especially if you've got a small team like ours where at the time i think we only had three client programmers on the game and one of them was focusing on rendering technology though we like it's really important to keep up that momentum and test out the new features as fast as possible fail fast all right he's so cute

yeah uh so performance we got a problem here we've got 10 villagers and we're going to have hundreds of thousands of objects per village in fact i was just debugging one village the other day which had 2565 decorations in it uh we've got this complex flow based logic where you can't just fast forward a timer like many many of our other games instead you have to wait for one worker to bring something to the storage and the other worker to come and get it that whole process needs to go through so performance was definitely going to be an issue so for rendering we chose to actually render our villages to texture imposters so we loaded the whole village rather than trying to load the sub-objects in the village instead just load the whole village as you zoom out swap to rendering it to a texture and then stagger the imposter updates

because once you've zoomed out especially on a phone screen this village is now so small on the screen that that one little villager walking around it's we're talking sub pixel changes here so we can easily just make it so that we only render one village at a time one village per frame to attack to a texture and maintain the illusion that we're running all the villages all of the time and then we made a lot of effort to make it so a near seamless transition between them so here's a video of that taking place here i'm zooming out from my village and uh zooming into another village if you if you know what to look for you can spot it you can see the the grass change shade a little bit there still some more work to do to make that really really good but you also see these objects are scaling up and down and that's actually nothing to do with this transition that's actually to do with we felt that when we were drawing them as the normal scale of objects that when we

zoomed out it kind of it looked too noisy it just didn't look quite right so we went for this more iconified version of the village as you zoom out so what about logic optimization obviously we're running a lot of villages at once on the server and we need to be able to rerun the logic quite often on the client so our game play is relatively slow so we found that we could actually reduce our logic tick rate from 25 hertz to 5 hertz and the the player wouldn't notice any difference at all of course response time is definitely an issue there where if you initiate an action you might get up to 200 milliseconds of latency before the action actually starts to happen so to get rid of that basically the client just as soon as you've done an action just jump ahead in time to the next tick and then that extra that you've accumulated just ease it out over a few frames and uh long enough that you don't really notice

the speeding up and slowing down the gameplay but it still maintains the illusion that your actions are happening immediately may the client interpolate logical state as necessary and that worked pretty well it's one one fifth already so then we move to trying to ensure that our update functions could be deterministic with a variable update length so you know we could update the world tick by tick for 30 ticks we go tick tick tick tick tick and that would be your state at the end or we could update 30 ticks in one update call update 30 instead of update 1. and here we want to make sure that our state at the end with update 30 is exactly the same as the state if you go tick by tick now we'd probably do this a little bit differently if we were to doing be doing this from the very beginning but this was a retrofit system so we had already had a lot of code so we

had to make the choice of doing it a little bit differently so we what we did was we allowed any object or system to declare how many ticks that they can update for deterministically we call this the max fast forward ticks and then uh we found that many objects can actually just skip their updates for multiple seconds at a time so it even up to hundreds of ticks they could just just fast forward for the over that whole thing one function call update we had to re reorganize some of our things like pathfinding and villager movement so that so that that wasn't a tick by tick update instead it was a like just jump jump forward in time so we made it so the client would step tick by tick to maintain the smooth gameplay and the server could fast forward villages forward and this was really awesome i mean this is this is a conservative number here but it actually reduced server load by something like 80 to 90 and here we're talking about compared to like a clash of clans

village so even though we're running 10 villages at once we're still like one-tenth the cost on server side of running a single clash of clans village it also let us do things like the off-screen villages on the client we could just not update them or update them less often and just fast forward them up which was a really good speed improvement on the client but of course you might ask how do we determine how do we guarantee that everything's going to be deterministic so we can then take advantage of this ability to run a background copy of the village so we can run background verification so load up an older version of the village fast forward it to now from that older state and then compare it to now and assert that they're the same if they're not we can save an error trace json file with the the last known good state and then we can then load that up into a debug client run it forward and

repeat over and over again with the situation that's not deterministic and find a way to fix it and the server's debug servers can also save traces out when these situations are detected so when we're testing we can catch any really weird cases so with guaranteed determinism and decoupled logic execution we can do all sorts of cool stuff like store replay traces for bug testing we could do regression testing where we just download all of the villages from the database and simulate them before and after any big system changes and assert that we have the same results say change path finding we still want the results to be comparable and all sorts of other systems can be validated in background threads while playing we also built ai logic that can play the game at first that was just on the client side to simulate when you've got other players in the game with you but actually we then realized oh yeah we could actually just port this over to

our logic code base and we could also port our client synchronization logic over to the logic code base2 and then we can just make server code that can connect to a load test environment and play the game spawn thousands of bots and gather a bunch of balance and stability data for us this was actually really useful for isolating some of these really rare bugs you get sometimes with these games and a real help because it was a very complex game with many many systems that will all work together so as a result we achieved our dreams mostly the game is now in soft launch we'll see what the future holds but even if it doesn't make it to global the tech will live on so key takeaways here dream big but go in with your eyes open it's not necessarily going to be easy to achieve these big dreams but you can you can achieve them and you may

get all sorts of side benefits along the way technical improvements we've got better tools for our future games investment in new tech usually does pay off so yeah hopefully this talk has inspired you to maybe tackle your own lofty game design goals dream big i want to see some cool games out there thanks for coming please remember to give the feedback we're hiring any questions [Applause] [Music] hi um you were talking about this discussion you guys had about the trading systems in which you like you know the trading systems where you were talking about like the developers went off and they worked on one feature each etc right were the developers directly involved in that conversation in terms of the design itself oh yeah absolutely every step of the way when you're working with a small team like having that kind of level of buy-in and

everybody being involved with as many of the things that they're working on as possible it's like it just saves so much time from motivation absolutely yeah okay thank you yeah thank you hey tristan uh a question on the zooming you're talking about how you did a lot of different approaches to the zoomy how did you think about what size was too small and too large and when to do the swapping because that's a prom and you know it looks really good on the big screen but how do you approach that with the variety of screen sizes that you're dealing with on your game we tried a whole lot of different screen sizes lots of experimentation um we tried many different iterations and i think there's probably still iterating the artists are probably still iterating on those you know scaling up and scaling down things i was showing it's a constant process but you know it's it's uh everything can always be improved lots of iteration like you're talking a lot of play testing just to give that feeling lots of play testing to get that feel right how it sounds absolutely and everyone in the on the team is playing the game so like it's

it's uh you know you get the build out and everyone's like oh yeah that looks pretty good gives feedback to the guy off you go try again thank you no problem um when working on something that was so experimental for so long how did you balance between iterations for the experimental stuff and just play with such a small team just plain old housekeeping keeping apis up to date uh you know all the stuff you need to make sure you don't get kicked off the play store yeah yeah fantastic question yeah i uh i'd like to say that we have a silver bullet for that but you know it's just using some common sense and uh usually if you've got a good bunch of developers that are really close to the game and really and know what's going around them they usually make good decisions without actually needing sort of any uh any uh overarching philosophy to be applied it's kind of we have a we have a

uh a bit of a saying in the company of like supercell first uh or we have had that so sort of like make a decision that's gonna be good for the company and not necessarily good for good for my getting my jollies by doing another iteration or something because i'd be really cool if i did that but like actually does that really add something am i really adding value here just a different question in terms of determinism uh how did you guarantee that across all devices and all different cpu architectures that the same code would result in the exact same result yeah it's a great question and uh actually it's even more complicated than that because our servers are java uh and our clients are sequence plus so uh we actually do it all in fixed point no floating points allowed yeah okay so once you're in fixed point there's there are some really interesting edge cases in fixed point overflows with especially we found a few new ones with the m1 the new m1 superviews that we had

to manually figure out in some of our core libraries but um because of the tablet not because of the laptop right the laptop actually they are monitoring the laptop yeah the m1s views on the ios they handle a certain kind of overflow slightly differently okay uh because it's like undefined in simplest plus that particular behavior yeah it's fixed point mostly solves the issue fixed point yep thank you yeah and and when you're testing it on your computers so you log the state to replay it if a player reported it or you know it automatically locked it and on your computers it runs the exact same yep absolutely thank you a quick question so when you're talking about the server architecture you talked about how you re-architected it um a couple of times on the client side it also sounds like you guys did several refactors how do you guys think about that in your planning process because at the same time you're talking about building out

prototypes very quickly in like a one week turnaround and how do you balance what needs to get built out quickly versus when something needs to be refactored because it feels like at least from my experience a lot of time refactoring gets cut because it's not necessary to ship it does help the product but just want to hear your thought process on that yeah that's a really good question um again i don't have a silver bullet for that one i have a personal philosophy on that one that once i'm uh once i'm copying and pasting a bit of code more than three times or three times or more i start to refactor to combine them and and then it comes down to a lot of just thinking about what's right actually some of the refactoring like for example the the second pass on the way the actions worked for the shed for the shared logic was probably twiddled my thumbs about it a bit too long before i started on that uh i wish i had done it sooner because i kind of like it was bugging me that this is still tedious this is annoying to do this stuff and then eventually bit the bullet like okay

scrap this re-architect the server a bit so the re-simulation instead and uh it it was a bit of effort it was quite a lot of effort but it totally paid off so we should have just done it earlier that way yeah so it's a it's an experience thing so when you go to your producer there and you're like oh man i have not refactored this i need to do this it's going to take it you made it sound like a big effort right so it also you come into your producer and saying oh man i need to refactor this it may take another month two months um how do you work with that on the rest of the schedule do you just say the schedule keeps pushing based off of that or do you guys look for trade-offs there um well our producers are so close to the game they kind of see a lot of these difficulties and they kind of see that that you know this feature is going to take a long time so it's kind of a matter of making that case of like okay this might take a couple of months but it's going to mean that we can iterate so much faster on our features and it's not everybody in the team that's stopped by this it's kind of my maybe my work on other things slowed down for that

time and then the system was was completed i did the migration for the other guys on all the work that they were continuing to do while i was working on this branch and started moving on with the new tech so it's comes down to like helping your producer understand the trade-offs and trying to be realistic with yourself about what the trade-offs are going to be and trying to make good estimates thank you yeah thank you hi hi so um i was thinking about what you said at the beginning dreaming big about a game that it's not necessarily about combat and more inclusive and avoiding the frustration moments of seeing your base smashed in clash of clans yep and i'm an avid player of clash of clans and i'm playing in legends league now most competitively and i never see anymore my base smashed and they never lose any more resources so it kind of looks like backwards right like did you guys considered of having this

kind of behavior at the beginning of the game to avoid the frustration of seeing your base smashed while pushing it more in in the more competitive phase of the game and the end in the legends league yeah that's a really good question and we've we definitely talk about things like that and we have talked about things like that like oh should we have like a kind of a competitive end game for the game or something like that and that's all still quite open it's still pretty early days for the game and you know maybe that'll happen someday i'm not sure yet but actually very early on i was kind of i had this extra dream which is one of the ones that didn't quite get realized which is that maybe it's kind of maybe both can co-exist in the same world you've got people that are into combat and people that aren't and that they all help each other still maybe one day we'll have something like that but but yeah cool question and congrats on legends league that's awesome yeah my question was actually quite similar because most of the other games are competitive games so it's just like have you learned

something from the players playing it so far how they do they fall off because there's not like a good game loop there or what have you learned from so far um it seems to really resonate so far it seems like there's a lot of people that have been hanging out for a game like this where you're just taking care of nurturing taking care of your village without having too many worries it's it's quite amazing the feedback we've been getting from one i mean the people who one big surprise was that we actually kind of expected to find quite a different audience like quite a different category of people but surprisingly there's heaps of people who love to play clash that also love to play everdale precisely because of it being just chill which is kind of cool and if you really dig into it there's actually you can open up graphs and see what your resources are doing so if you want to you can actually play it in a really hardcore way i wouldn't recommend it i did that for a little while and it drove me a bit crazy but have you seen if there was like more girls playing it or even different types

of players we expected it to be a bit more female dominated audience but um it's actually pretty it's pretty even it's it's been really nice to see the figures about that sort of stuff but it's as i said it's still early days it'll be interesting to see what happens hopefully we can bring it to the us market as well and see what happens here too cool thanks hi um you talked about you had this big dream about designing a new type of game and we know humans are kind of unpredictable so since launching a game did you guys see like any like strange behavior that players tend to do that diverge from the way the game was intended to be played the version the way the game was intended played yes we did actually um we we didn't expect to see so many people um wanting to play the the kind of the social side how to put it kind of the administration of the social side so differently than

we expected so it you may not be aware but we we had the game in a soft soft launch under a different name um before and the players from that kind of behaved quite differently uh and as soon as we put it to soft launch with our brand on it we were a little bit surprised by by how they behaved and it was really cool it was a wake-up call that that our assumptions were incorrect in a few places and actually we'll have a new update out soon which will hopefully help for people that are frustrated by the way that side of the gameplay works so yeah that's a good question thanks because no one else has go ahead in your in your takeaways you mentioned that it may not result in a global launch and i'm just trying to decipher the reasons for that one assumption i could maybe make is because it's not as combat focused more chill people don't go as intensely don't spend as intensely well perhaps i just worded it wrong um soft launch for us is like this this kind of partially proving

ground partially like a maturing ground um and we we just get the game out there and try it with real players and see how they really act and we learn lessons like we found that some of our assumptions about the way people game play the game are completely wrong so um there's i wouldn't want to comment in the likelihood either way but we're just gathering data and you never know sometimes we kill them sometimes we and the killing decision always comes from within the team like do we still believe that we can make this into like a game worthy of supporting for 10 plus years like our other games so yeah i wasn't trying to uh imply that it's not going to go global just that of course not we'll see we'll see what happens okay sorry just just on that point um do you feel like making it more chill while maybe appealing to a broader audience or maybe a different market um made it tough to have like extremely dedicated extremely hardcore players

no um the players are crazy so it's amazing love the the response we've had is insane like it's it's um it's really cool i i think you know it's just different games for different kinds of people like some people like to chill some people like it hardcore yeah okay thank you very much yeah no worries so uh clash of clans obviously a competitive game so you've got like a leader board where players are playing against each other so when you like monetize the game like that uh it's a little bit easier since you've got like sort of a little bit more competitive aspect to it going on so how would that factor into uh yeah um i mean we're still learning okay we're still learning what's the best way to monetize game games uh like this it's always it's always a surprise you try things and they don't always go the way you think and you adapt learn from them try something else ongoing process

yeah i think we have time for maybe one more i've noticed that uh with a lot of these social features people like to like form groups and communicate with their groups on strategy yeah on places like discord or facebook or reddit um have you thought about maybe like making a first party tool for that or like integrating something more officially with supercell yeah i mean there's a lot of ideas floating around always you know all these sorts of things pop up from time to time we'll see we'll see what happens yeah it's very cool i can't i can't believe some of the stuff you see if you ever watch how people play clash of clans competitively at the top level they've got like that painting overlays and everything it's amazing super cool stuff anyway thank you very much and just come and have just come and talk with me if you've got some more questions [Music]

you