Hello Riftbreakers!

We often mention optimization in our articles, release notes, and other interactions with you. It is one of the pillars of programming. It is usually not a problem to program the computer to do something for you. It is much more of an issue to make the computer do what you want quickly, without using 100% of CPU/GPU/RAM while at it. The Riftbreaker is a collection of thousands of such features. Making sure they all play nice with each other often takes more time than developing the feature in the first place. In today’s article, we would like to show you that optimization comes in many forms and is never an afterthought but an integral part of the development process.

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/640734b237241b553735350555b6f355.webm?t=1756478584[/video]
Just like you strive to optimize your bases, we are constantly fighting for every bit of performance we can get.

If we had to define optimization, we would say that it is the process of finding a compromise between functionality and resource utilization. You want to lower the performance cost of a feature while maintaining the intended function. One of the easiest examples of that is how our 3D models are made. First, our artists sculpt the model with very complex geometry. Polygon counts for our raw models can easily reach millions. If we wanted to use such models in-game, the GPU would give up after displaying just a couple of them at one time, let alone if we wanted a horde of such creatures.

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/f90d5e04e5f248805ea5fdc04095d7ec.webm?t=1756478584[/video]
A typical late-game attack wave is just about this size, maybe slightly smaller. Displaying so many enemies is not an easy task.

However, since The Riftbreaker offers only a top-down view with the camera mounted at a fixed height, we can get away with lowering the polygon count. After the initial model is accepted, the artists create a low-poly model with simplified geometry. Sphere shapes become less spherical. Angles become sharper. Legs start looking like sticks. You are unlikely to notice these things at a distance of 25 meters (that’s how high our camera is), but they make models easier for your GPU to handle. This process can reduce the polygon count from millions to thousands (single thousands, like 9001, for example). Optimization makes it possible for us to send epic hordes at your base - in more ways than one!

These two images portray how the original models differ from game-ready ones. All the details our artists sculpt are not lost in the process - they are replicated via normal mapping.

Another method we use for creature optimization never appears on your screen, but it is essential to the game’s operations. Maps in The Riftbreaker are quite large, with many naturally occurring obstacles sprinkled all over the place. If we want an enemy creature to reach your base, the game must calculate its path that does not violate the rules we set. Most creatures can’t fly over walls and canyons, for example. Moreover, the navigation system must refresh this path several times per second to account for changes in the game world. Props can be destroyed, altering the optimal path quite dramatically. That sounds like a lot of work already - now multiply it for every single creature and enjoy the slow motion because the PC can’t keep up.

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/e9ebbd0fc5502ba3b3fdd1e9682097f6.webm?t=1756478584[/video]
This is a video from 2018 showing creature navigation in its simplest form. The creatures must reach the target (the base) only using available grids and avoiding blockers. Sometimes creatures may block each other, requiring them to look for another path. So much to calculate, so little time.

To solve this problem, we decided to divide the game world into 64x64-meter zones. A zone can exist in two states: active or inactive. If the zone is not covered by the “fog of war” or within radar coverage, we consider it “active”. Enemies located in these zones run a full navigation simulation and are always ready to headbutt your walls. Units in inactive zones are “packed” - the game knows they should be there, but they do not take part in the simulation of the game world. When you approach an inactive zone, we unpack the units so they can take an active part in gameplay. It’s similar to a game of chess. The board is divided into squares. Game pieces can take any of those squares, but you don’t have to calculate all the possibilities at all times. You just have to figure out which pieces are relevant right now and count the possible moves for those (and then blunder your queen anyway - just play Gambit Sandomierski. It's OP). Thanks to this, you free up a lot of mental resources - just like packing creatures saves a lot of CPU power that we can utilize elsewhere.

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/dc6d107adc65b3902e24591bed46045b.webm?t=1756478584[/video]
It's hard to show what this 'packing' process looks like, but we could see glimpses of it in the days of early multiplayer beta - you could sometimes see empty husks of creatures with stuck animations. They had no hitbox, no health, almost nothing, really. They simply existed. Mr. Riggs could get stuck like that as well!

One last bit of optimization we would like to share with you today concerns the economics of your outposts around the planet. If you’ve ever built a base with lots of pipes, factories, power plants, and defensive structures, you might have noticed that time slows down a bit. This happens when the calculations for all the systems related to your economy are so complex that they exceed the 33 milliseconds allocated for updating the gameplay state. It is a deliberate choice - by lowering the game's pace, we allow gameplay calculations to catch up with rendering, which is often several times faster (the alternative was to drop frames, so we chose the lesser of two evils). Now, imagine if you had several such bases, scattered all over the planet, and wanted to update their status in real time. We would never make it in 33 milliseconds.

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/7f5819f71dc681aeedd8526f8d7a0442.webm?t=1756478584[/video]
Building ginormous bases got easier with the addition of multiplayer. If we had to run real-time economy for all your huge outposts, we would probably need to call CERN, NASA, and other four-letter institutions to do calculations for us.

We considered many optimizations, but none of them worked. They either affected the feature’s functionality or had limited performance potential. Without additional months of development, we wouldn’t be able to dynamically track conditions at your outposts. We had to make a compromise and chose fun over realism. Whenever you leave your outpost and travel to a new planetary location, the game takes a snapshot of your base’s economy. Based on that snapshot, we simulate a simplified version of your outposts. Your factories keep working, and depleting the resource deposits they need to operate. Once the deposit is gone, the production stops. Moreover, power is not taken into account. Thanks to these simplifications, we don’t have to update the full economy every frame. This already is a radical solution, but it’s not the entire story.

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/9096ddff3abb8530adffaad966da7551.webm?t=1756478584[/video]
Galatean creatures are so nice that they will wait until you're home to come to your doorstep.

We also decided to prevent enemy attacks while you are away from your outposts. Early on, we planned those remote outposts to be targeted by enemy hordes from time to time. You would have to come back and repel the attack, or leave it alone and accept that some of your buildings would be destroyed. That would also force us to update the outpost simulation much more frequently, leading to even more issues. After talking this feature through amongst ourselves and discussing it with you, we decided to let this feature go. It allowed us to limit the simulation to the economy alone and remove a potential pain point, all in one go. In hindsight, this was the best compromise we could have made. The Riftbreaker is complex enough without forcing players to babysit several outposts at once!

[video=webm]https://shared.fastly.steamstatic.com/store_item_assets/steam/apps/780310/extras/89848b12d935e54cd89eef3aa5686b33.webm?t=1756478584[/video]
We decided to get rid of attacks on remote outposts in your absence for simplicity's sake. From what we heard - it was a good decision.

There are hundreds of examples like that. Each of our programmers could spend hours talking through the optimizations they have introduced. Our 2.0 Update alone required them to revisit almost every piece of code and adapt it to online play, which was usually synonymous with heavy optimization. We hope that, thanks to this article, you will now know that optimization is never an afterthought. It is an integral part of software development. If you’d like to learn more about this or any other aspect of game development, feel free to ask us questions here and on our Discord server at https://www.discord.gg/exorstudios. Also, remember to sign up for our newsletter right here.

EXOR Studios