Now, at this point, we have a great-looking game, but nothing at all happens. Let's change that now using our player. Perform the following steps:

After your IDE has loaded, you will be presented with the C# stub code that was created automatically for you by Unity when you created the C# script.

Let's break down what's currently there before we replace some of it with new code. At the top, you will see two lines:

using UnityEngine;
using System.Collections;

The engine knows that if we refer to a class that isn't located inside this file, then it has to reference the contents within these namespaces for the referenced class before giving an error. We are currently using two namespaces.

The UnityEngine namespace contains interfaces and class definitions that let MonoDevelop know about all the addressable objects inside Unity.

The System.Collections namespace contains interfaces and classes that define various collections of objects, such as lists, queues, bit arrays, hash tables, and dictionaries. But we will not be using it in this file so you can remove that line.

The next line you'll see is:

public class PlayerBehaviour : MonoBehaviour {

You can think of a class as a kind of blueprint for creating a new component type that can be attached to GameObjects, the objects inside our scenes that start out with just Transform and then have components added to them. When Unity created our C# stub code, it took care of that; we can see the result, as our file is called PlayerBehaviour and the class is also called PlayerBehaviour. Make sure that your .cs file and the name of the class match, as they must be the same to enable the script component to be attached to a game object. Next up is the: MonoBehaviour section of the code. The : symbol signifies that we inherit from a particular class; in this case, it is set to MonoBehaviour. All behavior scripts must inherit from MonoBehaviour directly or indirectly by being derived from it. This idea of having classes inherit behavior is known as inheritance.

Inheritance is the idea of having an object to be based on another object or class using the same implementation. With this in mind, all of the functions and variables that exist inside the MonoBehaviour class will also exist in the PlayerBehaviour class, because PlayerBehaviour is a MonoBehaviour with the ability to add more to it.

Directly after this line, we will want to add some variables to help us with the project. Variables are pieces of data that we wish to hold on to for one reason or another, typically because they will change over the course of a program, and we will do different things based on their values.

Add the following code under the class definition:

// Movement modifier applied to directional movement.
public float playerSpeed = 4.0f;

// What the current speed of our player is
private float currentSpeed = 0.0f;

// The last movement that we've made
private Vector3 lastMovement = new Vector3();

Between the variable definitions, you will notice comments to explain what each variable is and how we'll use it. To write a comment, you can simply add a // to the beginning of a line and everything after that is commented upon so that the compiler/interpreter won't see it. If you want to write something that is longer than one line, you can use /* to start a comment, and everything inside will be commented until you write */ to close it. It's always a good idea to do this in your own coding endeavors for anything that doesn't make sense at first glance.

One of the things you'll notice is the public and private keywords before the variable type. These are access modifiers that dictate who can and cannot use these variables. The public keyword means that any other class can access that property, whereas private means that only this class will be able to access this variable. Here, currentSpeed is private because we want our current speed not to be modified or set anywhere else. But, you'll notice something interesting with the public variable that we've created. Go back into the Unity project and drag and drop the PlayerBehaviour script onto the playerShip object. Before going back to the Unity project though, make sure that you save your PlayerBehaviour script. Not saving is a very common mistake made by people when starting to code. Have a look at the following screenshot:

You'll notice now that the public variable that we created are located inside Inspector for the component. This means that we can actually set those variables inside Inspector without having to modify the code, allowing us to tweak values in our code very easily, which is a godsend for many game designers. You may also notice that the name for Player Speed has been changed to be more readable. This is because of the naming convention that we are using where each word starts with a capital letter. This convention is called CamelCase (more specifically headlessCamelCase).

Now that we have our variables set, go back to MonoDevelop for us to work on the script some more.

The line after that is a function definition for a method called Start; it isn't a user method but one that belongs to MonoBehaviour. Where variables are data, functions are the things that modify and/or use that data. Functions are self-contained modules of code (enclosed within braces { and }) that accomplish a certain task. The nice thing about using a function is that once a function is written, it can be used over and over again. Functions can be called from inside of other functions:

void Start () {
    
}

Start is only called once in the lifetime of the behavior when the game starts and is typically used to initialize data.

However, for this behavior, we will not need to use the Start function. Perform the following steps:

Now, you'll see that we can move using the arrow keys or the W A S D keys, and our ship will rotate to face the mouse. Great!