📝 Lesson 1.2: The Event Function Lifecycle

Event Functions, Not Main

A console program has one timeline you control. A Unity game has a player loop that the engine runs many times per second, and at well-defined moments it calls the methods you've defined on your components. Those methods are the event functions (Unity also calls them "messages").

You already met two of them in Lesson 1.1: Start (for setup) and Update (for per-frame logic). There are more, and knowing which runs when is the difference between code that works and code that mysteriously reads a value before it was set.

💡 The one-line summary: Awake/OnEnable/Start run once at birth, Update/FixedUpdate/LateUpdate run every frame or physics step, and OnDisable/OnDestroy run at death. Get those three phases straight and the rest is detail.

The Lifecycle Order

Here is the sequence for a single component, from the moment it's created to the moment it's destroyed. Unity guarantees this ordering within one component:

Two subtleties this diagram captures that trip people up:

• FixedUpdate can run zero, one, or several times per rendered frame — it's tied to the physics clock, not the frame rate.
• LateUpdate always runs after every component's Update that frame — that's what makes it perfect for "react to where things ended up."

Awake vs OnEnable vs Start

All three run near the beginning, but at different moments and for different jobs. Using the wrong one causes the classic "null on the first frame" bug.

The key insight is the two-phase startup: Unity runs all Awake calls first, then all Start calls. So anything you set up in Awake is safe to read from any Start. That's how you dodge the cross-object ordering problem.

using UnityEngine;

public class Player : MonoBehaviour
{
    private Rigidbody body;   // a reference to our own physics component

    void Awake()
    {
        // Set up MYSELF here. This is safe — it doesn't need other objects.
        body = GetComponent<Rigidbody>();
    }

    void Start()
    {
        // By now every other object's Awake has run, so cross-object lookups are safe.
        GameManager.Instance.RegisterPlayer(this);
    }
}

⚠️ Important: Remember from Lesson 1.1 — put initialization here, not in a constructor. Unity constructs your component itself, before the GameObject is wired up, so a constructor runs too early and on the wrong thread for most Unity APIs.

Update, FixedUpdate & LateUpdate

These three are the beating heart of gameplay — they run over and over. Choosing the right one is mostly about the clock each one follows.

Update() — once per rendered frame

Runs once every frame, so its rate rises and falls with performance (60 fps → 60 calls/sec; 30 fps → 30). Use it for input polling, timers, non-physics movement, and general game logic. Because frame time varies, multiply movement by Time.deltaTime to stay frame-rate independent:

void Update()
{
    // Move 5 units per SECOND regardless of frame rate.
    transform.Translate(0f, 0f, 5f * Time.deltaTime);
}

FixedUpdate() — on the physics clock

Runs on a fixed timestep (0.02s / 50 times per second by default), decoupled from the frame rate. This is where all physics code belongs — anything touching a Rigidbody (forces, velocity). Because its interval is constant, use Time.fixedDeltaTime here (or just rely on the physics engine's own integration):

private Rigidbody body;

void Awake() => body = GetComponent<Rigidbody>();

void FixedUpdate()
{
    // Apply physics forces here, NOT in Update.
    body.AddForce(Vector3.forward * 10f);
}

LateUpdate() — after all Updates

Runs once per frame too, but guaranteed after every Update has finished. The textbook use is a camera that follows the player: you want the camera to reposition only after the player has already moved this frame, otherwise it lags or jitters.

public Transform target;   // the player, assigned in the Inspector

void LateUpdate()
{
    // The player already moved in its Update; now we follow.
    transform.position = target.position + new Vector3(0f, 5f, -10f);
}

OnDisable & OnDestroy

Every setup has a matching teardown. Skipping cleanup is a top source of Unity bugs — dangling event subscriptions that fire on dead objects, or "leaked" listeners.

The most important pattern in the whole lesson: subscribe in OnEnable, unsubscribe in OnDisable. They're mirror images, so subscriptions never leak:

public class ScoreListener : MonoBehaviour
{
    void OnEnable()
    {
        GameEvents.ScoreChanged += HandleScoreChanged;   // subscribe
    }

    void OnDisable()
    {
        GameEvents.ScoreChanged -= HandleScoreChanged;   // ALWAYS undo it
    }

    void HandleScoreChanged(int newScore) => Debug.Log($"Score: {newScore}");
}

💡 Note on order: when an object is destroyed, Unity calls OnDisable first, then OnDestroy. So the unsubscribe in OnDisable also covers the destroy case — you rarely need to repeat it in OnDestroy. (We go deep on C# events and this pattern in Lesson 3.2.)

Why No override?

A sharp C# programmer notices something odd: you write void Update() with no override, no interface, and often private. How does Unity call a private method you never registered?

Unity finds these methods by name and signature when your script first runs, using a fast internal lookup (not ordinary reflection every frame). If a method with the right name exists, Unity wires it into the loop; if not, it simply isn't called. This is why:

• An empty Update() still has a small cost — Unity is invoking it every frame. Delete event functions you don't use.
• A typo silently does nothing: void Updaet() or void update() compiles fine and is simply never called. Case and spelling must be exact.
• Signatures matter: Update() takes no parameters; OnCollisionEnter(Collision c) takes exactly one of the right type.

Exercise & Quiz

using UnityEngine;

public class LifecycleLogger : MonoBehaviour
{
    void Awake()  { Debug.Log("1. Awake"); }
    // TODO: add OnEnable, Start, Update (first 3 frames only), OnDisable, OnDestroy
}

using UnityEngine;

public class LifecycleLogger : MonoBehaviour
{
    private int frame;

    void Awake()     { Debug.Log("1. Awake"); }
    void OnEnable()  { Debug.Log("2. OnEnable"); }
    void Start()     { Debug.Log("3. Start"); }

    void Update()
    {
        if (frame < 3)
        {
            Debug.Log($"4. Update (frame {frame})");
            frame++;
        }
    }

    void OnDisable() { Debug.Log("5. OnDisable"); }
    void OnDestroy() { Debug.Log("6. OnDestroy"); }
}

Summary

📚 Additional Resources

• Unity Manual — Event function execution order
• Scripting Reference — MonoBehaviour messages (Awake, Start, Update…)
• Scripting Reference — Time.deltaTime

🚀 What's Next?

You can now write components that come alive at the right moments. But real behavior needs objects to find and talk to each other. In Lesson 1.3 we cover accessing GameObjects and components: GetComponent, references, and the [SerializeField] attribute for wiring things up in the Inspector.