5 posts tagged with "Tutorial"

You need to delay an explosion by 2 seconds after a grenade lands. Simple enough. You write a coroutine. IEnumerator DelayedExplosion(), yield return new WaitForSeconds(2f), call the explosion logic. Maybe 10 lines if you're tidy. You feel good about it.

Then your designer says "the player should be able to defuse the bomb." Okay, now you need to store the Coroutine reference so you can call StopCoroutine(). But wait — what if the player defuses it before the coroutine starts? You need a null check. What if the game object gets destroyed mid-wait? Another null check. What if the player defuses it at the exact frame the coroutine completes? Race condition. Your 10 lines are now 25, and you haven't even handled the "show defused message vs. show explosion" branching yet.

This is the story of every time-based event in Unity. The first implementation is clean. The second requirement doubles the code. The third makes you question your career choices.

It's 3 PM on a Tuesday. Your designer leans over and says, "Hey, can we make the screen shake a little stronger when the player gets hit for more than 50 damage? And add a half-second delay before the hit sound plays? Oh, and the poison effect should tick every 1.5 seconds instead of 2."

Three changes. Maybe fifteen seconds of actual decision-making from the designer's perspective. But here's what actually happens: you close the Scene view. Open your IDE. Wait for it to load. Search for the damage handler. Find the screen shake intensity value buried in a method. Change it. Then find the audio delay -- that's in a different class. Change it. Then find the poison coroutine -- that's in yet another class, and the tick rate is part of a WaitForSeconds call. Change it. Save all three files. Switch back to Unity. Wait for recompilation. Test.

Eight minutes later, the designer says "actually, the shake was better before, and can we try the poison at 1.8 seconds?"

"I only have 5 minutes. Can you just show me how to make the event system work?"

Fair enough. No theory, no architecture deep-dives, no comparisons with other approaches. You want to go from zero to a working event-driven interaction in your Unity project, and you want to do it fast. Let's go.

This guide assumes you have a Unity project open (2021.3 LTS or newer) and about 5 minutes. By the end, you'll have an event that fires when something happens in your game and triggers a response on a completely separate GameObject — with zero direct references between them.

You start a new Unity project. You create ten events. OnPlayerDeath, OnScoreChanged, OnLevelComplete. You name them sensibly, drop them in a folder, and move on. Life is good. You can hold the entire event structure in your head.

Fast forward six months. You've got 200 events. The Project window is a wall of ScriptableObject files. You need OnPlayerHealthDepleted — or was it OnPlayerHPLow? Or OnPlayerHealthZero? You scroll through the list, squinting at names that all start with OnPlayer. After three minutes you give up and create a new one because you're not even sure if the event you want already exists.

This is where every event-driven Unity project lands eventually. And it's not because the event pattern is wrong — it's because nobody built the tooling for managing events at scale. Unity gives you the Animation window, Shader Graph, Timeline, the Input System debugger. Events get... the Project window.

You build GameEvent<T>. Clean, type-safe, elegant. You create a GameEvent<float> field for health updates and slap [SerializeField] on it. You switch to the Inspector. The field isn't there. It's just... gone. Unity is staring at you with a blank panel like you asked it to divide by zero.

It's Unity's oldest architectural headache. The serialization system doesn't understand generics. It never has. And every developer who's ever tried to build a type-safe, data-driven event system has walked face-first into this wall.

This isn't a minor inconvenience. It's the kind of limitation that poisons your entire architecture. You either give up type safety, drown in boilerplate, or accept that your beautiful generic design will never touch the Inspector. For years, the community answer has been "just write the concrete classes by hand." But here's the thing — if the boilerplate is 100% predictable, why is a human writing it?