I know Mondays can be rough - but also a great day to talk about the skill that separates "it's broken, and I have no idea why" from "found it, fixed it, moving on": debugging. Every Unity dev has stared at a wall of red text in the Console and felt their stomach drop. Here's the secret, though. That red text is usually telling you exactly what's wrong; you just need to know how to read Unity error messages.
Let's figure out some errors!
Welcome everyone to another blog post about the one idea that makes everything else in Unity click: GameObjects vs components in Unity. If you've ever wondered why a cube with nothing on it just sits there, or why every tutorial says "just add a component" like it's the most obvious thing in the world, this one's for you.
Let's try to figure this one out.
I recently finished The 7th Guest on Quest, and I walked away thinking it was an incredible game. Not "incredible for a VR game," just incredible. So I did what any curious dev would do and kept going. I tried a few more games on the Quest (Thief Simulator or Red Matter 2, anyone?), and the same question kept popping up in my head: wouldn't it be so much fun to make your own game for the Quest, and how exactly are people building this stuff?
For some of them, the answer is Unity. And if you already know Unity, you're closer to shipping something on Quest than you think. Yes, "closer" is doing a lot of heavy lifting in that sentence, but we'll get to that.
That's what got me thinking that Unity devs would really be interested in a comprehensive guide to Quest development. So here we are. This is Part 1, and it's the one where we figure out whether Quest development is actually for you. That's a lot cheaper than finding out after three weeks of building.
As promised for this fall: let's kick off the VR series! It's going to be 14 parts; that's the plan anyway. I'll try to post every Tuesday and Thursday, depending on my editing skills and available time. In the meantime, I'm still working on my own game, keeping busy!
Today we're doing something different from what you're used to. Instead of laying the focus on coding, we're diving into Unity itself. Let's start from the beginning and talk about the panel you probably stare at more than your actual code: the Inspector. If you've ever typed a variable into a script, went back to Unity, and watched a neat little slot appear like magic, you've already met Unity Inspector fields. What you might not know is exactly why some variables show up and others quietly don't. And also, how to use the Inspector properly - the way it was intended.
Let's elaborate!
Welcome to another blog post about a couple of little keywords that decide who gets to touch your variables: public, private, and [SerializeField]. If you've ever made a variable public just so you could tweak it in the Inspector, and then felt a vague sense of guilt about it, you're asking the classic public vs private C# question, and this one's for you.
Let's dive in!
Vector3 (a struct) constantly but your own custom data types are usually classes, this one's for you. Especially as a beginner, it's important to understand the differences between the two, since it can affect performance in your project! We're going to elaborate on the stack and the heap, and how exactly things are computed under the hood.Let's dive in!
If today == Wednesday && rainyWeather == false, then it's the perfect time to write a blog post about C# operators!
But what if today != Wednesday || any other day of the week? || weather == rainyWeather? Well, in that case, we could always grab a coffee, wait a little while, and try again.
Of course, we could also check whether coffee > motivation, whether deadline <= procrastination, || whether developer == "me" && coffee >= 2.
And if all of those conditions evaluate to true, then congratulations: you've already started using operators!
So, let's take a look at the little symbols that let us compare, calculate, assign, and make decisions in C#. After all, without operators, our code would have a pretty hard time doing much of anything.
Let's take a closer look, shall we?
It's Monday... I know. But what better day to start the week with a blog post about the thing that saves you from writing the same chunk of code 50 times across your project: methods in C#. If you've ever copy-pasted a block of code into three different scripts and then had to fix a bug in all three places separately, this one's for you. We're going over what it is exactly, and the best way to implement methods when you're building your program.
Let's go!
TGIF! Welcome to another blog post about a question nearly every beginner Unity dev asks at some point: should this be an array or a List? And if you're absolutely new to coding, what is it exactly? If you've ever stared at an inventory system or a spawn pool wondering which one to reach for, you're in the right place.
Let's go over this together!
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!