Monday Musings #54 – Performance Deep Dive

Happy Monday!

Many players have been asking about MoteMancer's specific plans for performance improvements, I'm happy to say the current Experimental branch is live with the opening salvo. No plan survives contact with practical reality, and MoteMancer has had quite a journey in that regard. I'd love to share some learnings today.

If you want to experience the improvements for yourself, jump in and check it out! What follows is going to get gritty.

More DOTS

Unity has this super cool system called DOTS or ECS (Entity Component System). I'm not going to get into the nitty-gritty details other than to say - yes it is quite magical, yes you can get insane performance gains like 1000x or better. The way it achieves this is by having very specific rules about where processing happens on your hardware and what objects it is allowed to affect.

Even at the start of MoteMancer I had tagged this technology as my future. A few months ago I dove right in, having built up the confidence and programming chops to tackle the new coding style and found out... ECS officially only supports 3D objects, which is not MoteMancer's pipeline. This may not have been a problem except that needing to render multiple planes simultaneously makes extensive use of stenciling, which is natively supported by Unity's Sprite Renderer, and not by the new system.

Suffice to say, many significant hurdles were found for the specific cocktail of rendering that is MoteMancer, much less all the fancy UV scrolling effects that are already present, let alone what’s planned for the future. We need another approach.

Back to First Principles

The most important thing you can do for solving any efficiency problem is identify ways to optimize over 50% of the work. What can you skip, how can you improve the most expensive part?

MoteMancer's frame rate holds up very well until you get to about 40,000 structures, give or take. And most of the slowdown comes from just the sheer number of belts and arms checking things every frame to see if there's something to move.

The first thing to notice, now that the logistics system is largely complete, is that the transit time of a given entity does have a floor - the time it takes for a single item to transit a single slot in a Streamway (.125 seconds). Ok there's one structure that is faster, which is a torrential streamway (.08333 seconds), but we'll get to that in a minute.

This means that we can finally nail down a tick rate for the game, albeit a strange one. Many games land somewhere between 4-15 ticks per second depending on their needs. Using the information above, MoteMancer is going to use two different tick rates, 8 and 12 per second, which nicely have a common denominator of 24.

24 is super close to 30 frames per second (which would be close to negligible) but its not a number we're using directly, it just ensures that there's commonality in the system.

This means we only need to calculate 40% of the frames for Torrential Streamways and 27% of the frames for everything else. This has some other large benefits because any background processes like garbage collection can happen during shorter load frames, giving the system an opportunity to drain the cache before it compounds faster than it can alleviate.

Idle Hands

Ok, that was a lot. Let's zoom out for a second.

Another super deep cut we can take is realizing that in many cases, your Factory is not actually doing anything. Belts are saturated, structure outputs are full, you are spending time thinking of ways to expand while the factory eagerly awaits kicking into motion again.

Apart from Infinite Research, all production lines will come to a halt eventually. There is no other endless sink in the game. Crucially though, that wouldn't stop every machine from trying to do its job - even checking whether a Gripper should pick something up starts to add up when you have literally thousands of them. That is, until now.

Fundamentally, production structures already tell grippers not to pick something up if the result would overfill the input inventory. We can simply take this one step further and have the production structure literally turn an input gripper off until it needs to wake it up again. When any structure has a full output inventory, there is no reason for a gripper to keep trying to fill the input inventory.

This does get scary, because there are many edge cases that need to be accounted for. Telling a vital part of your factory to just turn itself off risks the trigger to turn it back on breaking in some way. But, realizing that at any given time, a double-digit percentage of your factory is probably idle means you get a framerate much more in-line with what parts of your factory are actually operational rather than being taxed just because something has been placed.

Both of the above are great examples of our initial goal of finding ways to skip large swathes computation before it even starts.

Looking Forward

I’m going to be shifting to fewer, more meaningful deep dives while I finish the game. So much of the work left on MoteMancer is in this space - very specific, very technical. I will still be updating the game regularly with whatever is hot off the press, whether the full retail build or experimental, so be on the lookout for updates there. Thank you for being along on the journey, we're officially in the home stretch.

Back to the Lab! 🌿 ~CyanAvatar

PS - One last huge thank you to players that are providing the final-boss bases to performance test against. If you have a large base with a low frame rate, send an F1 and it'll be added to the testing pool!