The new input system moves away from statics and implements a dedicated control object, for this script, this is the playerControls.
Let’s take a quick look at our Move Action in the PlayerControls
First, you have an ActionMap. In our schema, we’re using several action maps rather than putting everything under one action map. Our ActionMap in this case is the Movement, so
playerControls.Movement
is a direct reference to the Action Map Movement.
On the Action Map, we have a Move Action (ignore the mousePosition, that’s just in my project as I took a different approach with the mouse pointer). That Move Action is where we get our input to move, so
playerControls.Movement.Move
represents the Move Action.
Finally, we need to know what the value of Move is. We know that Move is an Action which is a Vector 2, where x is the left/right and y is the up/down. We need to Read that value. For that we use ReadValue, and we have to specify what type that value is.
movement = playerControls.Movement.Move.ReadValue<Vector2>();
So now movement is a Vector2 which we can use in our movement calculations.
Now that we have our movement value, we can use it to move. While we cached movement in the Update() method, whenever we’re dealing with a rigidbody, it’s better to do the actual movement in FixedUpdate. Unlike Update, whose firing is more or less depending on our frame rate, FixedUpdate tries to run at a very set interval to keep physics calculations as smooth as possible.
So let’s break down the method:
rigidBody.movePosition()
This method moves the GameObject to a specific position in the game. If we were to use transform.position, we would be fighting the Rigidbody2D, so it’s best to use rigidBody.movePosition(). This method takes in a Vector2, which is what we’re putting together. We’ll focus on that complex math next.
We start with the current position, because we’ll be adding on to that.
rigidBody.position
Next, we need to know how far from that position we want to move.
We could use
rigidBody.position + movement
but that wouldn’t be framerate independent. We want to scale movement to Time.fixedDeltaTime
rigidBody.position + movement * Time.fixedDeltaTime;
But this calculation would leave us only moving one unit per second, which is probably a bit slow. For that, we have a speed variable,.
rigidBody.position + movement * speed * Time.fixedDeltaTime;
Now I’m sure you’ve seen those confusing memes people like to post on Facebook where people argue about the order of operations… for example
7 - 7 * (2 + 4) = ?
Is the answer 6 or -35? Oh, however will this dilemna be solved. In C#, the order of operations is the one that us older folks were taught with the old PEMDAS (Please Excuse My Dear Aunt Sally) or Parenthesis/Exponents, Multiplation and Division, Addition and Subtraction.
So the silly math problem becomes
7 - 7 * 6
7 - 42
-35
The same thing happens with our calculation for the move
rigidBody.position + movement * moveSpeed * Time.fixedDeltaTime.
In this case, the movement is multiplied by moveSpeed and Time.fixedDeltaTime before being added to the rigidBody.position.
I know Stephen packs a lot of information into the videos. There’s a lot of meaty stuff to learn in the course, and we try to keep each lesson relatively short. Even when I worked through a course, it’s pretty hard to keep up with the instructors if you’re typing away and setting things up while the video is playing.
I like to play the video in sections, pausing where I need to and updating my code or Unity setup, and yep, even a veteran like me will rewatch a video several times so I know just what the instructor is trying to show us. Keep with it, and feel free to ask questions, we’re here to help!