Anomaly Hours: Forest Cabin Devlog Massive Update. All Cameras Exposed - YouTube Gameplay Video & More News!

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!

 

 

UnityAction vs UnityEvent: The Real Difference (And When to Use Each)

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.

Inheritance vs Composition in Unity: Which One Should You Use?

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!

5 More Unity Coding Techniques Beginner Developers Probably Don't Know (Part 2)

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!

 

 

5 Coding Techniques Beginner Unity Developers Probably Don't Know

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!

 

Why These Unity Coding Techniques for Beginners Actually Matter

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!

Scope Creep In Game Development: What Is It, And The Best Way To Prevent It

You know that feeling when your "simple 2D platformer" somehow grows a crafting system, a day/night cycle, procedural weather, and a pet raccoon companion nobody asked for? That's scope creep, and it's the silent killer of more game dev projects than one line of bad code ever will be.

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.

 

Manager Classes in Unity: When They're Genius and When They're a Bad Idea

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.

SOLID Principles In Unity Explained Without Needing A Computer Science Degree

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!

 

So You Want to Build a VR Game for Meta Quest? Let's Actually Do It!

 
Here's the thing about VR development tutorials: most of them are written by people who already know everything, addressing an imaginary reader who apparently also already knows everything. You get a code snippet, a "simply configure your XR rig," and a vague sense that you missed a memo somewhere.

This series is not going to be that, so if you were expecting that; read another blog :P

I'm starting this the same way you probably are, with an idea for a Quest game and a Unity install that's never touched VR before. Over the next 14 articles, spread out over the beginning of the fall season, we're going from "WTF is an XR rig" to "My game is live on the Meta Horizon Store!"  

 

Why Meta Quest?

There's a lot of VR hardware out there, but Quest earns its own series for simple reasons: it's standalone and popular. No console or PC tether (although you could), no external sensors, just a headset someone bought and strapped on. That convenience is exactly what makes it the best on-ramp for indie VR dev, bigger install base, lower barrier to entry for players, and a genuinely mature toolchain now that Meta's XR SDKs have had years to sand off the rough edges. It's also, not coincidentally, the platform I'm going to build a project for. So consider this dual-purpose: you're getting a tutorial series, and I'm getting a build log!

 

What This Series Actually Covers

I'm going to write 14 articles that follow the real order things happen in, not the order they're fun to talk about:

Getting oriented (Parts 1-4): Why build for Quest at all, getting your dev environment actually working (this is the part where builds mysteriously fail and nobody explains why), understanding the alphabet soup of Meta XR SDKs, and getting a literal cube rendering in your headset. Unglamorous, but skipping it is how projects die in week one.

Core VR fundamentals (Parts 5-6):  Locomotion and comfort, arguably the most VR-specific design problem there is, since "how does the player move" can straight-up make people vomit if you get it wrong, followed by hand tracking and controller interactions.

Building your actual game (Parts 7-9): Designing a concept that works because it's VR, not despite it. Then the core gameplay loop, and a look at multiplayer basics for when "can my friend join" comes up (it always comes up).

Making it good (Parts 10-12): Mixed reality extras like Passthrough, performance optimization for standalone hardware (Quest is basically mobile-grade, treat it as so), and playtesting with actual humans who aren't you.

Getting it out the door (Parts 13-14): Submitting to the Meta Horizon Store, and what happens after launch, because "I shipped it" and "people are playing it" are two very different things. 

 

What You Won't See Here

Every deep technical rabbit hole! This blog series is deliberately the streamlined version, one concept, one working example, one clear next step per post. If you want the full depth, line-by-line implementation, every edge case, the stuff that would triple the length of each post, you want to read another blog!

 

Who This Is For

If you know your way around Unity but have never touched XR, you're in the right place. If you're VR-curious but a little intimidated by the ecosystem, also you. The one thing I'm assuming when writing the articles is that you know basic to intermediate C# and Unity editor familiarity.

As said, the series will be published in the beginning of the fall season. Stay up to date by subscribing to the feed, or follow any of my socials. I'll announce it there..so you won't miss a thing!

~ 

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