Last time, we were talking about how to read phone input, and we concluded that none of the motion-sensing tools available in the API would suit our needs, because none of them took starting orientation into consideration. Additionally, testing showed that it's extremely difficult for the average player to keep one movement axis steady while moving along the other, leading to undesired drifting onscreen. I decided it was better to limit the acceleration controls to the player's up/down movement, and find a different solution for left/right, or, more accurately, increasing/decreasing speed.
Now, you'll also remember from last time that there aren't a lot of other options to choose from on mobile: taps, swipes, and button clicks. I'm already using a tap for shooting torpedoes, and I didn't think swiping would make a lot of sense for controlling speed. In fact, I considered changing the torpedoes to a swipe motion so I could repurpose the tap...but I ultimately decided against this because of desired use. The shooting in this game takes a long time to recharge (by design), so you won't be able to constantly spam it. Instead, it's meant to be used as a last resort when you just can't dodge out of the way of an obstacle fast enough, when it's immediately upon you. I felt that swiping had the potential to be too slow and too inconsistent to be used in these cases, when you really need it to work, and instantly. So, all that said, my remaining option was to use onscreen physical buttons for speed control.
Which, of course, raised some new challenges. Take a look at the original UI layout:
It was a struggle to come up with even this. There's a lot of stuff that just simply needs to be there: indicators for sub health, torpedo recharge, distance traveled (base score), treasure collected, and of course the pause button. I wasn't sure where to put any of it, because I wasn't sure where it would be the least distracting. Remember that obstacles will be moving in from the right side of the screen; would it be better to put more of the UI there, so the obstacles are "blocked" for another brief moment right after appearing, but then clear afterwards? Or should I load up the left side, so that by the time the obstacles get there, you've had long enough to plan your dodging that it doesn't matter that they get "obstructed" on the exact part of the screen you're trying to avoid them? Or, should I move as much as possible to the middle of the screen as a compromise? In the end, I put everything where you can see it above because of the numbers. They will both be expanding to the right, and having them do so when anchored to the right side of the screen looked weird. It was even worse with them in the center and constantly moving ever-so-slightly to re-center themselves there. So I kept the numbers on the left and balanced everything else around them.
But now I needed to add the speed buttons to the mix. The obvious first idea was to use buttons that were the full screen height and just center them along the edges, like so:
I was afraid that this didn't really fit well, aesthetically. First was the button shape itself; if they were going to stay full-height, I didn't have a lot of options for cute shapes like the bubble buttons I'm using elsewhere. I needed them to be mostly transparent so I wasn't obscuring even more precious screen space (in fact, I thought they probably needed to be even thicker than pictured here for easier clicking), and I didn't like how they overlapped the other UI. You'll also notice that I moved the sub forward a bit so it wouldn't overlap either...but that meant less time from obstacles entering the screen to needing to dodge them. I created a second variation with buttons that weren't full-height, but stopped right before the other UI. That looked even tackier.
Another option involved a lot of switching around. If you're holding your phone the way I want you to while playing my game, you're sort-of gripping it with your palms, thumbs pointing upward or away from you. So if you need to then use them to press buttons on the screen, the best place for them is right at the top, where your thumbs are already hovering:
This might even help the button shape, since now they could be converted into bubbles or another non-rectangular shape fairly easily. Of course, this meant that the other UI had to be moved to the bottom, resulting in quite a bit of it along that left side. Even so, this was the best layout idea I'd had so far, and probably would have been what I went with, were it not for one more little nagging thought: the speed adjustment is an entirely optional feature, and I'd bet that most players will either only use the slow-down or ignore it completely. These dedicated buttons all-but force it upon them, and again, take up precious screen space to do so.
A last solution was proposed by a former teammate, who suggested I use invisible buttons which fully covered the left and right halves of the screen, respectively. I had already considered this as well, discarding the idea because it would interfere with the shooting mechanic. But I wondered if there was a way I could include the functionality without using official Unity buttons (which block other input when clicked). Perhaps I could:
-Determine if a touch is a "tap" or a "hold"
----If a tap, shoot the torpedo
----If a hold, determine the side of the screen it occurred and increase or decrease the speed accordingly.
Luckily, Unity's Input class comes with a TouchPhase enumeration, so you can get events similar to the regular KeyUp and KeyDown, and it was easy to determine how long the screen was pressed and if the input should be considered a "tap" or "hold". Implementing this was actually much easier than expected, and the only final snag was making sure to read multiple touches at once, so a player could shoot while in the sped-up or slowed states.
I'm happy with this solution. The UI still looks like the first picture above, and the functionality is there, but sort of hidden, which I like a lot. Most importantly, it feels natural to control, and for a casual game, that's crucial.