It's Friday!! And welcome to another blog post about a piece of logic you'll write more than almost anything else in your game: if statements in C#. If you've built even a tiny prototype in Unity, you've already written dozens of these without necessarily thinking about the "why" behind them: checking if the player's health hit zero, checking if a key was pressed, checking if an enemy is in range.
Let's dive in!
We're going over the 4 major types of loops you need to know. If you've ever found yourself copy-pasting the same line of code five, ten, or twenty times just to do the same thing over and over, you're about to feel a little silly, because that's exactly what loops are built to solve.
Let's dive in!
int score = 0; without really knowing why it works, or why it had to be int and not something else. Alright, that's fair; hardly anybody explains it well the first time around. Maybe I can shine some light on this topic.
You've probably heard of Object Oriented Programming, but what does it mean exactly? One may think it's pretty obvious. Well, it's not. OOP is one of those terms that gets thrown around in job listings and Reddit threads until it stops meaning anything.
Here's the thing though: Unity is built on OOP. Every MonoBehaviour you've ever written is a class. Every GameObject you drag components onto is basically a walking demonstration of composition. So whether you've been "using OOP" on purpose or by accident, you've already got your hands dirty.
The 4 principles; encapsulation, inheritance, polymorphism, and abstraction, all sound like you need a degree in computer programming - but after reading this article, you'll be surprised how simple it really is. They're the difference between a codebase you can expand on for years and one that collapses the moment you add a third enemy type. Let's go through them one at a time, Unity-style.
Welcome to another blog post about writing Unity code that doesn't make you want to throw your laptop out the window. Today's topic: state machines in Unity!
If you've ever written a PlayerController with six bools (isJumping, isRunning, isAttacking, isDead, isReallyDead, isDefinitelyDeadThisTime) and a 100-line Update() full of nested if statements, this one's for you.
Let's have a look!
Here we go again, yet another blog post about a debate that's been quietly ruining developer's sleep since the dawn of object-oriented programming. Sit back and relax, because we're finally settling the "interface or abstract class" argument.
As a solo game developer like myself, you don't have a senior architect looking over your shoulder telling you your class hierarchy is a big mess. When it comes to interfaces vs abstract classes in Unity, the choice you make on day one tends to snowball... and it'll either be a clean, swappable system, or turn into a tangled inheritance chain you'll be untangling weeks from now. Fully understanding both of them is important, especially at the beginners stage, since this is not even an intermediate topic.
Both let you enforce structure across your scripts. Neither is "wrong." But picking the wrong one for the wrong job is how you end up with an Enemy abstract class that fifteen unrelated objects are awkwardly pretending to inherit from just to get one shared method.
Welcome to another blog post about async programming in Unity, which async should you use? Let's elaborate. If you've ever Googled this while your coroutine spaghetti stared back at you accusingly, you're in the right place. Let's get you something to ponder on over the weekend!
The thing is, Async/await in Unity used to mean one thing: System.Threading.Tasks.Task. Then UniTask showed up and made everyone's coroutines look ancient. Unity's shipped its own native Awaitable type, and suddenly you've got three ways to do the same thing, each with its own opinions about your garbage collector.
So which one should you actually reach for? Let's break down the Task vs UniTask vs Awaitable performance story, the API differences, and where each one earns its spot in a solo game developers toolkit.
Back in the day when I first started programming in Unity (during COVID) this was probably one those hard concepts to wrap my head around. I kept mixing them up, and didn't know which one to use when. When I did a google search I was left even more confused! I thought, hey, now that I actually understand the whole thing; why not write an article about it because it's actually really simple.
So, do you use a UnityAction, or do you opt for a UnityEvent? They sound kind of the same. They show up in similar places, and yet mixing them up in the wrong context can leave you debugging phantom null references for a loooooong time, wondering why your inventory system just... stopped listening.
So, let me try to explain it in my own words and hopefully I can make some sense of it all, including exactly when to use UnityEvent in Unity, and when it's just adding overhead for no reason.
How many time have you argued with yourself: should this Enemy class inherit from a base Character class, or should it just be a GameObject wearing a trench coat made of components? Welcome to the inheritance vs composition in Unity debate, a fight that predates Unity by decades, but hits differently when you're the only person who has to live with the consequences of your own architecture.
This isn't an academic computer science debate for you. You're a solo dev. There's no team lead to quietly blame when your class hierarchy buckles under its own weight six months from now. So let's skip the theory-heavy stuff and talk about what actually matters when you're picking a side (or perhaps, you choose a combination of both in your project).
Let do it!
Back for round two? Good. I hope you've read the previous article.
If Part 1 covered TryGetComponent & friends, this batch is about the stuff that happens around your components like tags, cameras, and the Inspector itself quietly judging your field values.
Same thing as before: five more practical Unity coding techniques for beginners, real code and no fillers.
Let's begin!
So you've got Start() and Update() down cold. You can drag a reference into the Inspector in your sleep. But somewhere between "my game runs" and "my game runs well," there's a pile of small C# tricks that never quite make it into the beginner tutorials because, let's be honest, most tutorials are just trying to get a cube to move.
This is the good stuff you'll eventually come across, just like I did. Five underrated Unity coding techniques for beginners, with real code, zero fluff!
If you're a solo dev, you're the programmer, designer, and marketing team all at once. That means every shortcut that saves you five minutes today saves you an hour six months from now when you've forgotten why you wrote something the way you did.
These are NOT advanced architecture patterns. You won't need a computer science degree or a whiteboard full of arrows. They're small, practical Unity coding techniques for beginners that quietly make your code safer, faster to write, and less likely to break the moment you rename something.
Let's dive in!
A manager class is likely one of the first things you have written in Unity. GameManager, AudioManager, UIManager, SaveManager, they show up in every tutorial, every asset store project, every "clean architecture" YouTube video with a thumbnail of a guy with a weird looking beard pointing confused at a whiteboard.
And look, managers work, and that's exactly the annoying part to explain - but I'm going to try anyway. Managers work well enough, for long enough, and then you don't even notice the problem until your GameManager is 2,400 lines long and touches literally everything in your project. At that point it's not a manager anymore. It's a god object wearing a manager costume.
Let's talk about when managers are genuinely good architecture, when they quietly rot, and how to tell the difference before your Inspector starts looking like a control room of a spaceship.
FIVE letters, TEN intimidating words, and a bunch of academic jargon that make your eyes glaze over before you even get to the point. Somewhere along the way, "SOLID principles" got a reputation for being something only enterprise developers care about in between coffee breaks and standup meetings.
Here's the thing though: you've probably already broken (or followed) most of these principles in your Unity projects without knowing they had names. SOLID isn't some separate discipline you need to learn, it's just a handful of common-sense guidelines for not making your future self miserable.
Let's go through all five, Unity-style!
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.
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!!
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.
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!
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.
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.
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.
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 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.