In the last part of this I talked about how I set up the API to handle multiple control schemes and how I set them up to be able to swap at run-time, here I will talk about the actual control schemes and their implementations!

So you may be wondering, what were the three control schemes? The first one is a basic tank controls, forward / backwards is on one stick and rotation on another. The second is similar to the first however all directional were on the left stick, but the right stick could be used to override the rotation if needed. Finally the third was having everything on one stick, however movement was relevant to the camera’s position instead of the players.

Previously we have been using the first layout, so I was tasked at implementing the two new ones for QA this week. Firstly lets look at layout B, this was a relatively easy fix, all I had to do was implement an override for rotation if input was detected on the right stick.

Here you can see the starting section of our move player movement, with the xAxis variable in this case handling our rotations. xAxisMove is the first rewired axis input, this being bound to the right-stick in this setup, xAxisAim is the rewired axis input being got from the left stick (the override) in this case. Simply put if there is any input at all the variable is then set to the second input, replacing the first. Then this is passed along to the rotation function and everything acts the same.

Unfortunately layout C required it’s own function to work, as it is fundamentally different from the other two control schemes.

Here you can see the override for the function, since layouts A & B use the same functions we only care if the map is set to C, if it is then we use the new function.

This is a fairly simple movement algorithm, with the main difference being that the player’s movement direction is based on the camera’s rotation, so forward will correspond with the camera’s forward direction. The main challenge with this was that our current animation controller didn’t have functionality with this new movement scheme, we decided that it wasn’t a priority for this sprint and if we continued with this scheme we would polish the issues that it had. So the fix is to manually swap the diver’s direction into the direction of the velocity. This creates an issue where the diver’s rotation snapped to wherever they were looking and caused immersion issues. However this wasn’t a concern for now as we weren’t sure that it would feel good in the first place. That being said if we do go forward the fix would be to rotate the player towards the desired rotation instead of simply snapping to that rotation, a simple fix but not necessary for now.

All that considered… the third option was the winner for QA! Testers found that moving relative to the camera was the most conformable and felt the best. So going forward we are going to fix the weirdness and get it feeling fantastic, then hopefully I can move onto other systems to work on and have the diver feel good!

Thanks for reading!

-Alex Hubble