Tips, tricks, and guides for developing on modern Windows platforms
In Part 1 I covered public variables in Unity scripts. In Part 2 I will talk about MonoBehaviour methods. Unity scripts by default inherit MonoBehavior, and therefore implement many standard Unity 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 unique differences).
Here are some important and useful methods that automatically run for every MonoBehavior script. They each run at specific times and have specific uses.
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.
// initialise the object
// set location, sprite, initial values, etc.
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).
// this code will run when object is enabled
// may run multiple times
The opposite of OnEnable(). This will run when the game object is disabled. Use it to ‘clean up’ after an object.
// clean up after a destroyed object
The Start() method is executed before the first Update() method (see below). The script instance must be enabled for Start() to run.
// do what needs to be done when the object starts
Update(), FixedUpdate(), LateUpdate()
The update methods are very useful and powerful, but you need to know the difference between them. Each runs repeatedly while your script is active, and they differ by em>when they run.
In a nutshell:
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).
// 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
// 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
// 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 being 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!).
You can think of Update() and LateUpdate() in terms of they will run 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.
In short, the basic MonoBehaviour methods are:
In Part 3 I will extend on this topic to talk about the automated collision detection in MonoBehaviour scripts, such as OnCollision2D() and OnTrigger().