If you've ever Googled "how do I make a button call a function in Unity" and ended up more confused than when you started (which happens a lot in my case - yes I'm looking at you CodeMonkey!), you're not the only one.
"Unity Events," "C# events," and "UnityEvent" all sound like the same thing said three different ways.
Well, they're not. Surprise!
They're three genuinely different tools, each with their own tradeoffs, and picking the wrong one for the job is how you end up with either a spaghetti mess of references or a UnityEvent doing something a plain C# delegate would've handled in one line.
Let's sort out what's actually what.
First, Let's Kill the Naming Confusion
Here's the actual breakdown:
C# events → the native "event" keyword, built into the language
C# delegates → Action, Func, and custom delegate types
UnityEvent → UnityEngine.Events.UnityEvent, the Inspector-serializable one
"Unity Events" → the loose, informal term people use for any of the above
That last one is the troublemaker! When someone says "just use a Unity Event," they might mean the actual UnityEvent class, or they might just mean "wire up an event, using the inspector."
Context matters people!
For the rest of this article, I'll be specific and call out which one I mean, so you don't end up in the same boat. Let's just make it clear, once and for all!!
Option 1: C# Delegates (Action, Func, & Friends)
This is plain C#, no Unity involved. If you've written any amount of intermediate C#, you've probably used Action already, even if you didn't know it had a fancy name.
public class Health : MonoBehaviour
{
public Action OnDeath;
public void Die()
{
OnDeath?.Invoke();
}
}
Somewhere else:
health.OnDeath += HandleDeath;
void HandleDeath()
{
Debug.Log("Something just died. Probably dramatically.");
}
Fast, lightweight, zero Unity overhead. Action and Func live in System, so this works identically outside Unity too.
The thing is, it's not visible in the inspector. Designers can't wire this up, it's hard-coded in, subscriber and publisher both need to reference each other directly (or through something else that connects them), and if you forget to unsubscribe, you've got yourself a memory leak with your name on it (well, maybe not exactly YOUR name, but you get it)!
Option 2: C# Events (the actual 'event' keyword)
This is Action's stricter sibling. Functionally similar, but with guardrails.
public class Health : MonoBehaviour
{
public event Action OnDeath;
public void Die()
{
OnDeath?.Invoke();
}
}
Looks almost identical, right? The difference is what event restricts. With a plain Action, anything with a reference to Health can do this:
health.OnDeath = null; // wipes out every other subscriber.With event, external code can only use += and -=. It can't overwrite the whole thing, and it can't invoke it directly from outside the class. Only Health itself can call OnDeath?.Invoke().
So why doesn't everyone just always use event then? It has pretty much to do with laziness. Action fields are easier to expose, easier to assign directly (useful for testing or quick setup), and some patterns, like ScriptableObject-based event channels, lean on that flexibility. event is the safer default when you're building a public API that other systems will subscribe to and shouldn't be able to mess with.
Rule of thumb: if outside code has no business calling or clearing your event, use event. If you need that flexibility, Action is fine.
Option 3: UnityEvent
Now here's the one that actually shows up in you're Unity inspector.
public class Health : MonoBehaviour
{
public UnityEvent OnDeath;
public void Die()
{
OnDeath?.Invoke();
}
}
Drop this on a GameObject, and suddenly the Inspector shows you a little list where you can drag in other GameObjects and pick which public method to call when the event fires. No code required.
OnDeath (UnityEvent)
↓
[Enemy] → PlayEvent()
[UIManager] → ShowGameOverScreen()
[AudioManager] → PlayDeathSound()
This is exactly why UnityEvent exists: designers can hook up behavior without touching a script. Want the death animation, the game over screen, and the sound effect to all trigger off the same event? Drag, drop, done. No programmer required, no rebuild needed to test a tweak.
The tradeoff is performance and type safety. UnityEvents use reflection under the hood, which makes them noticeably slower than a plain C# delegate, which makes sense, not "your game will lag" slower for occasional events like death or game-over triggers, but absolutely noticeable if you're firing thousands of them per frame (please don't do that!). They're also easier to break silently: delete a metjod a UnityEvent was pointing at, and Unity won't always yell at you clearly about it until runtime.
You can also pass parameters:
[System.Serializable]
public class DamageEvent : UnityEvent<int> { }
public DamageEvent OnDamaged;
Now your Inspector-wired methods can receive the damage amount directly. Handy, but also another spot where a typo or mismatched type can quietly cause nothing to happen, and you'll spend twenty minutes wondering why the hell your UI isn't updating before realizing the method signature didn't match!
So Which One Do You Actually Use?
Depends on who needs access to the wiring.
Use C# delegates/Action when it's a purely code-side interaction. One system talking to another, no Inspector involvement needed, and performance matters (physics callbacks, per-frame logic, anything hot-path).
Use C# events when you're exposing something publicly that other scripts should be able to subscribe to, but shouldn't be able to clear or hijack. Think: a Health component broadcasting "I died" to whoever's listening, safely.
Use UnityEvent when a designer needs to hook things up without your involvement, or when the connections genuinely benefit from being visible and editable in the Inspector. UI button clicks are the most obvious example, but it applies to any "drag in a reaction" workflow.
A decent chunk of real projects end up using all three in different places, and that's fine. This isn't a "pick one forever" decision.
Button.onClick → UnityEvent (designer-facing, built into Unity's UI system)
Health.OnDeath → C# event (safe public broadcast)
Physics tick callback → Action (fast, code-only) A Quick Word on Performance
If you're building something where events fire constantly (like every physics step, or every frame) skip UnityEvent entirely. The reflection overhead adds up fast at scale, and there's no upside since nobody's hand-wiring per-frame logic in the Inspector anyway. Save UnityEvent for things that happen occasionally: button presses, deaths, level completions, dialogue triggers. That's exactly the range it was designed for.
Common Mistakes
Forgetting to unsubscribe. This applies to both Action and event. If an object subscribes in OnEnable and never unsubscribes in OnDisable, you've got a reference hanging around keeping that object alive longer than it should. Classic memory leak, classic "why is this destroyed object still responding to events" bug.
Overusing UnityEvent for internal logic. If nothing outside the script needs to see or configure the event, you don't need it exposed in the Inspector. A private Action does the same job faster and without the reflection tax.
Assuming event and Action are interchangeable. They're close, but event locks down external access on purpose. Swapping one for the other isn't just a style choice, it changes what other scripts are allowed to do.
Wrapping Up
None of these three are "the right one." They solve different problems: Action and event for fast, code-only communication, with event adding a safety rail for public APIs, and UnityEvent for anything that benefits from being wired up visually, usually by someone who isn't touching the codebase.
Know which situation you're in, and the choice mostly makes itself.
~Happy Coding!
No comments:
Post a Comment