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