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!
Welcome to another blog post about the stuff that quietly runs your entire game, whether you think about it or not. This Wednesday's topic: understanding the game loop in Unity; Awake, Start, Update, FixedUpdate, LateUpdate, OnEnable, OnDisable, Reset, teardown methods, coroutines, and a peek at the rendering callbacks.
If you've ever wondered why your player controller moves like it's had too much coffee on some frames and none on others, or why a script that "should" be running just... isn't, chances are you've got a game loop misunderstanding on your hands.
This stuff isn't glamorous, but it's foundational. Get it wrong, and every system you build on top of it inherits the wobble.
Let's have a closer look at how it all works together.
Welcome to another blog post about Unity for absolute beginners. If you've searched around for "how to start Unity," you already know the drill: install the engine, drag a cube into the scene, slap a Rigidbody on it, write ten lines of code to make it jump. Video over, you made the thing move, it feels really productive right?
That's actually how I started learning Unity as well. But I was struggling really bad. I could not wrap my head around what and why things were happening. Now, that I have been using Unity to design my games for over 6 years, I understand what my biggest issue was trying to learn the engine. That's why my teaching method is a different from all the others out there.
Here's the problem, and I understand why most people would quit after taking a course or two. Not because Unity is too hard, but because nobody explained what's actually happening under the hood before throwing them at the code editor. You can't debug what you don't understand, and you definitely can't build anything beyond a tutorial's exact steps if you don't know why those steps exist in that order.
So my approach is unusual. At this stage you don't have to learn how to make the player jump. Instead I'm going to cover the three things I wish someone had explained to me before I touched a single script: the game loop, how references work, and why starting stupidly small is the actual skill that separates people who finish games from people who don't.
Let's dive in!
Hey guys! Welcome to another Anomaly Hours: Forest Cabin big update. It's been awhile since my last one, and that's because I haven't sat still!
First and foremost, a big thank you to everybody who has wish-listed the game on Steam. With around 114(!) wish-lists already!! Thank you!
The news is that many features were added to my upcoming survival horror anomaly game. I won't go over all of them, but let's go over on the things that I want to highlight. In this update I'll show you all the camera views of the game! Also, what to expect when you play through all the anomaly hours - and some behind the scenes stuff if you're interested. The planned release date is Q4 of 2026!
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!
In game development it doesn't announce itself with a warning siren. It sneaks in one "just one more feature" at a time, until your six-month project is somehow entering year two with no end in sight.
Let's talk about the best way to prevent it before it crawls into your project.
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!
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.