Entry 06 - Joy with Joysticks
My sixth post, where I go into my experience setting up the inputs for this game.
After finishing the main menu last week, I decided to take a look at implementing compatibility with joysticks for our game. It was something I figured was best to be tackled early on, I also felt it was something essential for a platforming game.
Setting the Inputs
My first task was to edit the built-in inputs found in Unity’s Input settings. A very useful feature, it allowed me to designate the inputs of the game as I saw fit, I could name them what I wished, add as many as I liked, etc. I took the opportunity to decide on all of the game’s controls then and there. Below is the list of all of the game’s inputs so far.
The entire list of the game’s inputs.
You’ll notice that there are two of each input in the image above. The reason for this is that, for each button, there is an input for keyboards and an input for joysticks. Both inputs are named the same so that, when coding, if I specify “BtnA”, the name will apply to both inputs. This means that the input will be read regardless of whether the player is using a keyboard or joystick. Below is a closer look at the two inputs for one button.
The vertical directional button’s inputs, the above for keyboard, the bottom for joystick. Note the differences highlighted in orange.
As can be seen above, the most notable differences are seen in the “Gravity”, “Dead” and “Sensitivity” fields. It took some research to find out which values for these fields suited a joystick and which values suited a keyboard. For instance, the Gravity and Sensitivity are set very high for the keyboard buttons since we want them to become inactive as soon as the player lets go of them, whereas the joystick’s axis detects input over a continuous range of values.
For a clearer picture of how I’ve set out the game’s controls, below here’s the layout of our controls mapped onto the Xbox 360 controller, a joystick most commonly used with PCs.
Our controls at this point in time.
As seen above, directional movement of our character is manipulated with the axes on the bottom left of the controller. Players often prefer to use the analog stick above this directional pad, so in future I will likely duplicate the directional pad’s functionality and apply it to the left analog stick, giving the player the choice of using whichever axis they prefer for movement.
The Problem I Encountered
When first setting up movement with the axis, I used my main menu as the area for testing input. Right away I noticed a major issue: pressing down once on the joystick’s D-Pad would move my highlighter all the way to the bottom menu option. After some research I realised that, since the D-Pad was an axis and not a button (with continuous input detection instead of discrete), the game was detecting my input multiple times per frame and hence making menu navigation next to impossible.
After a lot of research as well as trial and error, I finally derived two methods that solved the problem for me. The methods make use of a bool called “axisInUse”. When the player presses on the axis, the input will only be read if the aforementioned bool is false.
The first method reads the input and sets the bool to true, helping the input to be read as if it was a button press.
The second method is constantly checking if the axes are still in use, if they are not in use, the bool is reset, allowing for further input from the player.
Overall, I’m happy with how the inputs for the game have been set so far. I think it’ll stand to us in future for when we’re implementing the gameplay mechanics our inputs will manipulate. Of course, it’s also good to remain vigilant for any further input issues that could arise.
As for next week, I’d like to start working on some content for the level, first though, I want to tackle a bug I’ve spotted in my main menu.
‘Til next time!
