Simple Player movement in Unity
Objective:
Make a player object move from keyboard input from a user.
When we go about the business of “Software Engineering” its best that we break things down into small chunks of what we’re trying to do. For me, the best way is to pseudo code it, implement it and optimize it.
Pseudo code — fake it ’til you make it:
I love pseudo code — ok, I love actual working code more, but I love to start with what it is that I need or want to do. This collects my thoughts on what I’m trying to do and if I don’t know how to do it then it gives me some direction on where I need to search. Since I know very little in Unity, a quick Google search on “player movement from keyboard input in unity” gets me to the Unity API docs, perfect! Since I’m learning hitting the actual API docs is exactly what I need to get precise info for myself vs reading someone else’s tutorial — I highly suggest you start to practice the same, after you read my tutorials first 😉
https://docs.unity3d.com/ScriptReference/Input.GetAxis.html
I see there’s a static method for GetAxix that looks exactly like what I want. Although I’m making my game for keyboard input, why not be forward thinking and also not have a bias in my code for folks who may use a Joy Stick, etc..
Variables…:
Some folks say one of the most difficult thing in programming is naming things…and they are not wrong 🤣🧐 In Unity your variables are bound by the rules of the C# programming language and variables have a scope — Scope basically boils down to where can a variable be accessed. For our Player class we want movement related variables “local” to the class…so for example, we don’t want that Enemy to be able to change our Player properties. So we use the private keyword. There’s a catch though, what if we want game designers to be able to modify variables in the Unity Editor, we don’t want them to touch our precious code and mess something up right?! Right. And Unity has us covered with a [SerializedField] If you don’t know what that is, read the doc: https://docs.unity3d.com/ScriptReference/SerializeField.html
With [SerializedField] on your private variables the Unity Editor exposes these in the UI for people to modify on the fly, without having to code anything or recompile!
Here, I wanted to be able to play around with player movement speeds to get a value that feels good to me. Designer’s are going to do the same as they playtest designs and tweak systems.
This gets to the hard part “naming things” with variables. As a convention use and underscore _ to signify this is a private variable. You don’t want to have to scroll up to see which variables are public or private — trust me your future self will thank me, so will your collogues! We also want to use a descriptive name for the variable — I chose to use something verbose because I don’t like to guess. I could have just used _speed but what is “speed”? I could assume that it’s the player speed but what if it is the speed in which special abilities cooldown, or shields regen or firing speed? Err on the side of verbose so you (and others) can actually read your code rather than pick it apart to understand it.
Implementation — Player Movement:
Now that we’re armed with Unity’s knowledge on how to get user input with Input.GetAxis("Horizontal") and also reading up on how to move things around (exercise left to the reader here to go find and read) I’m ready to work on the implementation of player movement in my game.
Below is my code implementation that covers left/right, up/down movement as well as some extras: bounding the player’s movement top to bottom and “warping” the Player object when getting to far left or right. This is my “refactored” code. I didn’t just come up with this on my first attempt. I did have branching code, which is less optimized (check this YouTube video). Below you’ll see no if's, well crap okay, one if but I’ll sleep just okay with it. I also left some notes (aka comments) for my future self on why I have the code I have. Comments are good, don’t let a bad Tech Lead tell you otherwise, cause if they do, they’re not that good — or just an ass. It’s never a bad thing to comment something that doesn’t jump out to folks as plain obvious.
You can see this code in action by playing my game (it may look different when you revisit it) here: https://joseph-youngquist.github.io/space-shooter-pro/
