In our blog post this week, we’re going to talk about our mobile control schemes, specifically how they’ve changed and why over the development cycle.
Initially, our control scheme was quite different, and functionally identical to what we had in Hopper, Star Escape’s Game Jam predecessor. Players would have a static joystick to the left of the screen that could be used to move Ihp around planets, and ability and jump buttons to the right. While it wasn’t a problem for desktop versions as they had no need for visual representation of controls, having both jump and ability buttons was taking up too much mobile screen real estate for our liking.
Our first idea to try and fix this issue was to have the ability button to be the same as the jump button, with the button’s functionality changing between jump and ability depending on whether or not Ihp was on a planet or flying in space. While this did reduce screen clutter, it also meant that you weren’t able to use any abilities when you are on a planet at all. It also limited our item design options and wasn’t necessarily clear to new players. As a result, we scrapped the idea pretty quickly.
This idea of reducing the number of buttons on the screen led us to removing the jump button altogether and effectively attaching its functionality to the joystick. The first iteration of this scheme functionally made the joystick a “slingshot” similar to what you see in Angry Birds. Rather than pulling towards the planet you were aiming at, you would pull the joystick in the opposite direction. This worked pretty well, but we realised that it was much easier to aim by dragging the joystick in the direction of your jump instead of against it.
While we’re pretty happy with this, it’s not completely optimal either. Since Ihp’s planetary movement and jumping capabilities are being controlled by the same joystick, it’s no longer possible to move around a planet without charging your jump. Thankfully, this wasn’t too much of an issue in practice, since we were always trying to charge up when moving anyways.
Since then, we’ve made further improvements. To start with, we made our joystick non-static, meaning that as long as you pressed down on the side of the screen the joystick was on, the joystick would snap to your finger, giving players greater flexibility.
We also added an option that allows players to swap which side of the screen the joystick and ability button are on in the settings menu, as you can see below.
You’ll notice that apart from the Left-Right buttons and usual volume controls, there’s another slider in the menu. This controls UI opacity. We implemented this to deal with a few new problems the non-static joystick was inadvertently causing.
During the game, players are usually swiping the joystick to the right. Combined with players subsconsciously continuing to press on the non-static joystick’s current location instead of where was most comfortable for them, there was an unintentional consequence: the joystick tended to move towards the centre of the screen. This led to three issues. Firstly, players were stretching their thumb further to reach the joystick, which caused unnecessary strain over time, especially on larger mobile screens. Secondly, it meant the player’s thumb and joystick would cover Ihp and make it harder to aim. Finally, since the joystick only registers presses on the half of the screen which it uses, players could accidentally tap on the other half and activate their item instead of triggering joystick control. The opacity slider fixes these problems by letting players tone down the visibility of the controls if they find them too distracting.
This has led us to what our control scheme looks like-or doesn’t, if the player so chooses-today.
I hope you found this explanation of our control scheme design process interesting.
Thanks for reading.