Welcome back to the deep dive. Hey there, So today we're opening up the hood on something that I think keeps a lot of people up at night. Oh yeah, it's that massive, you know, that intimidating chasm between being a bedroom coder hacking things together until they mostly work.
Hoping for the best. Yeah, I know that.
Stage, and then the other side being an actual certified professional developer.
It is a huge leap. I mean, it's the difference between building a treehouse in your backyard and building a skyscraper. They both use wood and nails, you know, But if you build the skyscraper the way you build the treehouse, it is going to fall down exactly.
And to help us navigate that construction site, we are looking at the Unity Certified Programmer Exam Guide by Philip Walker. Now hold on, I know you're thinking a test prep book.
Really I had the same reaction, I'll be honest, right.
I mean, usually these things are just dry lists of multiple choice questions. But as we dug into this, it became clear that this isn't really just about passing a test, No, not at all. It's a manifesto on how to think like a software engineer.
It is Walker uses this project aside scrolling shooter called Killer Wave, to basically dismantle all your bad habits and rebuild them from the ground up.
It's almost like a stealth textbook.
It is. Yes, the explicit goal is to get you that Unity certification, but the real value is that it forces you to look at your code and ask, will this scale right?
Can five other people work on this without wanting to strangle me?
Exactly? That's the real question.
So that brings us to the why why even bother with certification? In the creative world, we always hear portfolio as king just show me the game. If the game's fun, who cares about the code?
That is the classic argument, and it has some merit. But Walker makes a really sharp point here, which is, let's say you've been working at a studio for three years. You're writing these complex, amazing systems, but you're under a strict NDA. You can't show that code to a future employer. It's invisible.
Or or maybe you're a computer science grad. You've got four years of theory, you know algorithms inside and out, but you have never actually shipped a title on Steam or the app store.
Exactly. You have the skills, but you have zero proof.
So that's where certification comes in.
It's a standardized stamp of approval. It tells a hiring manager I know the Unity API, I understand architecture, and most importantly, I know how to work in a professional pipeline. It validates the skills when the work itself is invisible.
So it's basically a badge that says I am not a liability.
That's a harsh way to put it, but yes, pretty much. It proves you aren't going to break the build on day one.
So what does this exam actually cover. Walker breaks it down into six pillars. We won't bore you by just reading the syllabus, but I think the roadmap is important for sure. We're talking core interactions, the art, pipeline, application systems, scene design optimization, and the big one working in.
Teams, working in teams, And honestly, if you're a self taught dev, that working in teams part is usually the blind spot. You can be a wizard at C sharp, but if you don't understand version control or how to structure a project for others, you're going to hit a wall hard.
Well, let's hit that wall together and see if we can climb it. I want to start with the meat and potatoes of the book, The Architecture of Code. Okay, Walker spends a huge chunk of time on design.
Patterns, rightfully, so this is the foundation.
So for the person listening who just opens Unity, creates a script called player controller, and then types everything into void. Update.
We've all been there.
Let's back up. What exactly is a design pattern?
Think of design patterns as the common language of engineering. If you and I are building a house and I say we need a Victorian roof, you instantly have a mental image of the structure.
Right I know what that means.
I don't have to explain every single beam and shingle. Design patterns are the same for code. They are standard blueprints for solving common problems that developers have faced for decades.
So instead of reinventing the wheel every time I need to spawn an enemy, I just use the wheel pattern precisely.
The book reference is the famous gang of four categories, creational, structural, and behavioral.
It's about organizing your toolbox exactly.
Do you need to make something that's creational? Do you need to connect things that's structural? Do you need things to communicate behavioral.
Let's unpack the ones Walker says are essential for the exam. First up, the builder pattern. I feel like the definition is often so dry, but Walker uses a car analogy that actually made it click for me.
The car analogy is a classic. So imagine you have a script for a car, but then you need a red car, okay, then a red car with sunroof, then a blue car with turbo engine.
If you do that with inheritance, making a new script for every single variation, you end.
Up with hundreds of scripts. It's a complete nightmare. The builder pattern separates the construction from the object itself.
How does that work?
You have a builder script that acts like an assembly line, he says, Okay, start with a chass he now paid it. Read now add the sunroof. You write the logic for adding a sunroof once and you can apply it to any car.
It's like a sandwichop. You don't have a pre made sandwich for every mathematical combination of ingredients. No, you have a sandwich builder line.
Perfect analogy. It keeps your code dry. Don't repeat yourself.
Now, moving to a pattern that I feel like every Unity developer has a complicated relationship with the singleton.
Ah, the singleton the highlander of design patterns.
There can be only one.
There can be only one.
Walker seems torn on this. He acknowledges it's useful, but he also calls it dangerous. What's the deal?
So a singleton is a way to ensure a class has only one instance, and it gives you a global access point to it.
Yeah.
In Unity we do this constantly with managers.
Game manager dot instance, Audio manager dot instance.
Right. It lets any script in your game talk to the manager immediately.
Which feels incredibly convenient. Right, I don't have to drag and drop references in the inspector. I just type the code and works.
It is convenient, but that convenience comes at a huge cost. It creates what we call tight coupling, meaning suddenly every script in your game is dependent on this one manager. If you change something in the manager, you might break ten other unrelated systems.
It's like having one central power strip for your entire house. If it trips the fridge, the TV and the lights.
All go out exactly, and it often leads to god classes the scripts that just do way too much. But for the exam you need to know.
How to write one, and more importantly, when to use it right.
Usually for high level systems like audio or score, it's acceptable for the player's inventory. H maybe not.
Okay, one more pattern before we move on, and this one feels non negotiable for performance. The object pool.
Oh, if you want to make mobile games or just games that don't lag, you need object pooling.
Walker uses a ten bullet's analogy. That really clears this up. So let's walk through the pain point first, the standard rookie way. I press the fire button, the game instantiates a bullet. It creates it, the bullet flies off screen. I destroy the bullet.
And the CPU weeps. Creating memory and destroying memory is expensive. It creates garbage, and when the garbage collector runs to clean it up, your game freezes for a few milliseconds.
That's a frame drop.
That is a frame drop. If you're firing a machine gun, you're game because a slide show.
So what does the pool do?
The pool creates, say ten bullets. When the game loads, they're all just sitting there deactivated. When you fire, you grab one, you activate it, you shoot it. When it hits the wall, you don't destroy it. You just turn it off, you just deactivate it and put it back in the line.
So you're just recycling the same ten plastic bottles forever.
Zero memory allocation during gameplay, zero stutter, smooth, sixty frames per second. It is the difference between an amateur project and a professional release.
Okay, if we've got our blueprints, now we need the rules of the road. Walker dedicates a heavy section to the Solid principles. If this is an acronym solid, I feel like this is the vegetables of programming. Oh. Absolutely, everyone knows they should eat them, but they'd rather just hack something together.
It is the vegetables. Yeah, but if you don't eat your vegetables, your code gets scurvy. It becomes brittle and it rots. Solid is all about keeping your code flexible.
Let's run through them rapid fire style, but keep it practical. S is single responsibility.
One script, one job. Do not make a player script that handles movement, health, shooting, inventory and UI updates. Wow, break that into player movement, player health, player combat.
This makes you bugging so much easier if the player can't jump, I know exactly which file to open precisely. I don't have to scroll through line four thousand of the god script.
It keeps the cognitive load down.
Oh is open closed, open for extension, closed for modification. This one always trips people up.
Okay, think about the Killer Wave spaceship. You've written the code for the show. It works. Now you want to add a laser beam weapon. The rookie way is to open the ship script and type if weapon do laser things. You're modifying working.
Code, which risks breaking it. The open closed way is to design the ship to accept a generic weapon object. To add the laser, you create a new laser script and just plug it in.
So you extended the functionality without modifying the original ship code.
Got it.
Don't perform surgery on a healthy patient just to give them a new hat. I like that.
I'm stealing that one.
L is lisk of substitution. This sounds like a physics theorem.
It sounds intimidating, but it's simple logic. It just means a subclass must be able to stand in for its parent without crashing the game.
Okay, give me an example.
The rubber duck analogy. You have a class called duck and it has a method called quack. Then you make a subclass called rubber duck. Right, but rubber ducks don't quack. They squeak, maybe they don't make noise at all. If you write code that forces the rubber duck to throw an error when quack is called, you've broken lisk off because the game expects anything labeled duck to be able to quack safely.
Right. If you have to write code somewhere else that says, if this is a rubber duck, please don't call quack. You failed the principle. Your code is now full of special exceptions, which is where bugs live.
I is interface segregation.
Don't force a script to use methods it doesn't need. Walker gives a great example. An interface called iActor that has health and strength works for a goblin.
Yeah, that makes sense, But what if you have a crate.
A create have health, it can break, but does it have strength.
No, So don't force the crate to have a strength variable just to satisfy the interface exactly.
Split it into idamageable and eye attacker. Keep your interfaces small and specific. It keeps your code clean.
And finally, d dependency inversion.
Lean on abstractions. Don't write code that depends on the AK forty seven script. Write code that depends on the webon interface.
So that way, if you swap the AK forty seven for a banana gun, the player controller doesn't care.
It doesn't care at all, knows it's holding a weapon.
It really all comes down to future proofing. You're assuming that you will change your mind later, so you write code that lets you do that without burning the house down.
Game development is ten percent coding and ninety percent changing your mind. Solid protects you from yourself.
Let's talk about the actual test bed for all this theory, the Killer Wave Project. It's a futuristic side scroller, a.
Classic genre player moves right, three lives waves of enemies. But Walker uses this simple premise to show off a really complex architecture.
He doesn't just start coding, No, he starts.
With UML unified modeling language. He diagrams the whole thing out.
He defines the relationships before writing a single line of C sharp yep.
He sets up the scene manager, the score manager. But the key part, I think is the interface iActor template.
What does that do?
It acts as a contract says anything in this game that is alive must have an attack function and a die function.
So whether it's the player as sign way enemy or the final boss. The game knows how to treat them exactly.
The game loop doesn't care if it's a wave enemy that moves in a sign pattern or a flea enemy that runs away. It just sees an eye actor. The specifics are hidden inside the enemy class.
That's encapsulation, and he also separates the visuals from the logic. There's a player ship build class that just handles the mesh and the upgrades.
The builder pattern we just talked about.
Right, and a separate player class that handles the input. It's the single responsibility principle in action.
It basically proves that you can apply enterprise level architecture even to a simple arcade shooter.
Okay, so we built the code, but code doesn't exist in a vacuum. It lives in the Unity editor, and this is where the transition happens from coder to developer. The exam isn't just c shark. It is about the tools.
Walker is pretty specific about tools. Yeah, he references Unity twenty seventeen point three, which is I mean ancient history now, but the concepts hold up. One thing he hammers home is folder structure sounds, but it is so vital. He talks about the resources folder. Now, beginners love the resources folder because it's easy, so easy. You put a file in there and you can load it with one line of code resources dot load.
There's a butt, but it's a trap.
Everything in that folder gets built into the game executable startup memory, even if you don't use it. Oh, and managing the memory of those assets is manual. It is so easy to bloat your game and crash a mobile device. He warns you to use it very sparingly.
And then there's the team aspect objective number six working in professional teams.
Right.
This brings us to version control. The book focuses on Unity Collaborate.
Which has since evolved into Unity DevOps, but the logic is the same. It's basically get light. You need to know the difference between publishing, pushing your changes to the cloud and restoring.
Reverting back when you inevitably break something.
When you break something, yes.
The book mentions visual cues specifically for the exam Yes, and you.
Should memorize these. A green circle means you're SYNCD, A blue square means you have local changes. These are the kinds of specific gotcha questions that show up on the test.
He also talks about cloud build a life saver.
Instead of your laptop freezing for twenty minutes while it compiles the Android version, you just send it to the cloud. Can you keep working Unity servers build game, you keep coding. It's all about efficiency.
Let's get into the weeds the pro tips section. There are some specific hands on details Walker includes that I found really interesting. One was about importing three D models.
Ah, the import settings hygiene check.
What's that?
When you drag a dot fbx model into Unity, say your staceship, it brings a lot of baggage with it. Materials you don't need, animation, rigs you aren't using.
I usually just ignore all that stuff.
And that is why your game is five hundred megabytes instead of fifty. Ah, looker says, go into the inspector uncheck import materials, own check import animation. If it's a static rock, set the rig to none. You have to strip that data out.
It's digital decluttering.
It's performance optimization on mobile, every single megabyte counts.
Speaking of mobile performance, there's a weirdly specific trick he mentions. For the player's bullets, he uses a specific shader.
The unlit color shad and he sets.
It to this very specific Cyan.
Color our zero G one ninety B two five and five.
Yeah, why UNLT.
Because lighting is expensive. Real time lighting means the GPU has to calculate shadows, reflections normals for every pixel every frame. A bullet is just a fast moving dot. Does it need a shadow?
Probably not.
By using the unlit shader, you're telling the GPU just paint these pixels cyan. Don't do any math. It's incredibly fast.
And to make it look good, he just adds a little point light component to the prefabs exactly.
The object itself is cheap, but it casts a little glow. It's one of those smoke and mirrors tricks to get high performance without sacrificing the visual pop.
And of course we have to mention prefabs.
The DNA of Unity. If you aren't using prefabs, you aren't really using Unity. Emphasize is turning everything into a prefab the ship, the bullets, the enemies.
Why.
It means if you change the bullets speed in one place, it updates everywhere instantly.
He also mentions custom tags crucial.
For collision detection. Wow, you don't want your code checking if mm no beware enemy ship variant three so brittle. If you rename the ship the code breaks. You want to check if tag equals enemy. It groups all the bad guys into one bucket, so your code works on all of them.
So looking back at all of this patterns, Solid tools optimization, it is a lot of information. But as we wrap up this deep dive, the biggest takeaway for me is that Killer Wave isn't really the point.
No, not at all. The game is just a vehicle. The point is the mindset.
Walker mentions in the intro that you should avoid muscle memory during the exam. What does he mean by that?
That is the golden nugget of the whole book. A lot of us learn by rote, right. We know that to make a thing move we click here, type this, and drag that, but we don't know why.
We're just monkeys pushing buttons.
Exactly true expertise, The kind that gets you certified and gets you hired is understanding the principle behind the button. If you understand SOLID, you can code in Unity today, unreal tomorrow, and go down next week. The syntax changes, but the architecture is universal.
It's the difference between knowing a recipe and knowing how to cook. Perfectly said, so for everyone listening, here's the question we want to leave you with when you sit down to work on your project tonight. Are you designing a system that can grow or are you just typing until the red airlines go away?
That is the question that separates the hobbyist from the pro.
Thanks for joining us on the deep dive. Go build something solid.
Happy coding