Welcome to the deep dive. You've given us the source material, maybe articles, research books, even just your notes, and well, our job is to dive in and pull out the really valuable insights, the key nuggets you need.
Yeah, think of us as guides helping you navigate through all that information. We spot the core concepts, those aha moments, and you know, the practical takeaways that actually matter.
It's about getting the understanding without wading through absolutely everything yourself exactly. And for this deep dive, we've got some really interesting stuff excerpts from a book called Unity Game Development Blueprints.
That's right, So our mission today is basically to explore the essential scripting blueprints. This book lays out. These are like the foundational patterns for building core game features in Unity.
We're looking for the how to and maybe the why behind things like controls, uy inventory.
AI, scoring, saving games, audio settings, menus, all that core stuff.
It really is like getting a look at the uh, the engineering dives for how these games are put together and the source itself.
It comes from place of experience. The author, Kyle Dowst, his background is in serious games, right.
So that's creating games for things like training or.
Education, exactly, which as a kind of fascinating layer, doesn't it applying game mechanics to well real world learning.
It does, and the book's reviewers they seem to highlight the mix of skills needed to you see game DEEV professor sure, but also web developers, artists.
Miscomposers, aven sell actors and answers mentioned. It just underscores how game creation is this melting pot of different.
Disciplines, which makes understanding these technical blueprints even more valuable because while they're the foundation everyone builds on. Okay, let's dive in, starting with the absolute fundamentals.
Yeah, and you can't get much more fundamental than how the player actually interacts with the game.
Interactive input Chapter one controls. Why is getting controls right just so so critical?
Well, it's the player's main connection, isn't it. If the controls feel I don't know, clunky or unresponsive or.
Just confusing, it breaks the whole experience instantly.
So the book's blueprint starts by saying, okay, decide your target input device first. Are you aiming for keyboard and mouse, an Xbox controller, something else? That decision frames.
Everything right, figure out the device, then map the actions onto it. The blueprint mentions checking Unity's input manager.
Yeah, that's kind of step one. But what's really insightful here, I think is the focus on customization right from the start, baking it in.
Ah. So it's not just setting controls, it's building a system.
For setting control exactly. That's the key aha here. Instead of hard coding, say WES to move, the blueprint is designed for flexibility. Talks about letting players swap between schemes like.
Their example scheme A and scheme B, maybe WES versus numpet.
Or swapping left and right mouse buttons for attack and aim, that kind of thing. The point is allowing the player to choose or change.
Okay, so how does the script blueprint actually handle that flexibility.
Well, the core idea is a dedicated control script, and inside that script you have variables little containers basically to hold a specific key or button signment for each.
Action, tailored for different devices.
Right, so you might have a very real PC move holding WASD and another one like Xbox Move holding left thumbstick. The script that needs to figure out which device is actually.
Active, and then to make this usable for the player, you need to show them the current setup and let them change it, which brings us back to the UI again exactly.
The blueprint uses unities on UI function for.
This on Uiokay, remind us what's that specifically for some listeners might not be deep into Unity specifics.
Good point. On UI is a special function Unity calls for drawing what's called immediate mode UI think buttons, labels, textboxes drawn directly using script commands rather than building a UI visually in the editor.
So it's code driven UI drawing called every frame just for that purpose pretty much.
Yeah, So you use on UI in this blueprint to display the current control assignments, maybe in an options menu.
Got it, and the script would have functions like the book mentions, switch profile or switch control scheme.
That you trigger with a button clicking that GUI. Clicking the button calls the function. The function changes those variables holding the key assignments, and maybe opens a little pop up to let the player pick a new key.
It's a neat little system blueprint detect the input, map it flexibly in variables, display it using on GUI, and give the player UI buttons to change it.
Precisely a complete loop which.
Leads us perfectly into the next piece. GUI time Chapter two, moving from player input to the game showing information back to the player right.
And the book makes a useful distinction here between traditional two DUI and three dui.
Two d UI being the stuff we usually see flat on the screen right, health bars, menus, score counters, yep.
The blueprint shows setting up scenes and creating those elements buttons, health bars, maybe level or XP counters, and again on GUI is the main function used for actually drawing these in this particular blueprint.
So for say a health bar.
You'd use something like GUI dot box, which literally just draws a box, and then you calculate it's within the script based on like current health divided by maxelf.
So the UI isn't just static art, it's a dynamic It reflects the game state exactly.
The script does the math, the y does the drawing. But then there's three d UI, which is UI that exists inside the three D game world itself.
Like that health bar floating over an enemy's head you sometimes see.
Perfect example, and the blueprint for that includes a really neat trick making the UI element constantly look at the main cameras.
Transform look, so it just turns to face the camera.
Yeah, look, at camera dot Maine dot transform. It tells that UI element script always rotate yourself so you're facing the player's view m makes it readable from any angle in the three D space.
That's clever, handles the orientation automatically.
It is pretty neat. They also show blueprints for things like three D damage reports you know, the numbers that pop up when something gets hit. Yeah, yeah, and three D name tags over characters. For these kinds of dynamic three D elements, the update function becomes really important.
Okay, and update is different from ANGOI how so yes.
Definitely, Update is a function Unity calls automatically every single frame, like clockwork. It's where you put game logic that needs to happen constantly checking for input, moving things around, or in.
This case, making that three D damage text fade out exactly.
You'd use update to manage a timer and maybe decrease the text self a value its transparency over a second or two, making it fade nicely.
Okay, so we've got input, we've got output display. Now what about the actual things the player interacts with? Items, weapons, potions?
Right? That takes us to expandable item classes. Chapter three and the big idea here is modularity using item blueprints or classes to avoid repeating code.
So instead of writing totally separate code for a health potion and I don't know a magic scroll.
You define generic item types that share common features. The books blueprint breaks them down logically, item self for things that affect the user like potions, okay, Item way for close up interaction like swords or wrenches, and item range for things that shoot projectiles like bows or guns.
That classification makes sense. What kind of information did these item blueprints hold?
Well? They share common variables things like amount, value, weight, name maybe a generic stat variable, but crucially they use enom variables. Enoms remind me an enom or Enumeration is basically just a pre defined list of possible named values. So the blueprint uses enoms for the item's action and its type.
So self action could have values like heel, buff stat change armor exactly, and.
Self type might be potion, scroll food. The enom tells the generic item blueprint what kind of item it is and what it should do when it's used. The script then has the logic for each of those actions.
Okay, and how does an item actually do something like healing the player?
How does it communicate The blueprint often uses a Unity function called send message. It lets one script call a function on another script just by knowing the function's name.
So the potion script could call a function named say apply healing on the.
Playoscript precisely send message apply healing amount to heal. It's a straightforward way for objects to talk to each other in this blueprint.
Send message seems simple. But could that get messy in a really big game tracking all those messages.
That's a fair point. It can. For very large, complex projects, developers often move to more structured systems like interfaces or event systems for clarity and sometimes performance. But for these blueprints, send message is shown as a direct functional way for an item to tell its target, hey, do this.
Got It makes sense for a blueprint approach, and for items interacting with the world, like melee weapons hitting.
Things that usually involves Unity's physics and collider system. The blueprint mentions using trigger colliders and the on trigger interfunction. That function gets called automatically when the items collider marked as a trigger overlaps with another collider.
So the sword trigger hits an enemy collider right.
And for ranged items, you've also got the projectile's movement. The blueprint includes a movement type enom for that may be basic for a straight line, or drop to simulate gravity with a parabolic arc.
And the item's type enom might affect other things too, like a potion type usually gets destroyed after one use.
Exactly the blueprint for a potion would likely include a call to destroy game object after its effect is applied. The real aha here is defining these reusable blueprints that you can then configure with different variables in enom settings to create tons of unique items without starting from scratch every time.
Okay, so we have blueprints for individual items, but how does the game keep track of all the items the player picks up?
Ah? Now we're moving into core game systems like the inventory chapter four super common, super important in many games.
Yeah, RPGs, survival games, they almost all have one, and the blueprint seems to cover the essential size limits accessing it, organizing items, stacking, bartering, dropping using.
This pretty comprehensive system. They outline the implementation blueprint uses a mix of arrays like in items and lists like items in item count.
Why both arrays and lists? Oh, what's the thinking there?
Good question? Well, lists are dynamic, right, they can grow and shrink easily. Arrays have a fixed size once you create them. Using both might offer some flexibility. Maybe the array represents the fixed slots visually, while the list holds the actual items you possess. It depends on the exact implementation detail. The blueprint also mentions using a placeholder like an empty object for slots that don't have an item yet, and a key technique is using key value pair.
Key value pair sounds like storing two related pieces of info together exactly that.
Think of it as pairing the item data itself, like health potion with its count like five. So your list of items actually holds these pairs.
Ah. That makes managing stacks of items like having five health potions much cleaner.
Definitely, and the core functions in the blueprint reflect this. There's initialized inventory to set the size, fill slots with those placeholders, and set counts to zero.
Then adding items add.
To inventory is smart. It first checks do you already have this item? If yes, just increase the count in its key value pair. If no, find the first empty slot placeholder and put the new item pair there, and removing removed from inventory decreases the count. If the count hits zero or less. It replaces that slot with the placeholder again, effectively removing the item handles the stacking logic neatly.
And how does the player actually see and interact with this inventory? Probably guy again?
Absolutely The blueprint shows integrating this with a guy often toggled by a key like I. It draws the grid, the item icons, the counts all based on the data stored in those arrays and lists. We just talked about the.
Nice self contained system, and it obviously needs to talk to those item class blueprints we discussed earlier. Yeah, okay, let's shift focus from the player and their stuff to well making the world feel less empty, right?
Bringing in other characters with artificial intelligence Enemy and Friendly AIS Chapter.
Five AI can seem like a black box sometimes. What techniques does this book's blueprint explore?
It introduces two really common ones, finite state machines or FSMs and behavior trees. And FSM is like giving the character distinct modes or states.
Like idle, patrolling, fighting, running away exactly.
The AI is always in one state and rules dictate when it transitions to another state, like if players cited switch from patrolling to fighting.
Okay, and behavior trees.
Behavior trees are more like a hierarchy of tasks and decisions. Think of it like a complex flow charty. Try to attack? Can I attack? If yes? Do it? If no? Can I move closer? If yes? Do that? If no? Maybe weight It allows for more complex sequences.
Of actions, and the book's blueprint uses these.
It suggests you can combine them, which is common. Maybe use an FSM for the high level state idle, combat, flee, and then use a behavior tree to define the specific actions the AI takes within that state.
Ah okay, so you define the states or the decision logic. What kind of actual actions are these ais performing? In the blueprint examples.
The book makes a useful distinction between internal actions and external actions. Internal actions are things the AI does based on its own state, like following a patrol path, searching an area if it heard a noise, or decided to flee if.
Its health is low, and external actions affect other.
Things, yes, like attacking the player, maybe healing an ally, or interacting with an object. The specific examples mentioned are patrolling, attacking, fleeing, and searching.
The blueprint also mentions how things happening to the AI, like taking damage, can trigger changes in its behavior.
Yeah, this is crucial for making AI feel reactive. If an AI isn't suspicious, it's suspicious variable as false, but it suddenly takes damage. That event can triggers state change.
So it stops idling and starts guarding searching exactly.
It becomes suspicious behavior blueprint shifts. Maybe it enters a guard state or a start searching or another example, if it's health drops below say twenty five percent, a rule might trigger a transition to the flea state.
Using health or suspicion levels as triggers. Makes a lot of sense. Now, foreign AI to patrol or flea or search, it needs to move around.
Pathfinding essential. Yeah, unless your AI just stands still.
Yeah.
The blueprint discusses a couple of approaches. One is a simple waypoint system, just a list.
Of points the AI walks between.
Basically, yeah, an array of transform objects in unity representing positions in the world. The AI just moves from one way point to the next in sequence or maybe randomly.
Okay, simple. What's the other approach.
Using unities built in navmesh system, which is quite a bit more powerful navmesh.
How does that work?
You essentially bake a navigation mesh onto your level's geometry. Unity analyzes your scene, the floors, the walls, the obstacles, and generates a data structure nab mesh representing all the walkable areas, so.
It figures out where the AI can go precisely.
Then you add a navmesh agent component to your AI character. This component knows how to read the navmesh and find efficient paths from A to B avoiding obstacles automatically.
What does baking involve? Is it complex?
You can figure some settings. First, you tell Unity things about the agent that will use the mesh. It's as radius so it doesn't scrape walls, it's height so it knows if it can fit under low ceilings, the maximum slope it can climb. You can also define off mesh links manually for things like telling the AI it can jump across a specific gap or drop down from a ledge. Then you hit the bake button and Unity calculates it all.
So navmesh handles the complex pathfinding automatically, while waypoints are maybe better for very specific, predetermined routes.
That's a good way to put it, and the blueprint actually suggests you can combine them use navmesh for general get me from here to their movement, but maybe use waypoints for a strict guard patrol route within an ap mesh area.
Best of both worlds, right.
And they also mention integrating character animations, which is vital making the AI visually walk, run, attack, or flee as its behavior state and navmetch movement dictates. It's not just an invisible capsule sliding around.
Yeah, brings the character to life. Okay, AI covered. Let's switch back to the player's side and talk about tracking progress keeping score chapter.
Six right, Stats and Achievements, giving the player feedback on how they're doing and goals to aim for.
The source Blueprint lists a solid set of stats to track kills, deaths, gold, collected gold, spent, level, rounds one, rounds lost, and.
Then it automatically calculates things like kill death ratio KDR, when loss ratio WLR, and total time played. Pretty standard stuff for many games.
How does the Blueprint handle updating these?
It uses functions like a set stat function that gets called whenever something relevant happens, kill an enemy call set stat kills current kills plus one, pick up gold, current gold, current gold.
Plus, and the ratios KDR and WLR.
Those aren't set directly. The blueprint calculates them automatically whenever the underlying stats kills, deaths, rounds, one, rounds, loss change, so the ratios are always up to date, inconsistent.
Smart prevents mistakes, and the achievement system builds on top of these stats.
Yeah, exactly. Achievements are typically tied to reaching certain milestones. For specific stats, get ten kills, collect a thousand total gold, reach level five, play for an hour, that sort of thing.
The blueprint mentions tracking progress towards achievements, right.
It suggests using variables like eight kills to store the player's current count towards the next kill achievement, and it also uses boollion flags true false variables like get kills.
What are the flags for?
They control whether an achievement can still be unlocked or upgraded. Maybe there are bronze, silver, and gold levels for kills. Once you want gold, you set get kills to falls, so the game stops checking for that achievement.
Ah, okay, So you track progress and have flags for completion state and displaying this GUI again.
You guessed it. The blueprint involves on GUI or similar UI functions stat's gui ash gui are mentioned to draw labels showing the current stat values and maybe icons or progress bars for the achievements. Using those tracking variables in flags to decide what to display.
Gives the player that nice visual feedback and sense of accomplishment. Okay, foundations core systems, but what about making sure none of this progress vanishes when you quit the game?
Persistence? Creating save and load systems chapter seven absolutely vital for well most games that aren't just short arcade sessions. You need to save inventory, stabs, maede, the enemy, positions, quest progress.
We heard about player prefs earlier for settings, but that's usually for small bits of data, isn't it. This chapter seems to go deeper.
It's exactly. Player prefs is great for simple settings, maybe a high score, but it's not really suited for saving complex game states. Chapter seven sploes blueprints using two main methods, flat files and XML.
Files files just simple text files pretty much.
The blueprint shows saving data line by line. You take your game data, player position coordinates, x, y Z, maybe their health there ammo count, convert each piece to a string using toastring, and write each string on a new line in a text file. Using something called a.
Stream writer simple readable and loading.
Just the reverse. Use a stream reader to read the file line by line. Then you have to convert each line, which is text, back into the correct data type integer, float, whatever, using functions like convert dot two a thirty two or convert duct single.
And the blueprint mentions deleting the old file first.
Yeah, common practice to ensure you're writing a completely new save, not appending to or messing up an old one.
What are the downsides of this flat file approach.
Well, it's simple, which is good, but because you're just reading line by line, you have to know the exact order that data was saved in. If you add a new stat later, it can break loading old saves, and it gets pretty clumsy for really complex nested data like saving the SATA fifty different enemies.
Which is probably where XML files.
Come in handy exactly. XML provides structure. It uses tags like HTML to create a hierarchy. The blueprint uses unities, XML document and XML node classes to build this structure programmatically.
So instead of just lines of values, you have named tags.
Right, you might have a main player data tag and inside that position X ten y five, Z twenty health value eighty five, inventory, dot, inventory, and so on. For enemies, you could have an enemy's tag containing multiple enemy tags, each with its own position, health, AI, state, etc.
How do you get the data back out when loading?
You navigate the XML structure using the node names. You find the health node and read its value attribute, or find the position node and read its xyz attributes, or you find an enemy node and read its innertext. If the value is stored directly inside the tag, it's much more robust for organizing complex data.
A bit more work to set up than flat files maybe, but more flexible and less prone to breaking if you change the data structure slightly.
Generally yes. When loading enemies, for example, you loop through all the enemy nos you find, read the data from each one, convert it, and apply it to the corresponding enemy object in your game scene.
And how does the player actually trigger the save or load? Is it automatic? Manual?
The blueprint can support either. You could tie the save function to checkpoints the player reaches, making it automatic, or you could link the save and load functions to keypresses like F one to save and F two to load, letting the player do it manually whenever they want. The functions themselves, just handle the flat file or XML.
Writing reading gives players options for managing their progress. Okay, we've saved the game state, let's add some life beyond just visuals and numbers.
Sound oral integration Chapter eight. Yeah, audio is absolutely critical for immersion and feedback.
What kind of audio blueprints does the book cover?
Well? Adding background music is a big one, and the blueprint goes beyond just playing one track on loop. It shows how to set up systems for random music selection or playlist style systems.
How does that manage?
Usually with a dedicated script, maybe called BEG Music Manager. It uses Unity's audio source component. That's the thing that actually plays sounds and holds a list of audio clips, which are your actual music files. The script then decides which clip to play.
Next, and you can control things like volume volume definitely.
The blueprint also mentions pitch using a change speed function. Adjusting the pitch of an audio source often changes the playback speed too, so you.
Can make the music faster, slower, maybe more tense by tweaking the pitch exactly.
Then, beyond music, there are atmospheric sounds when rain, bird, song, city, hum, whatever fits your environment.
How's that handled similar manager script.
Yeah, often an ATM manager script, again using an audio source. The key distinction the blueprint makes here is between sounds that should loop continuously like steady rain. It mentions a play repeat function for that, and sounds that should just play once when triggered, like distant thunderclap, using a play function.
That makes sense for ambient background noise.
And then the third category is event driven sound effects or SFX. These are the sounds tied directly to specific actions or events, like the sound.
Of a sword swing, spell casting, picking up an item, clicking.
A button precisely. These are often triggered by the script performing the action itself, or sometimes by another dedicated SFX manager.
What if lots of sounds happen at once, like multiple footsteps or gunshots, the.
Blueprint would likely use a function called play one shot on an audio source. The cool thing about play one shot is that it can play multiple clips overlapping on the same audio source without cutting each other off, so those multiple gunshots can all ring out together naturally.
Ah okay, So you've got music for mood, atmosphere for the environment, and SFX for direct feedback, all managed via scripts talking to Unity's audio components.
Tying it all together and for that final layer of professional polish.
Game settings Chapter nine. Letting players tailor the experience to their liking and their.
Hardware absolutely vital, especially for PC games, but increasingly expected everywhere. Letting players optimize performance and configure things. The blueprint focus is mainly on video and audio settings.
Okay, video settings, what kind of options does the blueprint cover?
Things like setting the screen resolution using screen dot resolution, toggling shadows on or off for performance, adjusting the field of view or FOV, toggling anti aliasing for smoother edges, setting the sync to match the game's framwrate to the monitor's refresh rate, and changing overall graphical quality presets like low, medium, high.
Standard graphics options. And audio setting.
Primarily volume controls master volume, but also separate sliders for the categories we just discussed background music volume, SFX volume, atmospheric sound volume, and maybe speaker mode configuration.
And crucially, how are these settings saved so the player doesn't have to redo them every time they launch the game?
Ah, this is where player presss comes back in perfectly. It's designed exactly for this purpose, saving small bits of user preference data persistently.
So the blueprint uses player preps set and player preffs set float, player prefs set string to store the chosen resolution, volume levels, togble states, et cetera.
Exactly, you save the settings using player prefs when the player applies changes in the options menu, and you load them using player prefs, get it, get float, et cetera, when the game first starts up or when the options menu is opened.
Okay, so that clarifies the distinction player prefs for small simple settings data the chapter seven methods flat files or XML for saving the large complex game state itself.
Precisely that different tools for different jobs, and of course, to let players actually change these settings, the blueprint includes building an options menu GUI, probably.
Managed by its own scripts like configure.
Right using standard UI elements. Buttons, sliders for volume toggles, or checkboxes for on off settings all link to the functions that change the settings and save them using player prefs.
It's that options menu were all familiar with, but now we've kind of peaked behind the curtain at the scripting blueprints that make it work.
Yeah, we've looked at all these different blueprints. In relative isolation controls UI items, inventory, AI, scoring, saving, audio settings. They're presented as module.
Pieces, and Chapter ten, the last part is about putting it all together. How do these modules actually interact in a real game.
Well, the key takeaway from that chapter blueprint is showing that these systems don't live in isolation. A functional game level isn't just a pretty scene. It's where these systems collide and interact.
So designing a main menu scene would integrate the UI blueprint, the audio blueprint for menu music sounds, and the configuration blueprint for the option screen exactly, and.
A playable level uses the AI blueprints for enemies, the stats and scoring blueprints for tracking progress, the item and inventory blueprints for pickups, and the saveload blueprint for persistence.
Player actions become the glue. Right, Like shooting an enemy isn't just a visual.
Effect, right, the blue blue print shows how that single action shooting might trigger SFX using the audio blueprint, possibly alert nearby enemies, or change the target's AI state using the AI blueprint, and maybe increment the player's kill stat using the scoring.
Blueprint and pausing the game might bring up the settings guy config blueprint. Picking up a health kit uses the item class blueprint and tells the inventory system blueprint to update.
It's all about these systems sending messages or calling functions on each other, updating shared variables, and reacting to events triggered by the player or the game world itself.
So the process of building the game involves adding the sound managers, implementing the GUI for stats and options, adding the saveload scripts, basically wiring these blueprints together yes.
And linking game logic like win conditions. The blueprint mentions checking if enemies equals zero, That condition links back to the AI and STAT systems. Killing an enemy AI interaction updates the player's kill stat and decreases the enemy count that the wind condition is monitoring.
It really emphasizes that these are well blueprints building blocks. You learn how to make a working inventory, a working AI, a working save system, and then you combine them, customize them, expand on them to build something bigger.
It's about understanding the components so you can assemble and adapt them creatively.
So wrapping up this deep dive into the Unity game development blueprints source material, we've really taken a shortcut through a whole range of corese scripting concepts from the absolute fundamentals like controls and UI.
Through managing items in inventory, bringing the world alive with AI, tracking player progress with stats and achievements, making sure that progress sticks with saving and loading.
And adding that essential polish with audio integration and configurable game settings.
Understanding these modular blueprints, even just conceptually, gives you a really powerful starting point, a clear path for building functional features quickly and ultimately putting together entire game experiences.
And for you, the listener, as you think about these different blueprints may be consider this every single technical piece we talked about, that variable holding a key assignment, the line of code that counts a kill, the function that saves data, the setting for shadow quality. It isn't just technical minutia.
Yeah, the specific way these systems are designed and implemented, the choices made in the blueprint, they directly shape how the player actually feels playing the game. Does it feel responsive? Is it fair? Is it engaging?
That technical implementation directly translates into the player's moment to moment experience, their interaction, even the kind of emotional connection they might form with the world you've built using these blueprints.
The code isn't just instructions for the computer, it's fundamentally shaping the human experience on the other side of.
The screen, A fascinating connection to keep in mind. Thanks for joining us for this deep dive.
Until next time.