In this lecture, we're going to get our player moving around the screen using the new unity input system.
Okay.
So in the last lecture, we imported our unity input system via the package manager.
So go ahead and just make sure that's fully installed and up to date and then we can go ahead and close
our package manager.
Now to get the input system working, we need to attach it as a component to a game object.
So let's go ahead and find our player in our prefabs folder and then add a new component.
The input system can be found under input or we can go ahead and just search for our player input system.
And once we've attached this component, we then need to do a bit of set up.
So don't worry too much about all these extra boxes and things or we need to worry about.
At the moment it's just creating some actions.
So let's click on Create Actions and this will allow us to create a new input action asset.
Let's give it a name and I'm going to go with input actions for now.
Go ahead and hit save and then open our root assets folder.
We'll have this new input actions.
We've also got a warning error coming up down the bottom, but don't worry about that.
We can just clear that off when we need to.
So let's go ahead and open up our new input actions asset and this will bring up the asset window.
Now, there's quite a lot going on in this screen, so let's just break it down one by one.
First of all, this is a new asset window.
And unlike when we change things in the inspector, if we make changes in here, they won't save automatically.
So at the very top we can see we've got to save asset button in case we change anything.
And then over on the right we have an auto save option.
So if you're like me and prone to forgetting that you've changed things in your asset files, then you
can always go ahead and enable the auto save.
I'm not going to worry about that for now because we're not actually going to be making any changes
for the moment.
We're just going to have a look around and get a feel for how things work.
So the main bulk of this asset window is broken into three sections.
We have our action maps on the left, our actions in the middle, and then the properties over on the
right.
So let's start by looking at the action maps.
You can see that by default we've been given a player action map and a UI action map and all an action
map really is it's just a collection of related behaviors.
So under our player we have the actions of move, look and fire.
And if we look under UI, then we have things like navigate, point, click, submit and cancel.
So you can create new action maps and this allows you to reuse the same key bindings for different types
of gameplay.
So you might imagine that in some games you'll have your player action map where you can run around
and shoot at things.
Then you may have a separate action map for driving or flying or something else.
Talking of key bindings, let's next look at the actions section of this screen and the actions contained
within each action map.
Essentially take the button inputs or the physical inputs from a device and ties it to an action that
we want to perform in the game.
So if we roll down the move action so we can see the actual key bindings themselves, we can see we've
got a whole bunch in here.
So we've got ones for the gamepads, for the keyboard and mouse and joysticks and things like that.
And if we roll down the WASD bindings for MOVE, we can see the specific key bindings where we've got
the ways and keys and also the up, down, left and right arrows.
And now we've clicked on one of these.
Let's have a look over at the properties and we can see that our waist is considered a composite type
of a 2D vector.
So it will have an X component and a y component.
And this x and Y component is then further broken down for each key.
So the W handles the up part of that composite to DX vector SX controls the down, a is left and D is
right.
And if we wanted to, we could always change these around to whatever we want.
We can also change the key binding itself.
So if we didn't want to use D as our down key, we can go ahead and click on this dropdown and find
an input from this list.
Alternatively, if you have the control device plugged in, we can also go ahead and hit listen and
then you just have to press whatever button you want to find that in the input list.
So I'm going to keep this as D so if I press D on the keyboard, we can see that it comes up in our
list.
Now, like I said, we're not actually going to be changing anything in this input actions asset for
now.
We will of course come back to this later on when we come to start shooting at our enemies because at
that point we may want to either remap our fire buttons that are automatically assigned or potentially
add additional firing actions.
I just want to give you a brief overview for now so that we can start setting things up in our code.
So rather than saving this asset, I'm just going to go ahead and close it down and then back on our
input actions.
We've got another piece of set up before we go through this other stuff here.
Let's go ahead and drag over the input actions asset into this actions field and it's all open up a
whole bunch of new options.
And the great thing about this is that if we hover over any of these particular options, we'll get
a nice tooltip to explain what it does.
For the moment, we're just going to leave everything as default.
And the only thing I really want to cover is this behaviors list at the bottom.
It's currently on send message and we're actually going to leave it like that.
But when you look at Unity documentation, they tend to be written in terms of using the Unity Events
option.
This is a slightly more complicated setup, but it is more flexible and makes full use of the new input
system.
For now though, while we're just learning about this, let's keep it on send message because that keeps
it nice and simple.
And in this box below, send message will see all of the messages that our input system will be sending
out.
These can then be intercepted in our code.
So let's just have a brief aside and discuss how send messages work.
Well, you can think of it like our input system shouting out to any other.
Components that are on the same object.
There's something has happened.
So the general chain of command will be that the player presses a button on their keyboard, so imagine
they press the W on their keyboard.
This is then registered as being the move action from the input system, and the input system will send
the message to all the attached components that on move has happened.
So to intercept those messages, we're going to need a new script.
But before we do that, there's one final piece of setup that we need to do to get our player input
working.
So if we click on open input settings and then in the input system's package menu, all we need to do
is create our settings asset.
This thing gets everything set up for us and we're not going to worry too much about what all these
options do for now.
So let's just go ahead and close our project settings and we'll see that we've now got a new script
object in our assets folder.
With that all set up though, now let's create our new script that will intercept the messages being
sent by the player input.
So let's add a new component and create a new script called Player.
And then we can go ahead and open that up.
Let's start the script off right by removing our start method, because we're not going to need it.
And we're just clear up this note above our update method.
And now let's look at how we're going to intercept that on move message.
First of all, we're going to need to go right to the top of the script and add a new using statement.
And we're going to be using the unity engine dot input system.
Then to intercept that move message, we need a method with the same name so we can write void on move.
And you can kind of think of this like how the unity on trigger enter functions work and things like
that.
So unity will explicitly recognize this method and we won't have to manually call it from elsewhere
in our code, in the parentheses.
We're going to need to accept an input value and we'll just call this the value.
And if you remember, our move action was a type of vector too.
So we can get our value by saying value dot get and then in chevrons or angle brackets we can write
a vector to.
Let's also store this variable for later use.
So I'm going to create a vector too called raw input and then in on move we can just set raw input to
our value.
Don't get vector two.
Now to show how this works, let's go ahead and write a debug log statement and we're just going to
output the raw input if we now save our script and jump back over into unity, let's go ahead and clear
our console and hit play.
If I press the key on my keyboard, we'll see that we get a single debug log message.
And even though I'm still holding down the key, we're not getting any more messages.
However, when I lift my finger off the key, we get another debug log message to say that things have
been reset for.
I then do the same with the key.
I get a single message release and get a reset message.
So our on move method is only being called when we press a key down and when it gets lifted off.
This is great for things like button presses and mouse clicks, but we're going to want continuous movement.
So when we hold down a key, we continue to move in the given direction.
So how do we achieve this continuous movement?
Well, if we come out of play and jump back over into our script, this is the reason why I stored our
raw input in a separate variable, because we can then use that variable to continuously update our
position in the update method.
So in our update method, let's create a new vector three variable called delta.
And this is going to store the delta position for our movement, which we can then apply to our transform
position.
So for now, let's just set this equal to our raw input and then we can set our transform position to
plus equals our delta.
If we go ahead and save this and jump back into unity to test it out, I'm going to go back to our same
view and then hit play.
And we can now move around.
But our movement is incredibly fast because we're moving one unit, every single frame.
And this is going to bring us onto your challenge.
I want you to fix our player movement to make it more controllable.
Start by adding a move speed variable to our script and we're going to want to be able to change this
in the inspector as well.
So keep that in mind.
And then I want you to make the movement frame rate independent.
We've looked at all of this in previous sections, so pause the video now and give that a go.
Okay.
Welcome back.
So hopefully that was some good revision for you and you got on okay with that challenge.
So let's start by setting up a movement speed variable.
We said we wanted to change this in the inspector, so let's make it a serialized build and we'll use
a float for this and call it the move speed.
While we're here, we may as well set it up with a default value and I think five might be a good starting
value for this.
So let's give that a try.
And then down in our update method, let's amend our delta value to be the raw input multiplied by the
move, speed multiplied by time dot delta time.
And remember Delta time is the time the last frame took to render.
So multiplying by that will just help smooth things out and make our movement frame rate independent.
Now, before we go ahead and save our script, the last thing I want to do in here is just to refactor
this out of my update method.
So I'm going to extract the method by pressing control and the period key in Visual Studio and extract
method.
I'm going to get rid of the private declaration because I don't really like it there.
I like to keep things tidy and I'm going to rename my method to move.
Now, if we go ahead and save this and jump back over into unity, let's go ahead and hit play.
And we can now move around nicely.
Now we are a little bit slow, so we may want to speed that up later on, but we've got a much bigger
problem at the moment in that we can completely leave the game screen and fly where we like.
So we've done quite a lot of work in this lecture to get our player moving.
So we're going to stop things there.
And in the next lecture we're going to look at confining our player to the boundaries of our screen.
So I'll see you there.