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.
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.
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.
It’s official! Anomaly Hours: Forest Cabin has been approved for Steam and now has a page on the store!
This first chapter in the Kinley family’s haunting story invites you to uncover the strange events surrounding a remote forest cabin after a mysterious death.
You’ll monitor rooms through security cameras, spot eerie anomalies, and piece together a chilling mystery that can change with every replay. Each hour holds something new, and no two playthroughs are ever the same!
The anomaly game Anomaly Hours: Forest Cabin is planned to be in early-access so we can fine-tune the overall player experience. Become part of the community!
I'm aiming on a few live streams on our Twitch channel in the near future about this upcoming anomaly game. If you can't make it to the live stream session, I always upload to our YouTube channel as well.
You can now visit the Steam page to learn more, add the game to your wishlist, follow game development updates, as well as its official release date.
Does your game or application in Unity use a lot of update loops that slow down performance? No need to install plug-ins or special packages, greatly increase performance for free with an update publisher in Unity. It makes you wonder why this isn’t a standard feature anyway (but that goes for a lot of things in Unity).
We’re basically going to make a SINGLE type of update loop for your entire project! As you can imagine, this will lead to a massive performance boost for your game, especially if you use a lot of scripts that implement any kind of update loop.
Understanding the issue:
What's the problem? Let’s address the issue of update loops in the first place (like Update, FixedUpdate, or LateUpdate) in Unity, because it's more complex than you may think.
When you put code in an update loop to move a game object, like transform.position += new Vector3(0, 0, 1) * Time.deltaTime;, under the hood a lot of different checks are being performed before the update loop is even validated and started. First, Unity checks if the object hasn’t been destroyed yet, then there's checks if the requirements have been met to be active at all. Even when it passes all these checks, Unity still needs to confirm that its own update method is functioning properly.
So basically, even BEFORE Unity runs the actual update loop, it’s doing all these involved computations, behavior iterations, call validations, preparing to invoke the method, verifying all the arguments and then finally running the little piece of code you wrote (which hardly is a performance issue compared to the aforementioned. Yes, this even happens with empty update methods accidentally left behind in scripts!
This slows down your project tremendously, and gets worse the more update loops you have!
When you have lots of objects that implement any update loop in Unity, you can see the problem if it needs to perform these under the hood checks constantly.
Come on!
But what can we do about it? This is yet another case where the Observer Design Pattern comes in!
The Solution:
First, we’re going to make an UpdatePublisher that lives in the scene on its own GameObject. It holds the ONLY Update method in the game, and it’ll notify all the other listeners when it’s called.
The observer itself is an interface, we’ll call it IUpdateObserver:
public interface IUpdateObserver
{
void ObservedUpdate();
}
