Unity Journey: The Player's ship

Make sure to read Part 1 first

Hello there, I am back with another entry on my Unity Journey's development diary. I would like to remind you that I am not trying to make a full-fledged game, I just want some practical application of my ongoing learning process.

In the last chapter I ended by having the model that represents the player in the game. Now we will be diving into Unity to make that model move with the input from the player.

One of the first things that really seem weird at first is, when you import a model into unity, it comes with a default scale factor of 0.01:

This makes it impossible to see it once you have dragged into the scene:

But once that is figured out, we can see our awesome model in the scene :P

One of the first things you should do after dragging a model into the scene is to reset its transform (a composite of three vectors, for position rotation and scale) to prevent it from ending up in an expected place when running the game.

Make it move

Now that we have our ship we need to make it move. As it currently stands, our ship is just a dead object without anything of interest going on. To add some spice to it we need to attach a script.

When creating scripts Unity gives you three options regarding the languages you want to use: Javascript, C# and Boo. Since I am already comfortable with JS and Boo doesn't seem to have much community support, so I ended up choosing C#, thus also learning a new language (well, I have used before at college for a course but I didn't actually retain much of it).

This is a part where I think Unity really did a good job with scripts. Scripts in Unity are just Components and a GameObject (like our ship) can have any number of components. In fact, both the Transform and the animator are components.

Everything that you attach to a GameObject is a component, so in Unity composition is a key factor in your game structure and its advantages begin to show once the game gets more and more complex. This focus on composition over inheritance reinforces the modularity of your design and development and immensely improves the reusability of logic between different objects and projects.

You just need drag the components onto the objects and configure them. Let's take player movement as an example.

We will start with a simple movement, press the left to go to the left, right arrow to go to the right and so on. We will also add a bit of tilt to the ship as it moves along the screen to make it seem more natural.

Here is the code:

using UnityEngine;  
using System.Collections;

public class PlayerMovement : MonoBehaviour {

    public float speed;
    public float maximumTilt=20f;

    // Use this for initialization
    void Start () {

    }

    // Update is called once per frame
    void Update () {
        Vector3 moveDir = new Vector3 (-Input.GetAxis("Horizontal"), 0, -Input.GetAxis("Vertical"));
        transform.position += moveDir * speed * Time.deltaTime;
        transform.Rotate(new Vector3(0,0,Input.GetAxis("Horizontal")*maximumTilt) * Time.deltaTime);
    }
}

Here we are just creating a movement vector from the player input and use it to change the player's position. We take into account the speed we want the ship to have and multiply it by Time.deltaTime to guarantee that our speed is independent of the processing speed of the device we run our game on.

The last just adds that bit of tilt I told you before.

The public modifier of the two properties allow us to quickly set their values through the Unity Editor. Everything declared public will be visible inside the Script section:

You can just change the values, press the play and see the results. Even better, you can change the values in real time and watch how it changes the way your game plays and feels. How great would it be to have this kind of modular development coupled with the drag-and-drop spirit and run-time tinkering capabilities in your regular software development IDE? I'll leave that discussion for a later post.

In this part we have managed to make the ship a living object by making it respond to the user input. But you must already probably have noticed that the camera doesn't follow the player. This wouldn't make for a very exciting game, specially since we want to recreate that old-school space-shooter fast pacing feel.

In the next part we will deal with the camera, the problems it presents and how can we solve them.

If you have any doubt or just want to get in touch with me, you can contact me by email, LinkedIn or Twitter

Menu

Make it move