Get moving in Unity
How to capture player input and use it to move a GameObject
So, let’s say you want to prototype a 2 or 2.5 dimensional shoot ’em up (SHMUP) style game in Unity.
Where do you start?
Well, assuming you have a fresh Unity project, you’ll likely start with a GameObject that represents the player’s ship.
Attached to that GameObject, you might attach a script, and that script would start out looking something like this:
One of the main mechanics in any SHMUP is movement. In fact, there are some SHMUPs where the only mechanic is movement. So, let’s kick things off by focusing on movement.
The most important thing we need to get our movement mechanic going is input from the player. Unity has a couple of different input systems, the UnityEngine.Input class, and the new Input System Package. This article is going to use the UnityEngine.Input class, as it has all of the functionality that we are going to need and doesn’t require any additional configuration. This system is very easy to use for single player games and basic control schemes. Since our game is going to fall squarely into both of these categories, we will proceed with confidence.
The system that we are using for input relies on an abstraction that Unity refers to as “Axes”.
Now we’re talking!
Wait, no. Not that kind of axe. Axes in this case is the plural form of axis, like the kind you might find in a Cartesian coordinate system.
Unity by default defines a number of axes that are mapped to various input devices that a player might use. For instance, there is a Horizontal axis that is mapped by default to the left and right arrow keys, with alternate mappings to the “A” and “D” keys. It also maps joysticks on gamepads, if you happen to have one connected. You can examine the default mappings that Unity uses by opening up the Project Settings and looking at the Input Manager.
Heading back to our script, we will add a bit of code to the Update() function to check and see if the player is interacting with the game in a way that we care about. We do this using a static method on the UnityEngine.Input class called GetAxis().
GetAxis() takes a single argument, a string representing the name of the axis to retrieve. It returns a float value between -1 and 1. In the case of the Horizontal axis (and assuming a keyboard as the input device), a value of -1 means that either the left arrow key or the “A” key is being pressed. A value of 1 indicates that the right arrow key or the “D” key is being pressed. 0 is the neutral value and means that neither key is pressed. If the input device were something more analog, like a joystick, the values would be more granular. For instance, if the joystick was held only halfway to the left, the value would be close to -0.5.
So now our script has the ability to discern when the user is interacting with any device that is mapped to the horizontal and vertical axes. Great!
Now what?
Well, I’m glad you asked. Fortunately for us, there is a construct in C# that can take these values and turn them into a direction that we can hand to a method that will move our GameObject around. Vectors allow us to define x and y values that, when used together, can indicate a direction in 2-dimensional space. The Translate() method of the Transform component takes a vector (Vector3 in this case) and shifts the GameObject in the direction indicated.
First, we take the input variables for the horizontal and vertical axes and pass them into the constructor for a new Vector3 object that we are then going to pass to the Translate() method. We use a Vector3 here even though we don’t care about the z axis as, in this case, this is going to be a 2D game.
When you pass the Translate() method a new Vector3 object, the object will be translated whenever the player presses the arrow or “WASD” keys on their keyboard.
Let’s try it out!
It works!
It’s erratic and impossible to control with any sort of precision, but when a player presses the keys, the object moves, so that’s it, article over.
Next time we’ll take a look at why our ship is stuck at warp speed and see what we can do to smooth out the experience for the player.
Until then, keep hacking away. And, as always, RTFM!
