Unity Events vs UnityEvent vs C# Events: Which One Should You Actually Use?

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!!

10 ScriptableObject Patterns Every Unity Developer Should Know (Part 3) Factory Pattern, AI Behaviors & Global Configuration

Over the last two articles, we've explored seven practical ways to use ScriptableObjects beyond simple data storage.

We've covered everything from Data Assets and Runtime Sets to Item Databases and Spawn Tables. Hopefully by now it's becoming clear that ScriptableObjects aren't just a convenient place to store numbers, colors or sprites, they're powerful architectural tools that can help keep your project organized as it grows.

In this final part, we'll look at three more advanced patterns that are particularly useful in larger projects.

Don't worry if some of these seem a little intimidating at first, you probably won't need all of them on your next game. In fact, you may never need them at all, but knowing about it is a great addition to your programmer's toolbox.

Remember, good architecture isn't about using every design pattern you know. It's about choosing the simplest solution that solves the problem in front of you.

Let's jump in.

 

10 ScriptableObject Patterns Every Unity Developer Should Know (Part 2) Variable Assets, Ability Definitions, Item Databases

In the previous article, we explored three of my favorite ScriptableObject patterns:

• Data Assets

• Runtime Sets

• Event Channels

If those patterns help organize your project, the next four we're covering today help organize your gameplay. They're all about making your game easier to balance, extend, and maintain without constantly diving into your code.

As with every design pattern, these aren't solutions looking for problems. They're practical techniques that shine in the right situations, and as always, can become overkill if used everywhere.

Let's jump in!

10 ScriptableObject Patterns Every Unity Developer Should Know (Part 1) Data Assets, Runtime Sets, Event Channels

If you've read my previous article on ScriptableObjects, you'll know they're far more than glorified data containers. Of course they're fantastic for storing weapon stats, enemy configurations, and game settings, but that's only the beginning.

One of the biggest "wait a minute sister" moments in my personal Unity journey was realizing that ScriptableObjects can also help shape the architecture of an entire project. They aren't just assets sitting quietly in your Project window; they can become communication hubs, registries, and reusable building blocks that make your code cleaner and easier to maintain.

In this mini-series, we're going to explore ten practical ScriptableObject patterns that I sometimes use in my own Unity projects. These aren't theoretical examples you'll only find in programming textbooks. They're patterns that solve real-world problems you'll encounter as your projects grows.

Learning all these patterns is important in my opinion. Even if you don't plan to use them now, you at least know which options are available - and perhaps you may find one useful in the future. All extra useful knowledge you can add to your programmer's toolbox.

In this first part, I'll cover:

• Data Assets

• Runtime Sets

• Event Channels

   

Let's dive in.

 

Unity 7 Is Coming! Here's Everything You Need to Know

If you've been using Unity for a while, you've probably developed not only your game, but also a healthy amount of skepticism whenever a new major version is announced. We've all seen the flashy presentations, heard promises about revolutionary features, and then gone right back to waiting for shaders to compile while questioning our life choices.

Thankfully, Unity 7, scheduled to be released early 2027, does feel a little different.

Instead of trying to reinvent the engine again, Unity seems to be focusing on something developers have been asking for years: making the engine faster, smoother, and more enjoyable to use every day.

And honestly? That's exactly what I want!

Will they live up to that promise? Who knows, it's a step in the right direction at least.  

I don't need another dozen experimental systems that may or may not exist two years from now. I need my projects to open faster, Play Mode to start quicker, and the editor to spend less time making me stare at loading bars.

Let's take a look at everything Unity 7 is bringing to the table.

ScriptableObjects In Unity And The Hidden Superpowers Most Overlook

When you first encounter ScriptableObjects, it's usually introduced as a way to store data outside of a scene. You create an asset, fill in some values in the Inspector, and suddenly you've got a cleaner alternative to hardcoded variables.

But that's only scratching the surface. It can do more than just hold data!

ScriptableObjects is one of Unity's most powerful and often misunderstood feature. If used correctly, it can simplify your architecture, reduce dependencies, improve reusability, and make your project significantly easier to maintain as it grows.

Unfortunately, it also has a reputation for being overengineered. Spend enough time on Unity forums, and you'll eventually find someone suggesting ScriptableObjects as the solution to virtually every problem. Need an inventory? ScriptableObjects. Dialogue? ScriptableObjects. AI? ScriptableObjects. Coffee machine broken? ...okay, perhaps not that one.

Like any tool, it's at its best when solving the right problem.

Let's deep-dive into what ScriptableObjects really are, when/how/why you should use them, and when it's definitely not the answer.

Don't Ditch Coroutines for Async/Await in Unity Until You Read This

If you've only ever worked with coroutines, switching to async/await can feel almost magical. The code is cleaner, easier to read, and behaves much like synchronous code.

However, there's an important difference: Tasks are a .NET feature. Coroutines are a Unity feature.

That distinction affects how they interact with Unity's object lifecycle, scene management, and exception handling.

These differences are responsible for many of the mysterious NullReferenceExceptions and "WTF it worked yesterday!!" bugs that developers encounter when first adopting async.

---

Tasks don't adhere to Unity object lifetimes

This is arguably the biggest gotcha.

Imagine you write a simple async method to open a door:

public async Task OpenDoor()
{
    await Task.Delay(3000);

    animator.SetTrigger("Open");
}
  

Everything works perfectly until the player changes scenes, or destroys the object...or exits play mode. Three seconds later, the task resumes anyway. Now animator no longer exists.

NullReferenceException

You may wonder:

"The GameObject was destroyed. Why is this code still running?"

Because Tasks have no clue what a GameObject is. They're managed entirely by the .NET runtime.

---

Coroutines vs Async/Await vs Awaitable in Unity: Making Sense To Modern Asynchronous Programming

Coroutines have been pretty much the backbone of asynchronous programming in Unity for a long time. When you need to spawn enemies, fade a UI, load a level, or create cinematic sequences, chances are you wrote countless methods returning IEnumerator.

However, Unity has other options regarding this that may be better for your project.

Modern versions of Unity embrace C#'s async/await programming model and, more recently, introduced Awaitable, a Unity-specific asynchronous API that integrates directly with the engine. These additions don't replace coroutines outright but they complement them and, in many situations, offer cleaner, safer, and more powerful alternative.

Perhaps the challenge for many Unity game developers isn't learning the syntax, it's knowing which tool is better for the task at hand.

Let's take a deep-dive into Coroutines, async/await, and Awaitable, including threading, Task.Run(), CancellationToken, AwaitableCompletionSource, performance considerations, and strategies for migrating existing coroutine-based projects.

Singleton Game Design Patterns Done Right in Unity (With Code Examples)

Ahh, Singletons... probably one of the most debated game design patterns in Unity development. A quick Google search often reveals two camps. Those who swear by it, and those who avoid it like the plague. 

Not that long ago, I was in the latter camp. But ever since I ran into some issues, I'm switching back to the other side. Now, how do you use persistent and non-persistent Singletons effectively in Unity?

 

 

Let’s first briefly go over what a Singleton is for those unfamiliar with the concept.

 

Overengineering Code in Unity: When Good Game Architecture Can Become a Problem

Back in September of this year, I wrote an article about decoupling game systems in Unity with an EventBus. This is a crucial part of  game architectural design, and should be implemented in those areas of your project that make sense. Once you understand it, you're probably eager to implement it everywhere! But be aware that this can also lead to some unwanted results in your project.