📝 Lesson 3.2: Events and Decoupling

The Coupling Problem

Here's the naive way to make things react when the player is hurt: give the Player a reference to everything that cares.

// ❌ Tightly coupled: Player must know about every reactor.
public class Player : MonoBehaviour
{
    [SerializeField] private HealthBar healthBar;
    [SerializeField] private ScoreManager scoreManager;
    [SerializeField] private AudioManager audioManager;
    [SerializeField] private CameraShake cameraShake;

    void TakeDamage(int amount)
    {
        health -= amount;
        healthBar.Refresh(health);        // Player now depends on HealthBar…
        scoreManager.LosePoints(amount);  // …and ScoreManager…
        audioManager.PlayHurt();          // …and AudioManager…
        cameraShake.Shake();              // …and CameraShake.
    }
}

The fix is to invert the relationship. Instead of the Player calling each reactor, it simply announces "I took damage." Reactors subscribe to that announcement. The Player no longer knows — or cares — who's listening.

C# Events in Unity

You met delegates and events in the Intermediate C# course; here they earn their keep. A quick recap of the vocabulary:

Here's Health as a publisher. It exposes an event and raises it when damage happens — with no idea who is listening:

using System;
using UnityEngine;

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

    // The announcements this component can make. Others subscribe; only Health raises them.
    public event Action<int> Damaged;    // passes the new health value
    public event Action Died;            // no data needed

    void Awake() => current = maxHealth;

    public void TakeDamage(int amount)
    {
        current -= amount;

        // Raise the event. The ?.Invoke guards against "nobody is subscribed" (null).
        Damaged?.Invoke(current);

        if (current <= 0)
            Died?.Invoke();
    }
}

Notice how small and self-contained Health is now. It depends on nothing in your game. You could drop it into a totally different project unchanged.

The Subscribe/Unsubscribe Pattern

Back in Lesson 1.2 we promised this: subscribe in OnEnable, unsubscribe in OnDisable. Now you can see why it matters. A subscriber registers a method and must remove it, or it leaks — and worse, a destroyed object's method may still get called, throwing errors.

public class HealthBarUI : MonoBehaviour
{
    [SerializeField] private Health health;   // the publisher to listen to

    void OnEnable()
    {
        health.Damaged += UpdateBar;   // start listening
    }

    void OnDisable()
    {
        health.Damaged -= UpdateBar;   // ALWAYS stop listening (mirror image)
    }

    private void UpdateBar(int newHealth)
    {
        Debug.Log($"Health bar now shows {newHealth}");
    }
}

💡 The golden rule: every += needs a matching -=. Put them in OnEnable/OnDisable and you never have to think about it again.

UnityEvents in the Inspector

C# events are code-only — great for programmers, invisible to designers. UnityEvent is Unity's serializable event that shows up in the Inspector, so non-programmers can hook up reactions by dragging, exactly like a Button's On Click () list (which is a UnityEvent).

using UnityEngine;
using UnityEngine.Events;   // UnityEvent lives here

public class Interactable : MonoBehaviour
{
    // Appears as a drag-and-drop event list in the Inspector.
    public UnityEvent onInteract;

    public UnityEvent<int> onScoreAwarded;   // typed variant, passes an int

    void Interact()
    {
        onInteract.Invoke();        // note: UnityEvent uses .Invoke(), no ?.
        onScoreAwarded.Invoke(10);
    }
}

In the Inspector, onInteract becomes a list where a designer adds a target object and picks a public method to call — no code needed to connect a door to its "open" sound.

ScriptableObject Event Channels

C# events need the subscriber to hold a reference to the publisher ([SerializeField] private Health health;). That's fine within one object, but awkward when a system in one scene must talk to a system in another, or when you don't want any direct reference at all. The elegant Unity solution combines Lesson 3.1 with events: an event channel — a ScriptableObject that is the event.

using System;
using UnityEngine;

// The event lives as an ASSET. Publishers and subscribers both reference the asset,
// not each other.
[CreateAssetMenu(menuName = "Events/Game Event")]
public class GameEventChannel : ScriptableObject
{
    public event Action Raised;

    public void Raise() => Raised?.Invoke();
}

// Publisher: raises the channel. Knows nothing about listeners.
public class Player : MonoBehaviour
{
    [SerializeField] private GameEventChannel playerDied;   // drag the asset in

    void Die() => playerDied.Raise();
}

// Subscriber: listens to the same channel asset. Knows nothing about the Player.
public class GameOverScreen : MonoBehaviour
{
    [SerializeField] private GameEventChannel playerDied;   // same asset

    void OnEnable()  => playerDied.Raised += Show;
    void OnDisable() => playerDied.Raised -= Show;

    private void Show() => Debug.Log("GAME OVER");
}

Which Should You Use?

Three mechanisms, three sweet spots. Reach for the simplest that fits.

💡 Don't over-engineer. Events are for decoupling things that genuinely benefit from it (one-to-many, or systems that shouldn't know each other). A component calling a method on its own child doesn't need an event — a direct call is clearer. Decouple where change hurts, not everywhere.

Exercise & Quiz

using System;
using UnityEngine;

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

    public event Action<int> Damaged;

    void Awake() => current = maxHealth;

    public void TakeDamage(int amount)
    {
        // TODO: reduce current, then raise Damaged with the new value.
    }
}

using System;
using UnityEngine;

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

    public event Action<int> Damaged;

    void Awake() => current = maxHealth;

    public void TakeDamage(int amount)
    {
        current -= amount;
        Damaged?.Invoke(current);
    }
}

using UnityEngine;

public class HealthBarUI : MonoBehaviour
{
    [SerializeField] private Health health;

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

    private void UpdateBar(int newHealth) => Debug.Log($"[UI] Health: {newHealth}");
}

public class HurtAudio : MonoBehaviour
{
    [SerializeField] private Health health;

    void OnEnable()  => health.Damaged += PlayOuch;
    void OnDisable() => health.Damaged -= PlayOuch;

    private void PlayOuch(int newHealth) => Debug.Log("[Audio] Ouch!");
}

Summary

📚 Additional Resources

• Microsoft — C# Events (delegates & the event keyword)
• Scripting Reference — UnityEvent
• Unity — Architecting with ScriptableObjects (event channels)

🚀 What's Next?

Systems can now talk without tangling. Next we deal with time: Lesson 3.3, Coroutines and Async in Unity, covers spreading work across frames with IEnumerator/yield and how that compares to C#'s async/await — perfect for delays, sequences, and waiting on events like the ones you just built.