The challenges of tablet

Last week we removed our most complicated input system and successfully got something playable onto tablet. However, we've spent an entire semester with PC as our target platform; it stands to reason that we'll run into more hurdles as we further explore our new platform. This week's challenge was managing our newly restricted resources. On tablet, you have both less memory and less processing power than on PC, which means you get frame-rate slowdown with a lot less going on. However, on the tablet build some of our levels began to noticeably chug after a few minutes of play.

I looked at the offending scenes using Unity's profiler and found out the problem was with all of our energy units. Currently, planets will produce energy pellets at a set rate if charged, and will produce them indefinitely while charged. Although we had never ran into issues before, it stands to reason that a system forever increasing in complexity will eventually hit a ceiling; we had simply been lucky enough to avoid it on PC. So, I spent the week looking into ways to make this energy generation take fewer resources.

The obvious solution (well, second most obvious, but we'll get into that in a moment) was to disable the rigidbody physics on energy that didn't need it. Our energy pellets have rigidbodies attached because they use physics forces to move when fired, and are affected by gravity, another physics force. However, when an energy pellet is sitting on the surface, it doesn't need physics to affect it until it leaves the surface. Disabling the rigidbody while energy was on the surface seemed a simple solution.

However, this caused a few complications. First off, rigidbodies can't be directly disabled, unlike most other Unity components. To another man this might have seemed a pertinent warning, but I plowed on ahead. Rigidbodies could be removed entirely using the RemoveComponent command. Although it might make re-adding a challenge, this would at least work for a baseline test.

Something funny happened with this test, though. Under normal conditions, we found that on the PC it took about 600 energy pellets in our test scene to get slowdown. Once we started removing rigidbodies, however, that number plummeted to 200. I'm still not sure why removing the calculations Unity has to perform on an object made it significantly less efficient; perhaps there was some code somewhere else referencing a now non-existent rigidbody in a way that didn't throw an exception but still messed things up, or perhaps Unity optimizes rigidbodies very well already behind the scenes. Regardless, it seemed like this was not going to be a fruitful avenue of research.

Thankfully, not every technical problem needs a technical solution. We already had a function written that prevented charged planets from producing more energy if they had a certain amount already on their surface. By using this on every planet, we could set a hard cap of the amount of energy allowed in any given level. By setting this cap lower than the amount that caused problems, we could prevent those problems entirely. So, that's exactly what we did. Another victory for simple solutions.