📣 Lesson 2.2: Events & Delegates

The Problem Events Solve

When the player's health hits zero, a lot needs to happen: the health bar empties, a death sound plays, the score is tallied, a "You Died" screen fades in, maybe an achievement fires. The naive approach makes Health reach out and call each one:

// ❌ Health now depends on the UI, audio, score, and screen systems
void Die()
{
    FindObjectOfType<HealthBar>().SetEmpty();
    FindObjectOfType<AudioManager>().PlayDeath();
    FindObjectOfType<ScoreManager>().AddKill();
    FindObjectOfType<GameOverScreen>().Show();
}

We're right back to spaghetti — Health knows about four unrelated systems, and every new reaction means editing Health. Events invert this: Health simply shouts "I died!" into the room and moves on. Whoever wants to react was already listening.

Delegates: Methods in a Variable

The whole system is built on the delegate. You already store numbers in an int and text in a string; a delegate is a variable that stores a method — a reference you can pass around and call later.

// declare a delegate type: "a method that takes an int, returns nothing"
public delegate void DamageHandler(int amount);

DamageHandler onHit;      // a variable of that type

void Start()
{
    onHit = LogDamage;    // store a method (no parentheses!)
    onHit(10);            // call it -> LogDamage(10) runs
}

void LogDamage(int amount) => Debug.Log($"Took {amount} damage");

A delegate can also hold several methods at once. Use += to add one and -= to remove one; invoking the delegate calls them all in order. That "one call, many methods" behavior is the seed of everything in this lesson.

Action & Func

You rarely need to declare your own delegate type, because .NET ships two general-purpose ones you'll use everywhere:

• Action — a method that returns void. Action takes no arguments; Action<int> takes an int; Action<int, string> takes an int and a string.
• Func — a method that returns a value. The last type parameter is the return type: Func<bool> returns a bool; Func<int, int, int> takes two ints and returns an int.

using System;

Action greet = () => Debug.Log("Hi!");          // no args, no return
Action<int> report = n => Debug.Log($"HP: {n}"); // one int arg
Func<int, int, int> add = (a, b) => a + b;       // two ints -> int

greet();                 // "Hi!"
report(42);              // "HP: 42"
int sum = add(3, 4);     // 7

For game events you'll almost always reach for Action — most events are "something happened," not "compute and return a value."

The event Keyword

A plain public delegate is dangerous: any outside class could overwrite it with = (wiping every other listener) or even invoke it. The event keyword locks that down.

using System;

public class Bell : MonoBehaviour
{
    public event Action OnRing;          // outsiders can only += / -=

    public void Ring()
    {
        OnRing?.Invoke();                // only Bell can raise it
    }
}

The ?.Invoke() is important: if nobody has subscribed, the event is null, and calling it directly would throw. The null-conditional ?. means "invoke only if there's at least one listener." Always raise events this way.

The Observer Pattern

What you just built has a formal name: the observer pattern. A publisher owns an event and raises it; any number of subscribers attach their own methods and react. The publisher never holds a reference to the subscribers and never knows how many there are.

Figure 1: One publisher, many subscribers. Health raises OnDied once; four unrelated systems react. Add or remove a subscriber and Health never changes.

Compare this to Figure 1 from the last lesson: interfaces pointed the caller at its targets; events point the targets at the source. Both remove hard wires, and real projects use them together.

A Health That Broadcasts

Here is the publisher. It exposes two events — a data-carrying OnHealthChanged and a bare OnDied — and raises them at the right moments. Notice it imports no UI, audio, or score code whatsoever:

using System;
using UnityEngine;

public class Health : MonoBehaviour, IDamageable
{
    [SerializeField] int maxHealth = 100;
    int current;

    // (current, max) so listeners can compute a fill fraction
    public event Action<int, int> OnHealthChanged;
    public event Action OnDied;

    public int CurrentHealth => current;

    void Awake()
    {
        current = maxHealth;
        OnHealthChanged?.Invoke(current, maxHealth);
    }

    public void TakeDamage(int amount)
    {
        current = Mathf.Max(0, current - amount);
        OnHealthChanged?.Invoke(current, maxHealth);   // tell the UI
        if (current == 0) OnDied?.Invoke();            // tell everyone
    }
}

And here is one subscriber — a health bar that listens for changes and updates its fill. It never calls into Health; it only reacts:

using UnityEngine;
using UnityEngine.UI;

public class HealthBarUI : MonoBehaviour
{
    [SerializeField] Health health;   // the publisher to watch
    [SerializeField] Image fill;

    void OnEnable()  => health.OnHealthChanged += UpdateBar;
    void OnDisable() => health.OnHealthChanged -= UpdateBar;

    void UpdateBar(int current, int max)
    {
        fill.fillAmount = (float)current / max;
    }
}

An AudioManager could subscribe its PlayDeath to OnDied in exactly the same shape. Neither subscriber knows the other exists.

Unsubscribe or Leak

Look again at those two lines: subscribe in OnEnable, unsubscribe in OnDisable. This pairing is not optional — it prevents a real and nasty bug.

The reliable habit: subscribe in OnEnable, unsubscribe in OnDisable. These fire together every time the object is enabled/disabled or destroyed, so the two calls always balance. Never subscribe in Awake/Start and forget the other half.

💡 Symmetry is the trick. Read your OnEnable and OnDisable side by side: every += in one should have a mirror -= in the other. If they aren't mirror images, you have a leak waiting to happen.

UnityEvent: Wiring in the Inspector

C# events are code-only — a designer can't see or change them in the Editor. Unity offers a serializable cousin, UnityEvent, that shows up as a wireable field in the Inspector. You (or a designer) drag target objects in and pick methods from a dropdown, no code required.

using UnityEngine;
using UnityEngine.Events;

public class Interactable : MonoBehaviour
{
    // shows up in the Inspector with a + button and a list
    public UnityEvent OnActivated;
    public UnityEvent<int> OnScored;   // can carry a payload too

    public void Activate()
    {
        OnActivated.Invoke();   // note: no ?. needed, it's never null
    }
}

In the Inspector, OnActivated renders as a list of persistent listeners. Each row is one reaction: an object, and a method on it to call. Here's that panel, drawn faithfully:

Hands-on Challenge

Summary

🚀 What's Next?

Events decouple behavior. But games are also full of data — weapon stats, enemy definitions, item lists — that today lives tangled inside components and scenes. In Lesson 2.3: ScriptableObjects we lift that data out into standalone project assets that designers can edit and many objects can share.