🎛️ Lesson 2.4: ScriptableObject Event Channels (Mini-Project)

The Big Idea: Data-Driven Events

In Lesson 2.2, a subscriber needed a direct reference to the publisher: [SerializeField] Health health; then health.OnDied += …. That's fine within one scene, but it breaks down when the publisher and subscriber live in different scenes (loaded additively) or are spawned at runtime — you can't drag a reference across a boundary that doesn't exist yet.

The fix is to put the event itself into a shared asset. Both sides reference the asset, never each other. The raiser says "raise this channel"; the listener says "when this channel raises, do my thing." Because the channel is a ScriptableObject in the Project, everyone can reference it — across scenes, across prefabs, across spawn timing.

💡 Why not just a static event or a Singleton? A static event or a global GameManager.Instance also lets anyone talk to anyone — but it re-introduces a hidden hard dependency on that one class, and it doesn't show up in the Inspector. Channels are visible assets a designer can create, name, and wire, and there can be as many as you like (OnPlayerDied, OnScoreChanged, OnBossSpawned).

Building GameEvent

The channel is a ScriptableObject that keeps its own list of listeners and offers Register, Unregister, and Raise. Note we walk the list backwards in Raise so a listener that removes itself mid-broadcast can't corrupt the loop:

using System.Collections.Generic;
using UnityEngine;

[CreateAssetMenu(fileName = "NewGameEvent", menuName = "Events/Game Event")]
public class GameEvent : ScriptableObject
{
    readonly List<GameEventListener> listeners = new();

    public void Register(GameEventListener listener)
    {
        if (!listeners.Contains(listener)) listeners.Add(listener);
    }

    public void Unregister(GameEventListener listener)
    {
        listeners.Remove(listener);
    }

    public void Raise()
    {
        // iterate backwards: a listener may unregister during its response
        for (int i = listeners.Count - 1; i >= 0; i--)
            listeners[i].OnEventRaised();
    }
}

Each named channel is one asset. Create Assets ▸ Create ▸ Events ▸ Game Event and make OnPlayerDied, OnGameOver, and so on — one file per kind of announcement.

Building GameEventListener

The listener is a MonoBehaviour you drop on any GameObject. It holds a reference to the channel asset and a UnityEvent that a designer wires in the Inspector. It registers in OnEnable and unregisters in OnDisable — the exact discipline from Lesson 2.2:

using UnityEngine;
using UnityEngine.Events;

public class GameEventListener : MonoBehaviour
{
    [SerializeField] GameEvent gameEvent;   // which channel to listen on
    [SerializeField] UnityEvent response;   // what to do, wired in Inspector

    void OnEnable()  => gameEvent.Register(this);
    void OnDisable() => gameEvent.Unregister(this);

    public void OnEventRaised() => response.Invoke();
}

And raising is trivial — any script that has a reference to the channel just calls Raise():

public class PlayerHealth : MonoBehaviour, IDamageable
{
    [SerializeField] int maxHealth = 100;
    [SerializeField] GameEvent onPlayerDied;   // the channel to raise
    int current;

    void Awake() => current = maxHealth;
    public int CurrentHealth => current;

    public void TakeDamage(int amount)
    {
        current = Mathf.Max(0, current - amount);
        if (current == 0) onPlayerDied.Raise();   // shout into the channel
    }
}

PlayerHealth references only the channel asset, not the UI, not the audio, not the game-over screen. It has no idea anyone is listening.

The Channel Architecture

Here's the whole shape. The GameEvent asset sits in the middle like a radio frequency: raisers broadcast on it, listeners tune in, and the two sides never touch:

Figure 1: The event-channel architecture. Every arrow points at the asset, never at another system. Raisers and listeners can live in different scenes and still connect.

Compare this with the observer diagram from Lesson 2.2: it's the same one-to-many broadcast, but the publisher has been replaced by a shared asset. That single move is what lets the connection survive scene boundaries and runtime spawning.

Channels That Carry Data

A bare Raise() is enough for "the player died," but many events carry a value — a new score, a health fraction. Make a generic-feeling variant that passes an int (Unity serializes concrete types, so we make a concrete IntGameEvent). The listener uses a UnityEvent<int>:

using System.Collections.Generic;
using UnityEngine;

[CreateAssetMenu(fileName = "NewIntEvent", menuName = "Events/Int Game Event")]
public class IntGameEvent : ScriptableObject
{
    readonly List<IntGameEventListener> listeners = new();

    public void Register(IntGameEventListener l)   { if (!listeners.Contains(l)) listeners.Add(l); }
    public void Unregister(IntGameEventListener l) => listeners.Remove(l);

    public void Raise(int value)
    {
        for (int i = listeners.Count - 1; i >= 0; i--)
            listeners[i].OnEventRaised(value);
    }
}

using UnityEngine;
using UnityEngine.Events;

public class IntGameEventListener : MonoBehaviour
{
    [SerializeField] IntGameEvent gameEvent;
    [SerializeField] UnityEvent<int> response;   // receives the int

    void OnEnable()  => gameEvent.Register(this);
    void OnDisable() => gameEvent.Unregister(this);

    public void OnEventRaised(int value) => response.Invoke(value);
}

Now a ScoreManager can onScoreChanged.Raise(newScore) and a score-label UI can receive the number straight into its SetScore(int) method — with neither knowing the other exists.

Mini-Project: A Score & Health System on Channels

Let's assemble the real thing. Every system talks only through channels — pull any one system out and the rest keep compiling. Here's the plan:

1. Create three channel assets under Assets ▸ Create ▸ Events: OnScoreChanged (Int Game Event), OnHealthChanged (Int Game Event), and OnPlayerDied (Game Event).
2. Gameplay: a Pickup raises OnScoreChanged when collected; PlayerHealth raises OnHealthChanged when hurt and OnPlayerDied at zero.
3. UI: a score label and a health bar each hold a IntGameEventListener whose response calls their own SetScore/SetFill. A game-over panel holds a plain GameEventListener on OnPlayerDied.
4. Audio: an AudioSource with a GameEventListener on OnPlayerDied whose response is AudioSource.Play.

Wiring a listener is all Inspector work. Here is the GameEventListener on the Game-Over panel, listening to OnPlayerDied and calling two responses — drawn faithfully:

Press Play and take damage until you die. The health bar drains, the score persists, the Game-Over panel appears, and the sting plays — yet PlayerHealth imports none of those systems. Delete the audio GameObject and everything else still works: proof of full decoupling.

Trade-offs & When to Use It

Channels are powerful, not free. Be honest about the costs:

• Indirection. Following "who reacts to OnPlayerDied?" means searching the scene for listeners rather than reading one method. Name channels clearly and keep them in a dedicated folder.
• Setup overhead. Creating an asset and wiring listeners is more clicks than a direct call. For two objects in one scene that will never move, a plain C# event (Lesson 2.2) is simpler — use it.
• Debugging. Because the link is data, a typo in wiring fails silently. Consider a debug Raise button or logging inside Raise() while building.

Reach for channels when systems are far apart — different scenes, spawned at runtime, or owned by different team members — or when designers need to rewire reactions without you. For tightly-scoped, same-scene messaging, the lighter tools you already learned win.

💡 Module 2, in one sentence. Interfaces decouple the caller, events decouple the reaction, ScriptableObjects decouple the data — and event channels combine events and SOs so even whole scenes can talk without knowing each other's names.

Extend the Project

Summary

🚀 What's Next?

That completes Module 2 — you can now build games out of decoupled systems that talk through interfaces, events, ScriptableObjects, and channels. Every module from here leans on these foundations. Next we retire the legacy input handling you learned in Fundamentals: Lesson 3.1: Why the New Input System & Installing It kicks off Module 3, where device-agnostic controls replace the old Input class for good.