Unity Scripting Primer Part 2: MonoBehaviour Basics

In Part 1 I covered public and serialized variables in Unity scripts. In Part 2 I will talk about MonoBehaviour methods. Unity scripts by default inherit MonoBehavior, and therefore implement many standard methods, which give great automatic functionality. When a script inherits MonoBehavior, it is declared like this:

public class MyUnityScript : MonoBehavior

Inheritance is an important part of programming, so read up on it if you need to. For our needs you just need to know that when a class (effectively a script in Unity) inherits MonoBehaviour it becomes a copy of MonoBehaviour, but with its own unique code in addition to the MonoBehaviour code (much like cars and motorcycles are both vehicles, sharing many similar properties, but also having differences).

MonoBehaviour Methods

Here are some important and useful methods that automatically run for every MonoBehavior script. They each run automatically at specific times and have specific uses.

Awake()

Awake() executes when the scene starts, as soon as the object containing the script is first created. It only runs once, and it runs before any other methods. You can use this to initialise anything, such as setting the sprite or the location.

void Awake()
{
   // initialise the object
   // set location, sprite, initial values, etc.
}

OnEnable()

OnEnable() is called when the scene starts, and when the game object and the item the script is attached to are both enabled. This will generally run as soon as your object in instantiated, but runs AFTER the Awake() method. Because game objects can be disabled and re-enabled, this method can run multiple times throughout the life-cycle of your objects (e.g. when pausing/unpausing the game).

void OnEnable()
{
   // this code will run when  object is enabled
   // may run multiple times
}

OnDisable()

The opposite of OnEnable(), this runs when the GameObject is disabled. Use it to ‘clean up’ after an object.

void OnDisable()
{
   // clean up after a destroyed object
}

Start()

Start() runs before the first Update() method (see below). The script instance must be enabled for Start() to run.

void Start()
{
   // do what needs to be done when the object starts
}

Update(), FixedUpdate(), LateUpdate()

The update methods are very powerful, and each is different. Each runs repeatedly while your script is active, and they differ by when they run.

Three Updates

• Update() runs every frame; framrate fluctuates according to hardware and complexity (e.g. a simple game on powerful hardware has a higher framerate than a complex game on weak hardware)
• LateUpdate() runs every frame AFTER Update()
• FixedUpdate() runs every PHYSICS ‘tick’; time between ticks is always the same regardless of hardware or game complexity.

Imagine a complex game with lots of physics interactions. On a low-end smartphone your game has less power available to draw all the graphics and compute the physics, but a gaming PC or console has much more power. You still want the game to play the same (falling items fall at the same speed, players jump at the same speed, etc.), but on the more powerful systems you would like to take advantage of the extra power to show smoother graphics (i.e. a higher framerate).

void Update()
{
    // code here will run every frame, running more often on faster devices
    // framerate will fluctuate if there is a lot of activity in the scene
    // use Update for anything that doesn't require accurate timing, such as user input
}

void FixedUpdate()
{
    // code here will run at a fixed rate, always at the same interval regardless of device
    // any physics work must be done here as it relies on accurate timing
}

void LateUpdate()
{
   // runs after each Update() method, and should be used for anything that should be updated after everything else, such as moving the camera
}

NOTE: FixedUpdate() will not run the same number of times as Update() and LateUpdate(). Generally FixedUpdate() will run more often (especially in more complex games or on slower hardware).

The update methods should be used sparingly, as they run constantly (e.g. 60 times per second). Everything your code does in the update methods is repeated many times per second, so avoid anything time consuming or wasteful (e.g. if you run a ‘for loop’ in Update() and loop through 100 items, you could be repeating that 60 times per second!). Think of Update() and LateUpdate() as running as often as they can within the hardware and code restraints. FixedUpdate() will run at the constant physics rate unless your game is really struggling to keep up. The more work you do in your update methods the lower your framerate will be.

Recap

In short, the basic MonoBehaviour methods are:

• Awake() – runs when your object is first created, and only runs once.
• OnEnable() – runs when your object is enabled, which can happen more than once.
• OnDisable() – runs when your object is destroyed and can be used for ‘clean up’.
• Start() – runs when your object first starts.
• Update() – runs every frame, avoid too much work.
• FixedUpdate() – runs every physics tick.
• LateUpdate() – runs at the end of every frame.

In Part 3 I will extend on this topic to talk about the automated collision detection in MonoBehaviour scripts.