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