top of page

Optimization: Balancing Frames and Fun

Hi everyone! My name is Ryan Kosha, and I'm one of the gameplay programmers working on the Dominature team. My job is to create and implement the cool ideas our design team come up with and bring those ideas to life. I'm here today to share the journey and complexity of balancing performance and fun in our game - the joys of optimization!

When the NaughtShore team decided on creating a minion focused game, we knew we wanted our players to be able to throw massive armies against each other and have intense visuals to accompany the fast paced action happening on the screen. We also knew that those minions had to be independent - be able to function on their own in the game world without necessarily being part of a mob. With these goals in mind, we began to design our systems around this idea of large scale minion warfare. Although it's a popular belief (and well-founded) that optimization always comes at the end of a project, taking these design considerations into account when building up your technical frame will save you hours of work down the pipeline.

Over the course of the working on Dominature, we've had a few pain points when it came to optimization - minions, mobs, collisions + physics. If I were to pull up an early build of Dominature and compare it to our release candidate, we literally have over 9,000% improvement on performance! In these early builds, our scripts alone were sitting at 45-50ms CPU calculation time for 100 units - that's roughly 15-20fps and essentially a slideshow. Part of this massive performance drop was due to a bunch of overlapping systems that we had implemented that all ended up being replaced by one. Because we wanted each minion to be completely independent, we were calculating everything on a per minion basis - where to stand, who to attack, proper spacing for larger packs, pathfinding logic. The biggest offenders were anything that took into account the relationship between one minion to all of his/her friendly minions. In these cases, we had for loops iterating through each minion, performing logic and calculations based on information gathered from every other minion in the same mob. Obviously this exponential increase in calculations doesn't work so great when you need to make these calls every frame so we took the code to the chopping block and came back with all the excessive systems cut; relying now solely on the Unity collision system for keeping units spaced apart logically.

As they say, "With great power comes great responsibility". Unity collisions are quite the double-edged sword as we have all too readily discovered. Although they simplified the logic side of things from the minion perspective, colliders have a giant performance hit associated with using them (and we're talking just basic circle/square ones). We started off throwing every single specific type of collision we wanted to have into it's own layer - this way we could control exactly which objects collide with what. This ended up being extremely nice to manage and optimize for...until we realized we could only have 32 unique layers (of which 8 are unity reserved I should add!). So out the window went that idea and in came rounds of consolidation and simplification of layer interactions. Eventually we boiled it down to only needing 20 of 24 maximum layers and this is where Dominature currently lies.

Other improvements we made were sticking limiters on most of our heavy calculation functions. Although it might seem like you need to call logic every single frame, the reality is not even close. Due to human processing lag (the time it takes for your brain to make sense of the image it's receiving), having logical updates every .09-.11 seconds ended up being optimal for Dominature. We also add in a slight random aspect on calls that might be executed multiple times in quick succession - telling units to start thinking about a new movement location for example. With the very slight random factor in the time of calls, when 400 units need to call the same function they do so at different times to prevent a bottleneck of performance.

When you look at Dominature and realize that the game is currently running at 60fps with 400 minions all on the screen engaged in war, it's hard to remember that the game is running entirely on the CPU and only using a single core. In the near future, we're looking to move the physics onto the GPU via 3D colliders instead of the 2D ones we currently use, and have seen that unity is offering multi-threading optimizations of their own come later in 2017. Here's to hoping Dominature gets to take advantage of some of the sweet new tech and really see how many minions we can max out at and still be functional.

I hope you've enjoyed gaining a bit of insight into our technical design process and the challenges we've had to go through on the way. Remember to stay tuned and follow us on social media for the latest updates on Dominature! We love you guys and the support you've shown us during development :)

- Ryan

Featured Posts
Check back soon
Once posts are published, you’ll see them here.
Recent Posts
Search By Tags
No tags yet.
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • YouTube Social  Icon
bottom of page