Right, so classes have a number of methods in them and it can get a bit confusing as to when each of them are called, especially when you require a very specific sequence of events to occur.

So let’s say that you are instantiating a prefab from a class method.

 yourPrefab yPre = Instantiate(yourPrefab, transform.position, transform.rotation);
        ast.gameObject.name = "Asteroid_" + i.ToString("00");
        // Find a good location for the Asteroid to spawn
        Vector3 pos;
            pos = ScreenBounds.RANDOM_ON_SCREEN_LOC;
        } while ((pos - PlayerShip.POSITION).magnitude < MIN_ASTEROID_DIST_FROM_PLAYER_SHIP);

        ast.transform.position = pos;
        ast.size = asteroidsSO.initialSize;

Scriptable Objects have 2 major uses

  1. Saving and storing data during an editor session
  2. Saving data as an asset in our project for use at runtime

Things to Note

  1. In the editor we can save data to the SO during edit and runtime
  2. In a deployed build we can only read the data from the SO, we cannot save to it. – so no good for saving game state data.

So what’s good about Scriptable Objects

So you can make your scriptable object an Asset and create one in your Project panel with the “Create” menu. You can also define the name of your scriptable object as it appears in the create menu.

Adding your Scriptable Object to the Unity “Create” menu

 [CreateAssetMenu(menuName = "Scriptable Objects/YourObjectName", fileName = "YourObjectName.asset")]

Now once you have created your scriptable object asset, it’s public properties will be available in the inspector simply by selecting it in your project panel. You don’t need to attach it to a scene gameobject in order to be able to view and edit the data.

Why not just use a class?

Well yes you could, but using a scriptable object to store unchanging game data is probably the most efficient way. It creates just one set of data that remains constant, and everything in your file can access this one copy, rather than creating an instance of the data for every gameobject that uses it.


Serialization of Scriptable Objects

Two important attributes to know about



Classes and struct need to be [Serializable]. All public fields are then serialized. Add it above the class definition.

public class MyScriptableObject : ScriptableObject

In Unity, the [SerializeField]  attribute allows you to have private script variables that are exposed in the Inspector. This will let you set the values in the editor without giving access to the variable from other scripts.


So what does this word “static” do to variables and methods? Well a couple of things.

  1. static variables and methods that are public are accessible from anywhere without having to first reference or instantiate the class that they are in. Note though that if they are private, they can not.
  2. They make variables class variables, rather than instance variables. This comes in handy with games especially when you are creating multiple enemies or bullets or obstacles and you want to keep a total count of them. Rather than each instance of the enemy/bullet/obstacle keeping a count, the class as a whole keeps count.
using UnityEngine;
using System.Collections;

public class Obstacle
    //Static variables are shared across all instances of a class.
    public static int obstacleCount = 0;

    public Obstacle()


    static public Obstacle SpawnObstacle()
        //Increment the static variable to know how many
        //objects of this class have been created.

        GameObject oGO = Instantiate<GameObject>(GameManager.ObstacleSO.GetObstaclePrefab());
        Obstacle obst = oGO.GetComponent<Obstacle>();
        return obst;


Now one of the cool things about having a static method is that you can reference them directly and I’ll show you the code for that here.

using UnityEngine;
using System.Collections;

public class GameManager
    void Start()
        for (int i = 0; i < 3; i++)
            Obstacle obst = Obstacle.SpawnObstacle();
            Vector3 pos = ScreenBounds.RANDOM_ON_SCREEN_LOC;
            obst.transform.position = pos;

        //You can access a static variable by using the class name
        //and the dot operator.
        int x = Obstacle.obstacleCount;


Common Concepts of Version Control





Conflict Resolution – Merge



Connect to Collaborate

Click on the services tab (the little cloud in the top right corner). Assign an organisation to your project. Then click on the “Collaborate” tab. Turn on “create together seamlessly”


The arrow on the “collab” button will be blue if you have newer files that need to be published or uploaded.

The arrow on the “collab” button will be orange when there are newer files on the server that you need to pull.

So these are classes that you write, that extend one of the Unity classes. There’s a good example on one of the Learn Unity tutorial site here. But basically  you will create the class file like this:

using UnityEngine; 
using System.Collections; 

    //It is common to create a class to contain all of your 
    //extension methods. This class must be static. 

    public static class ExtensionMethods
    //RULE 1 : extension methods must be declared static. 
    //RULE 2 : The first parameter must have the keyword "this"
    //RULE 3 : Follow the "this" with the Class name that you are extending, 
    // example, Vector3, Transform, Rigidbody
    //RULE 4 : Follow the class type with a variable name to use in the method
    // then just do whatever you need to in the method as per usual

    public static void ResetTransformation(this Transform trans)
        trans.position = Vector3.zero;
        trans.localRotation = Quaternion.identity;
        trans.localScale = new Vector3(1, 1, 1);



Now you can refer to your new extension method with the following code

//Notice how you pass no parameter into this
//extension method even though you had one in the
//method declaration. The transform object that
//this method is called from automatically gets
//passed in as the first parameter.

it is the same as saying


So I was watching a tutorial and the guys keeps banging on about classes being monobehaviour or not and I started wondering why he was making note of one that wasn’t monobehaviour. So I’ve looked it up on Unity and you can see the whole post here, but the main jist is this.

MonoBehaviour is the base class from which every Unity script derives.

When you use C#, you must explicitly derive from MonoBehaviour. When you use UnityScript (a type of JavaScript), you do not have to explicitly derive from MonoBehaviour.

Note: There is a checkbox for disabling MonoBehaviour on the Unity Editor; it disables Start()Awake()Update()FixedUpdate(), and OnGUI() from executing when unticked. If none of these functions are present in the script, the Editor does not display the checkbox.


Did you know that the camera is half-size when in orthographic mode? Well I didn’t, but now I do.

The orthographicSize property defines the viewing volume of an  orthographic  Camera. In order to edit this size, ensure the Camera is first set to orthographic either through script or in the Inspector. The orthographicSize is half the size of the vertical viewing volume. The horizontal size of the viewing volume depends on the aspect ratio.

So if I wanted to create a bounding box around the orthographic camera view – for example in a game where I wanted to know if an object has left the gameplay area which is the whole screen – then I could use the following script.

Vector3 scaleDesiredOfColiderBox;

scaleDesiredOfColiderBox.z = 10;
scaleDesiredOfColiderBox.y = Camera.main.orthographicSize * 2;
scaleDesiredOfColiderBox.x = scaleDesiredOfColiderBox.y * Camera.main.aspect;