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.

New Control Scheme Adventures

One of the biggest problems SunBots had at the end of last semester was its control scheme. The game used a dual stick setup, with the left stick controlling movement and the right aiming energy shots. Although our primary testers (~20 year old gamers) largely found this setup intuitive, we got significantly different feedback from the professors who played our game during greenlight deliberations, who generally found the setup a bit unwieldy. A dual stick setup requires a very high level of hand-eye coordination, which clashes conceptually with the rest of SunBots, which is generally casual-friendly.

Additionally, our game very strongly gives off a tablet vibe, due to its colorful aesthetic and simple concept. However, our movement alone made our controls too complex to work on tablet. On a planet, the player can only move one of two directions, clockwise or counterclockwise. However, simplifying this to a binary input is problematic. Left, right, up, and down mean different things depending on where on the planet the player is. On the north pole right is clockwise and left counter, but the opposite are true on the south pole. This led to us creating a sophisticated series of checks to properly translate the left analog input to what makes sense based on the player's general position, taking 8 different possibilities and condensing them into the two real outputs.

Since tablets don't have any buttons or tactile feedback, their range of input is limited. You only have so many discrete actions possible before they begin to blend into one another. Taking our complicated movement system and porting it to tablet would leave us with a mediocre product. So, we simplified, and cut direct movement entirely. Movement on planets wasn't ever a core part of our game; it was more a means to an end, the end being solar system movement. Now, the player has a constant velocity when on a planet's surface. They can press a single button (an easy input to port to tablet, once we begin seriously building tablet controls) to swap directions. This system works great; it never feels like you aren't in control, since the important control takes place in space. It just goes to show the power of simplification and outside the box solutions.

SunBots Second Semester Funtimes

It's been a very exciting development process so far for SunBots. Ever since settling on a concept we've been off to the races, and it's somewhat amazing how solid of a product we have after only 3 months and 4 people. But now it's time to really get going; we've double in size and with an extra 4 months, SunBots could be amazing. We've already got some cool ideas about how to expand on our premise from our new members. I don't want to talk about them now since we don't know what we'll pursue and what we won't, but suffice to say we're going to be doing a lot of cool new things.

Since we've just started our second phase of development, there's not much to talk about so far; we're still figuring out what we want to do and who will be responsible for what. We've been doing some housekeeping; cleaning up code, cleaning up our repository, basically making things easy for newcomers to get into and work with. Expect some fun updates next week. I'm very confidant we'll have lots of cool updates.