Unity Tutorial Part 3: Components
In the final part of our Unity tutorial series, you’ll learn how to make your first game in Unity with C# from scratch: a twin-stick shooter called Bobblehead Wars! By Brian Moakley.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
Unity Tutorial Part 3: Components
40 mins
Accessing Input From Code
Now to actually implement the control scheme. In the Project Browser, double-click the PlayerController script to launch the editor.
When the code editor opens, you’ll see your first script. Every new script contains empty implementations for Start()
and Update()
.
Look for a blank line below the first {
(a.k.a., “curly bracket”) — that’s the class definition. Add the following code there:
public float moveSpeed = 50.0f;
If your script throws an error, carefully review the code to make sure you didn’t miss, forget or mess up something.
If your script throws an error, carefully review the code to make sure you didn’t miss, forget or mess up something.
moveSpeed
is a variable that determines how fast the hero moves around in the arena. You set it to a default value of 50
that you can change later in Unity’s interface.
Now, to write the actual moving code. In Update()
, add the following:
Vector3 pos = transform.position;
This bit of code simply gets the current position of the current GameObject — in this case, the space marine since that is what this script is attached to — and stores it in a variable named pos
. In Unity, a Vector3
encapsulates the x, y and z of a GameObject, i.e., the object’s point in 3D space.
Now comes the tricky part. Add the following after the previous line:
pos.x += moveSpeed * Input.GetAxis("Horizontal") * Time.deltaTime;
pos.z += moveSpeed * Input.GetAxis("Vertical") * Time.deltaTime;
When you move the object, it’ll only be on z- and x-axes because y represents up and down. Because there are two different input sources (“Horizontal” for left and right, and “Vertical” for up and down), you need to calculate values for each axis separately.
Input.GetAxis("Horizontal")
retrieves a value from the Horizontal component of the Input Manager. The value returned is either 1
or -1
, with 1
indicating that a positive button in the Input Manager is being pressed. According to the settings you saw defined earlier, this is either the right
arrow or d
keys. Similarly, a value of -1
indicates that a negative button is being pressed, meaning it was either the left
arrow or the a
key.
Whatever the returned value may be, it’s then multiplied by the moveSpeed
and added to the current x
position of the GameObject, effectively moving it in the desired direction.
The same thing happens with Input.GetAxis("Vertical")
, except it retrieves a value from the vertical component of the Input Manager (indicating the s
, down
, w
or up
keys), multiplies this (1
or -1
) value by the moveSpeed
and adds it to the z
position of the GameObject.
So what’s with Time.deltaTime
? That value indicates how much time has passed since the last Update()
. Remember, Update()
is called with every frame, so that time difference must be taken into account or the space marine would move too fast to be seen.
TL/DR: Time.deltaTime
ensures movement is in sync with the frame rate.
By default, Unity considers one point to be equal to one meter, but you don’t have to follow this logic. For instance, you may be making a game about planets, and that scale would be way too small. For the purposes of simplicity in this tutorial, we have sized our models to follow Unity’s default of one point per meter.
By default, Unity considers one point to be equal to one meter, but you don’t have to follow this logic. For instance, you may be making a game about planets, and that scale would be way too small. For the purposes of simplicity in this tutorial, we have sized our models to follow Unity’s default of one point per meter.
Now that you’ve altered the location, you have to apply it to the SpaceMarine GameObject. Add the following after the previous line:
transform.position = pos;
This updates the SpaceMarine GameObject’s position with the new position.
Save the script and switch back to Unity. You may be tempted to run your game, but there’s a slight problem. The camera is not positioned correctly.
In the Hierarchy, select the Main Camera, and in the Inspector, set Position to (–9.7, 53.6, –56.1) and Rotation to (30, 0, 0). I determined these values by moving the camera around manually and looking at the Camera preview in the lower right until I was happy with the result.
In the Camera component, set Field of View to 31. This effectively “zooms in” the view a bit.
Now it’s time to give your game a test run. Look for the play controls at the center-top of the editor. Click the Play button.
Now, look at the Game window and move your character by pressing the Arrow keys or WASD keys. Behold… life!
The Game window is where you actually play the game. There are two life-and-death details to keep in mind as you play.
First, when you start playing, the interface becomes darker to give a visual queue that you’re in play mode.
Second, when you play your game. you can change anything about it (including changing values on components in the inspector) but, when you stop playing the game, ALL YOUR CHANGES WILL BE LOST. This is both a blessing and a curse. The blessing is that you have the ability to tweak the game without consequence. The curse is that sometimes you forget you’re in play mode, continue working on your game then, for some reason, the game stops. Poof! Buh-bye changes!
Thankfully, you can (and should) make play mode really obvious. Select Edit\Preferences on PC or Unity\Preferences on Mac to bring up a list of options.
Select the Colors section. Look for Playmode tint. Click the color box next to it, and then give it an unmistakable color — I prefer red. Now play your game to see if it’s conspicuous enough.
The Game window is where you actually play the game. There are two life-and-death details to keep in mind as you play.
First, when you start playing, the interface becomes darker to give a visual queue that you’re in play mode.
Second, when you play your game. you can change anything about it (including changing values on components in the inspector) but, when you stop playing the game, ALL YOUR CHANGES WILL BE LOST. This is both a blessing and a curse. The blessing is that you have the ability to tweak the game without consequence. The curse is that sometimes you forget you’re in play mode, continue working on your game then, for some reason, the game stops. Poof! Buh-bye changes!
Thankfully, you can (and should) make play mode really obvious. Select Edit\Preferences on PC or Unity\Preferences on Mac to bring up a list of options.
Select the Colors section. Look for Playmode tint. Click the color box next to it, and then give it an unmistakable color — I prefer red. Now play your game to see if it’s conspicuous enough.