Optimization: The Quest for More Frames

I do most of my work for Unto the Breach on my personal desktop, which is a mid-to-high end gaming PC (Ryzen 5 3600, 32 GB DDR-3200 RAM, RTX 2080, etc.). Occasionally I'll do work on my Surface Pro 6 though, like when I'm traveling or just want to lay on the couch instead of sitting in my computer chair for hours on end. Normally I do just coding or database work on the Surface, and almost never actually do a test play of something. So I had a bit of a shock recently, when I tried to fire up Unto the Breach to test out the dialogue and eventing for a new scene.

OH GOD IT BURNS!

The framerate suuuuuuucked! I'm talking single digits here, even on a map that was barely the size of the screen, so there were virtually no events to bog things down. Granted, as far as gaming goes, my Surface is barely a few steps removed from a potato (It even struggles to run Jackbox games smoothly, and those aren't exactly hyper-realistic graphics or anything). But it made me realize, not everyone's rocking a RTX video card or high-end RAM, either. And, if I had to be honest, even on my gaming PC, the game occasionally chugs a bit.

So I started testing the various plugins installed to the game, trying to figure out which ones were destroying the framerate. Eventually I tracked it down to a couple specific ones (and was a bit surprised when it turned out to not be the ones I initially suspected it would be). Which in turn led me to discover those plugins were more symptoms of a larger issue facing me. So now I'm on a (kinda) epic journey to overhaul how the game does updates.

In a nutshell, the game runs an update process 60 times a second (by default in the engine this is actually tied to your framerate, but one of the plugins I have decouples it and makes it a consistent 60 times a second which makes way more sense from a programming standpoint). This includes everything from rendering graphical changes (in fact the entire screen is re-rendered every frame), to updating object properties (anything from character stats to sprite colors to event positions), to handling player inputs, to loading new files (graphics, sound, etc.), to a bunch of other stuff. It is, quite simply, a LOT of data to crunch. Unto the Breach is over 85,000 lines of code long, split across hundreds of classes and methods. There are a LOT of classes getting called during the update process. Some take less than a millisecond to finish, others take...longer.

---

Much better! Though I'm still not getting this everywhere...

Now the challenge becomes, how do I optimize this so each update call isn't nearly as resource-intensive? Due to the way the game's structured, it's primarily CPU-driven, and while the integrated Intel graphics on my Surface are definitely slowing performance, it's more the low-end CPU (a dual-core i3) that's struggling to keep up. I updated the Pixi library from version 4.5 to 4.8, which definitely led to some performance improvements, but not nearly enough for a low-end system. After that, I started to analyze what exactly is called during the update process, and try to figure out if the game REALLY needs to run through all these classes every single update cycle (for instance, I'm not sure the game necessarily needs to fully re-render every graphical element when those elements don't change between two given frames, e.g. the map terrain layer when the player is standing still).

I looked at the plugin that was the worst offender for bogging down the update process, the party HUD that shows up when you're walking around. Turns out the process I added to make the HP/SP bars animated was surprisingly resource intensive. But also I discovered the HUD goes through its own full update cycle every frame, even if it's currently invisible. So I altered the plugin to essentially skip the update cycle if it's invisible, and removed the animated HP/SP bars for the time being until I can think of a more efficient way of handle them (or possibly make it an option in the graphics settings menu). And just like that, my framerate on the Surface went from 6-8 to 20-25 in the most problematic areas.

But that's just to start. I won't be satisfied until I can get a smooth 60+ frames per second on my Surface, because then I'll know for sure that the game will be able to run effectively on virtually any system out there. And also mobile devices (I'm told RPG Maker MV is notoriously bad at mobile performance), should I want to port the game to there. It is definitely going to take some work, though, as I sort through these many thousands of lines of code. Good thing I enjoy making things better!

---