WEBVTT 1 00:00:00.120 --> 00:00:03.759 Welcome to the deep dive. You've given us the source material, 2 00:00:03.839 --> 00:00:07.839 maybe articles, research books, even just your notes, and well, 3 00:00:08.439 --> 00:00:10.359 our job is to dive in and pull out the 4 00:00:10.400 --> 00:00:13.560 really valuable insights, the key nuggets you need. 5 00:00:13.800 --> 00:00:16.600 Yeah, think of us as guides helping you navigate through 6 00:00:16.640 --> 00:00:21.039 all that information. We spot the core concepts, those aha moments, 7 00:00:21.559 --> 00:00:24.239 and you know, the practical takeaways that actually matter. 8 00:00:24.359 --> 00:00:27.800 It's about getting the understanding without wading through absolutely everything 9 00:00:27.839 --> 00:00:30.199 yourself exactly. And for this deep dive, we've got some 10 00:00:30.239 --> 00:00:33.359 really interesting stuff excerpts from a book called Unity Game 11 00:00:33.399 --> 00:00:34.520 Development Blueprints. 12 00:00:34.600 --> 00:00:38.079 That's right, So our mission today is basically to explore 13 00:00:38.119 --> 00:00:41.679 the essential scripting blueprints. This book lays out. These are 14 00:00:41.719 --> 00:00:45.119 like the foundational patterns for building core game features in Unity. 15 00:00:45.200 --> 00:00:47.679 We're looking for the how to and maybe the why 16 00:00:47.719 --> 00:00:51.560 behind things like controls, uy inventory. 17 00:00:51.039 --> 00:00:56.320 AI, scoring, saving games, audio settings, menus, all that core stuff. 18 00:00:56.439 --> 00:00:58.840 It really is like getting a look at the uh, 19 00:00:58.880 --> 00:01:01.960 the engineering dives for how these games are put together 20 00:01:02.880 --> 00:01:03.840 and the source itself. 21 00:01:03.880 --> 00:01:07.400 It comes from place of experience. The author, Kyle Dowst, 22 00:01:07.719 --> 00:01:10.599 his background is in serious games, right. 23 00:01:10.480 --> 00:01:13.719 So that's creating games for things like training or. 24 00:01:13.799 --> 00:01:17.239 Education, exactly, which as a kind of fascinating layer, doesn't 25 00:01:17.239 --> 00:01:21.400 it applying game mechanics to well real world learning. 26 00:01:21.560 --> 00:01:24.719 It does, and the book's reviewers they seem to highlight 27 00:01:24.719 --> 00:01:27.560 the mix of skills needed to you see game DEEV 28 00:01:27.599 --> 00:01:31.319 professor sure, but also web developers, artists. 29 00:01:31.120 --> 00:01:34.680 Miscomposers, aven sell actors and answers mentioned. It just underscores 30 00:01:34.719 --> 00:01:38.680 how game creation is this melting pot of different. 31 00:01:38.359 --> 00:01:42.359 Disciplines, which makes understanding these technical blueprints even more valuable 32 00:01:42.560 --> 00:01:46.040 because while they're the foundation everyone builds on. Okay, let's 33 00:01:46.120 --> 00:01:48.640 dive in, starting with the absolute fundamentals. 34 00:01:48.719 --> 00:01:50.879 Yeah, and you can't get much more fundamental than how 35 00:01:50.879 --> 00:01:52.719 the player actually interacts with the game. 36 00:01:52.959 --> 00:01:57.599 Interactive input Chapter one controls. Why is getting controls right 37 00:01:57.920 --> 00:01:59.959 just so so critical? 38 00:02:00.000 --> 00:02:02.200 Well, it's the player's main connection, isn't it. If the 39 00:02:02.239 --> 00:02:05.879 controls feel I don't know, clunky or unresponsive or. 40 00:02:06.239 --> 00:02:09.159 Just confusing, it breaks the whole experience instantly. 41 00:02:09.319 --> 00:02:12.159 So the book's blueprint starts by saying, okay, decide your 42 00:02:12.199 --> 00:02:16.000 target input device first. Are you aiming for keyboard and mouse, 43 00:02:16.560 --> 00:02:20.840 an Xbox controller, something else? That decision frames. 44 00:02:20.439 --> 00:02:23.400 Everything right, figure out the device, then map the actions 45 00:02:23.400 --> 00:02:26.919 onto it. The blueprint mentions checking Unity's input manager. 46 00:02:27.199 --> 00:02:30.159 Yeah, that's kind of step one. But what's really insightful here, 47 00:02:30.199 --> 00:02:33.719 I think is the focus on customization right from the start, 48 00:02:33.800 --> 00:02:34.479 baking it in. 49 00:02:34.719 --> 00:02:38.080 Ah. So it's not just setting controls, it's building a system. 50 00:02:37.759 --> 00:02:42.039 For setting control exactly. That's the key aha here. Instead 51 00:02:42.039 --> 00:02:45.520 of hard coding, say WES to move, the blueprint is 52 00:02:45.560 --> 00:02:49.639 designed for flexibility. Talks about letting players swap between schemes like. 53 00:02:49.599 --> 00:02:53.439 Their example scheme A and scheme B, maybe WES versus numpet. 54 00:02:53.479 --> 00:02:56.159 Or swapping left and right mouse buttons for attack and aim, 55 00:02:56.199 --> 00:02:58.080 that kind of thing. The point is allowing the player 56 00:02:58.120 --> 00:02:59.199 to choose or change. 57 00:02:59.280 --> 00:03:04.120 Okay, so how does the script blueprint actually handle that flexibility. 58 00:03:04.400 --> 00:03:07.240 Well, the core idea is a dedicated control script, and 59 00:03:07.319 --> 00:03:10.919 inside that script you have variables little containers basically to 60 00:03:10.960 --> 00:03:13.560 hold a specific key or button signment for each. 61 00:03:13.400 --> 00:03:15.240 Action, tailored for different devices. 62 00:03:15.319 --> 00:03:17.360 Right, so you might have a very real PC move 63 00:03:17.719 --> 00:03:21.240 holding WASD and another one like Xbox Move holding left thumbstick. 64 00:03:22.680 --> 00:03:25.759 The script that needs to figure out which device is actually. 65 00:03:25.400 --> 00:03:28.199 Active, and then to make this usable for the player, 66 00:03:28.199 --> 00:03:30.000 you need to show them the current setup and let 67 00:03:30.039 --> 00:03:33.840 them change it, which brings us back to the UI 68 00:03:33.879 --> 00:03:34.840 again exactly. 69 00:03:34.919 --> 00:03:38.120 The blueprint uses unities on UI function for. 70 00:03:38.080 --> 00:03:41.960 This on Uiokay, remind us what's that specifically for some 71 00:03:42.120 --> 00:03:44.599 listeners might not be deep into Unity specifics. 72 00:03:44.639 --> 00:03:48.159 Good point. On UI is a special function Unity calls 73 00:03:48.159 --> 00:03:52.520 for drawing what's called immediate mode UI think buttons, labels, 74 00:03:52.560 --> 00:03:56.759 textboxes drawn directly using script commands rather than building a 75 00:03:56.879 --> 00:03:58.319 UI visually in the editor. 76 00:03:58.400 --> 00:04:01.599 So it's code driven UI drawing called every frame just 77 00:04:01.599 --> 00:04:02.719 for that purpose pretty much. 78 00:04:02.800 --> 00:04:05.319 Yeah, So you use on UI in this blueprint to 79 00:04:05.319 --> 00:04:08.759 display the current control assignments, maybe in an options menu. 80 00:04:08.879 --> 00:04:11.560 Got it, and the script would have functions like the 81 00:04:11.599 --> 00:04:14.400 book mentions, switch profile or switch control scheme. 82 00:04:14.240 --> 00:04:17.160 That you trigger with a button clicking that GUI. Clicking 83 00:04:17.199 --> 00:04:20.759 the button calls the function. The function changes those variables 84 00:04:20.800 --> 00:04:23.319 holding the key assignments, and maybe opens a little pop 85 00:04:23.399 --> 00:04:24.839 up to let the player pick a new key. 86 00:04:25.120 --> 00:04:28.839 It's a neat little system blueprint detect the input, map 87 00:04:28.920 --> 00:04:32.480 it flexibly in variables, display it using on GUI, and 88 00:04:32.560 --> 00:04:34.720 give the player UI buttons to change it. 89 00:04:34.759 --> 00:04:37.240 Precisely a complete loop which. 90 00:04:37.199 --> 00:04:41.079 Leads us perfectly into the next piece. GUI time Chapter two, 91 00:04:41.639 --> 00:04:45.040 moving from player input to the game showing information back 92 00:04:45.079 --> 00:04:46.000 to the player right. 93 00:04:46.040 --> 00:04:49.680 And the book makes a useful distinction here between traditional 94 00:04:49.759 --> 00:04:51.319 two DUI and three dui. 95 00:04:51.120 --> 00:04:53.240 Two d UI being the stuff we usually see flat 96 00:04:53.240 --> 00:04:57.040 on the screen right, health bars, menus, score counters, yep. 97 00:04:57.240 --> 00:05:00.319 The blueprint shows setting up scenes and creating those elements buttons, 98 00:05:00.360 --> 00:05:03.480 health bars, maybe level or XP counters, and again on 99 00:05:03.639 --> 00:05:06.120 GUI is the main function used for actually drawing these 100 00:05:06.160 --> 00:05:07.399 in this particular blueprint. 101 00:05:07.519 --> 00:05:09.360 So for say a health bar. 102 00:05:09.279 --> 00:05:11.920 You'd use something like GUI dot box, which literally just 103 00:05:12.000 --> 00:05:14.120 draws a box, and then you calculate it's within the 104 00:05:14.160 --> 00:05:17.079 script based on like current health divided by maxelf. 105 00:05:17.279 --> 00:05:19.720 So the UI isn't just static art, it's a dynamic 106 00:05:19.800 --> 00:05:21.680 It reflects the game state exactly. 107 00:05:21.759 --> 00:05:24.120 The script does the math, the y does the drawing. 108 00:05:24.480 --> 00:05:27.079 But then there's three d UI, which is UI that 109 00:05:27.199 --> 00:05:30.079 exists inside the three D game world itself. 110 00:05:29.800 --> 00:05:31.879 Like that health bar floating over an enemy's head you 111 00:05:31.920 --> 00:05:32.480 sometimes see. 112 00:05:32.680 --> 00:05:35.959 Perfect example, and the blueprint for that includes a really 113 00:05:36.000 --> 00:05:40.439 neat trick making the UI element constantly look at the 114 00:05:40.480 --> 00:05:41.399 main cameras. 115 00:05:41.040 --> 00:05:43.959 Transform look, so it just turns to face the camera. 116 00:05:44.120 --> 00:05:46.439 Yeah, look, at camera dot Maine dot transform. It tells 117 00:05:46.480 --> 00:05:49.600 that UI element script always rotate yourself so you're facing 118 00:05:49.600 --> 00:05:52.319 the player's view m makes it readable from any angle 119 00:05:52.319 --> 00:05:53.199 in the three D space. 120 00:05:53.319 --> 00:05:55.879 That's clever, handles the orientation automatically. 121 00:05:55.959 --> 00:05:58.000 It is pretty neat. They also show blueprints for things 122 00:05:58.079 --> 00:06:00.800 like three D damage reports you know, the numbers that 123 00:06:00.839 --> 00:06:02.879 pop up when something gets hit. Yeah, yeah, and three 124 00:06:02.920 --> 00:06:06.319 D name tags over characters. For these kinds of dynamic 125 00:06:06.360 --> 00:06:09.680 three D elements, the update function becomes really important. 126 00:06:09.720 --> 00:06:13.879 Okay, and update is different from ANGOI how so yes. 127 00:06:13.800 --> 00:06:18.279 Definitely, Update is a function Unity calls automatically every single frame, 128 00:06:18.399 --> 00:06:21.079 like clockwork. It's where you put game logic that needs 129 00:06:21.120 --> 00:06:25.560 to happen constantly checking for input, moving things around, or in. 130 00:06:25.480 --> 00:06:29.279 This case, making that three D damage text fade out exactly. 131 00:06:29.319 --> 00:06:31.879 You'd use update to manage a timer and maybe decrease 132 00:06:31.879 --> 00:06:34.600 the text self a value its transparency over a second 133 00:06:34.680 --> 00:06:36.480 or two, making it fade nicely. 134 00:06:36.720 --> 00:06:39.480 Okay, so we've got input, we've got output display. Now 135 00:06:39.480 --> 00:06:43.759 what about the actual things the player interacts with? Items, weapons, potions? 136 00:06:43.920 --> 00:06:46.560 Right? That takes us to expandable item classes. Chapter three 137 00:06:47.120 --> 00:06:50.399 and the big idea here is modularity using item blueprints 138 00:06:50.439 --> 00:06:52.680 or classes to avoid repeating code. 139 00:06:52.879 --> 00:06:55.519 So instead of writing totally separate code for a health 140 00:06:55.600 --> 00:06:58.839 potion and I don't know a magic scroll. 141 00:06:58.240 --> 00:07:01.399 You define generic item types that share common features. The 142 00:07:01.439 --> 00:07:05.240 books blueprint breaks them down logically, item self for things 143 00:07:05.279 --> 00:07:08.079 that affect the user like potions, okay, Item way for 144 00:07:08.160 --> 00:07:11.720 close up interaction like swords or wrenches, and item range 145 00:07:11.720 --> 00:07:14.600 for things that shoot projectiles like bows or guns. 146 00:07:14.759 --> 00:07:17.639 That classification makes sense. What kind of information did these 147 00:07:17.639 --> 00:07:18.720 item blueprints hold? 148 00:07:18.920 --> 00:07:22.680 Well? They share common variables things like amount, value, weight, 149 00:07:23.040 --> 00:07:27.279 name maybe a generic stat variable, but crucially they use 150 00:07:27.560 --> 00:07:31.759 enom variables. Enoms remind me an enom or Enumeration is 151 00:07:31.800 --> 00:07:35.040 basically just a pre defined list of possible named values. 152 00:07:35.279 --> 00:07:38.040 So the blueprint uses enoms for the item's action and 153 00:07:38.079 --> 00:07:38.639 its type. 154 00:07:38.720 --> 00:07:41.759 So self action could have values like heel, buff stat 155 00:07:41.879 --> 00:07:43.720 change armor exactly, and. 156 00:07:43.800 --> 00:07:48.160 Self type might be potion, scroll food. The enom tells 157 00:07:48.199 --> 00:07:51.000 the generic item blueprint what kind of item it is 158 00:07:51.360 --> 00:07:53.680 and what it should do when it's used. The script 159 00:07:53.680 --> 00:07:55.600 then has the logic for each of those actions. 160 00:07:55.680 --> 00:07:57.839 Okay, and how does an item actually do something like 161 00:07:57.920 --> 00:07:58.759 healing the player? 162 00:07:58.800 --> 00:08:02.040 How does it communicate The blueprint often uses a Unity 163 00:08:02.040 --> 00:08:04.920 function called send message. It lets one script call a 164 00:08:04.959 --> 00:08:07.920 function on another script just by knowing the function's name. 165 00:08:08.120 --> 00:08:10.439 So the potion script could call a function named say 166 00:08:10.480 --> 00:08:11.600 apply healing on the. 167 00:08:11.519 --> 00:08:16.360 Playoscript precisely send message apply healing amount to heal. It's 168 00:08:16.360 --> 00:08:18.439 a straightforward way for objects to talk to each other 169 00:08:18.439 --> 00:08:19.160 in this blueprint. 170 00:08:19.240 --> 00:08:22.000 Send message seems simple. But could that get messy in 171 00:08:22.040 --> 00:08:24.639 a really big game tracking all those messages. 172 00:08:24.920 --> 00:08:29.160 That's a fair point. It can. For very large, complex projects, 173 00:08:29.480 --> 00:08:33.240 developers often move to more structured systems like interfaces or 174 00:08:33.279 --> 00:08:38.039 event systems for clarity and sometimes performance. But for these blueprints, 175 00:08:38.159 --> 00:08:41.320 send message is shown as a direct functional way for 176 00:08:41.360 --> 00:08:43.639 an item to tell its target, hey, do this. 177 00:08:43.799 --> 00:08:46.879 Got It makes sense for a blueprint approach, and for 178 00:08:47.320 --> 00:08:50.440 items interacting with the world, like melee weapons hitting. 179 00:08:50.159 --> 00:08:53.519 Things that usually involves Unity's physics and collider system. The 180 00:08:53.519 --> 00:08:56.960 blueprint mentions using trigger colliders and the on trigger interfunction. 181 00:08:57.399 --> 00:09:00.480 That function gets called automatically when the items collider marked 182 00:09:00.480 --> 00:09:03.039 as a trigger overlaps with another collider. 183 00:09:02.759 --> 00:09:05.440 So the sword trigger hits an enemy collider right. 184 00:09:05.919 --> 00:09:08.720 And for ranged items, you've also got the projectile's movement. 185 00:09:09.200 --> 00:09:13.039 The blueprint includes a movement type enom for that may 186 00:09:13.039 --> 00:09:16.039 be basic for a straight line, or drop to simulate 187 00:09:16.080 --> 00:09:17.600 gravity with a parabolic arc. 188 00:09:17.639 --> 00:09:19.840 And the item's type enom might affect other things too, 189 00:09:20.000 --> 00:09:22.559 like a potion type usually gets destroyed after one use. 190 00:09:22.919 --> 00:09:25.919 Exactly the blueprint for a potion would likely include a 191 00:09:25.919 --> 00:09:29.399 call to destroy game object after its effect is applied. 192 00:09:30.000 --> 00:09:35.159 The real aha here is defining these reusable blueprints that 193 00:09:35.200 --> 00:09:38.000 you can then configure with different variables in enom settings 194 00:09:38.120 --> 00:09:41.320 to create tons of unique items without starting from scratch 195 00:09:41.360 --> 00:09:41.759 every time. 196 00:09:41.840 --> 00:09:44.879 Okay, so we have blueprints for individual items, but how 197 00:09:44.879 --> 00:09:47.039 does the game keep track of all the items the 198 00:09:47.039 --> 00:09:47.799 player picks up? 199 00:09:47.879 --> 00:09:51.039 Ah? Now we're moving into core game systems like the 200 00:09:51.039 --> 00:09:55.240 inventory chapter four super common, super important in many games. 201 00:09:55.320 --> 00:09:58.320 Yeah, RPGs, survival games, they almost all have one, and 202 00:09:58.360 --> 00:10:01.799 the blueprint seems to cover the essential size limits accessing it, 203 00:10:01.919 --> 00:10:05.120 organizing items, stacking, bartering, dropping using. 204 00:10:04.879 --> 00:10:08.720 This pretty comprehensive system. They outline the implementation blueprint uses 205 00:10:08.759 --> 00:10:11.440 a mix of arrays like in items and lists like 206 00:10:11.519 --> 00:10:12.519 items in item count. 207 00:10:13.080 --> 00:10:16.279 Why both arrays and lists? Oh, what's the thinking there? 208 00:10:16.440 --> 00:10:21.240 Good question? Well, lists are dynamic, right, they can grow 209 00:10:21.320 --> 00:10:24.480 and shrink easily. Arrays have a fixed size once you 210 00:10:24.559 --> 00:10:28.720 create them. Using both might offer some flexibility. Maybe the 211 00:10:28.799 --> 00:10:32.279 array represents the fixed slots visually, while the list holds 212 00:10:32.320 --> 00:10:35.919 the actual items you possess. It depends on the exact 213 00:10:35.919 --> 00:10:40.360 implementation detail. The blueprint also mentions using a placeholder like 214 00:10:40.399 --> 00:10:43.200 an empty object for slots that don't have an item yet, 215 00:10:43.639 --> 00:10:46.039 and a key technique is using key value pair. 216 00:10:46.320 --> 00:10:49.799 Key value pair sounds like storing two related pieces of 217 00:10:49.799 --> 00:10:51.279 info together exactly that. 218 00:10:51.720 --> 00:10:54.200 Think of it as pairing the item data itself, like 219 00:10:54.240 --> 00:10:57.759 health potion with its count like five. So your list 220 00:10:57.759 --> 00:10:59.320 of items actually holds these pairs. 221 00:10:59.360 --> 00:11:01.960 Ah. That makes managing stacks of items like having five 222 00:11:02.000 --> 00:11:03.559 health potions much cleaner. 223 00:11:03.279 --> 00:11:06.159 Definitely, and the core functions in the blueprint reflect this. 224 00:11:06.360 --> 00:11:09.600 There's initialized inventory to set the size, fill slots with 225 00:11:09.600 --> 00:11:11.759 those placeholders, and set counts to zero. 226 00:11:11.960 --> 00:11:13.480 Then adding items add. 227 00:11:13.240 --> 00:11:15.759 To inventory is smart. It first checks do you already 228 00:11:15.759 --> 00:11:18.080 have this item? If yes, just increase the count in 229 00:11:18.120 --> 00:11:20.639 its key value pair. If no, find the first empty 230 00:11:20.639 --> 00:11:22.679 slot placeholder and put the new item pair there, and 231 00:11:22.799 --> 00:11:26.159 removing removed from inventory decreases the count. If the count 232 00:11:26.200 --> 00:11:29.480 hits zero or less. It replaces that slot with the 233 00:11:29.480 --> 00:11:34.159 placeholder again, effectively removing the item handles the stacking logic neatly. 234 00:11:34.639 --> 00:11:37.600 And how does the player actually see and interact with 235 00:11:37.639 --> 00:11:40.240 this inventory? Probably guy again? 236 00:11:40.480 --> 00:11:44.960 Absolutely The blueprint shows integrating this with a guy often 237 00:11:45.000 --> 00:11:48.159 toggled by a key like I. It draws the grid, 238 00:11:48.320 --> 00:11:51.200 the item icons, the counts all based on the data 239 00:11:51.240 --> 00:11:53.720 stored in those arrays and lists. We just talked about the. 240 00:11:53.759 --> 00:11:56.240 Nice self contained system, and it obviously needs to talk 241 00:11:56.279 --> 00:11:59.159 to those item class blueprints we discussed earlier. Yeah, okay, 242 00:11:59.240 --> 00:12:01.480 let's shift focus from the player and their stuff to 243 00:12:02.279 --> 00:12:04.279 well making the world feel less empty, right? 244 00:12:04.360 --> 00:12:07.720 Bringing in other characters with artificial intelligence Enemy and Friendly 245 00:12:07.759 --> 00:12:09.080 AIS Chapter. 246 00:12:08.720 --> 00:12:11.279 Five AI can seem like a black box sometimes. What 247 00:12:11.399 --> 00:12:13.720 techniques does this book's blueprint explore? 248 00:12:13.919 --> 00:12:17.320 It introduces two really common ones, finite state machines or 249 00:12:17.399 --> 00:12:20.559 FSMs and behavior trees. And FSM is like giving the 250 00:12:20.639 --> 00:12:22.799 character distinct modes or states. 251 00:12:22.679 --> 00:12:26.320 Like idle, patrolling, fighting, running away exactly. 252 00:12:26.519 --> 00:12:29.600 The AI is always in one state and rules dictate 253 00:12:29.720 --> 00:12:33.440 when it transitions to another state, like if players cited 254 00:12:33.720 --> 00:12:35.200 switch from patrolling to fighting. 255 00:12:35.799 --> 00:12:38.000 Okay, and behavior trees. 256 00:12:37.960 --> 00:12:41.000 Behavior trees are more like a hierarchy of tasks and decisions. 257 00:12:41.320 --> 00:12:43.840 Think of it like a complex flow charty. Try to attack? 258 00:12:44.000 --> 00:12:46.759 Can I attack? If yes? Do it? If no? Can 259 00:12:46.759 --> 00:12:49.320 I move closer? If yes? Do that? If no? Maybe 260 00:12:49.320 --> 00:12:52.519 weight It allows for more complex sequences. 261 00:12:52.000 --> 00:12:54.240 Of actions, and the book's blueprint uses these. 262 00:12:54.320 --> 00:12:56.960 It suggests you can combine them, which is common. Maybe 263 00:12:57.120 --> 00:13:00.519 use an FSM for the high level state idle, combat, flee, 264 00:13:00.879 --> 00:13:03.279 and then use a behavior tree to define the specific 265 00:13:03.399 --> 00:13:05.360 actions the AI takes within that state. 266 00:13:05.480 --> 00:13:08.679 Ah okay, so you define the states or the decision logic. 267 00:13:09.000 --> 00:13:11.679 What kind of actual actions are these ais performing? In 268 00:13:11.720 --> 00:13:13.360 the blueprint examples. 269 00:13:13.039 --> 00:13:15.639 The book makes a useful distinction between internal actions and 270 00:13:15.679 --> 00:13:19.279 external actions. Internal actions are things the AI does based 271 00:13:19.279 --> 00:13:22.080 on its own state, like following a patrol path, searching 272 00:13:22.159 --> 00:13:24.279 an area if it heard a noise, or decided to 273 00:13:24.279 --> 00:13:24.799 flee if. 274 00:13:24.679 --> 00:13:27.120 Its health is low, and external actions affect other. 275 00:13:27.039 --> 00:13:30.200 Things, yes, like attacking the player, maybe healing an ally, 276 00:13:30.679 --> 00:13:37.039 or interacting with an object. The specific examples mentioned are patrolling, attacking, fleeing, 277 00:13:37.360 --> 00:13:37.919 and searching. 278 00:13:38.039 --> 00:13:40.799 The blueprint also mentions how things happening to the AI, 279 00:13:41.159 --> 00:13:44.120 like taking damage, can trigger changes in its behavior. 280 00:13:44.200 --> 00:13:47.159 Yeah, this is crucial for making AI feel reactive. If 281 00:13:47.200 --> 00:13:51.039 an AI isn't suspicious, it's suspicious variable as false, but 282 00:13:51.080 --> 00:13:55.080 it suddenly takes damage. That event can triggers state change. 283 00:13:54.840 --> 00:13:59.440 So it stops idling and starts guarding searching exactly. 284 00:13:59.159 --> 00:14:02.320 It becomes suspicious behavior blueprint shifts. Maybe it enters a 285 00:14:02.320 --> 00:14:05.240 guard state or a start searching or another example, if 286 00:14:05.240 --> 00:14:08.200 it's health drops below say twenty five percent, a rule 287 00:14:08.279 --> 00:14:10.480 might trigger a transition to the flea state. 288 00:14:10.519 --> 00:14:13.240 Using health or suspicion levels as triggers. Makes a lot 289 00:14:13.279 --> 00:14:16.559 of sense. Now, foreign AI to patrol or flea or search, 290 00:14:16.559 --> 00:14:17.559 it needs to move around. 291 00:14:17.759 --> 00:14:21.039 Pathfinding essential. Yeah, unless your AI just stands still. 292 00:14:21.159 --> 00:14:21.399 Yeah. 293 00:14:21.399 --> 00:14:24.120 The blueprint discusses a couple of approaches. One is a 294 00:14:24.120 --> 00:14:26.120 simple waypoint system, just a list. 295 00:14:25.879 --> 00:14:27.799 Of points the AI walks between. 296 00:14:27.600 --> 00:14:31.919 Basically, yeah, an array of transform objects in unity representing 297 00:14:31.919 --> 00:14:35.399 positions in the world. The AI just moves from one 298 00:14:35.440 --> 00:14:39.279 way point to the next in sequence or maybe randomly. 299 00:14:39.360 --> 00:14:41.480 Okay, simple. What's the other approach. 300 00:14:41.600 --> 00:14:46.240 Using unities built in navmesh system, which is quite a 301 00:14:46.240 --> 00:14:48.240 bit more powerful navmesh. 302 00:14:48.279 --> 00:14:49.159 How does that work? 303 00:14:49.320 --> 00:14:53.440 You essentially bake a navigation mesh onto your level's geometry. 304 00:14:54.240 --> 00:14:58.039 Unity analyzes your scene, the floors, the walls, the obstacles, 305 00:14:58.320 --> 00:15:01.440 and generates a data structure nab mesh representing all the 306 00:15:01.480 --> 00:15:02.519 walkable areas, so. 307 00:15:02.480 --> 00:15:04.799 It figures out where the AI can go precisely. 308 00:15:05.159 --> 00:15:08.960 Then you add a navmesh agent component to your AI character. 309 00:15:09.360 --> 00:15:11.679 This component knows how to read the navmesh and find 310 00:15:11.679 --> 00:15:14.879 efficient paths from A to B avoiding obstacles automatically. 311 00:15:15.000 --> 00:15:17.559 What does baking involve? Is it complex? 312 00:15:18.200 --> 00:15:20.679 You can figure some settings. First, you tell Unity things 313 00:15:20.720 --> 00:15:22.679 about the agent that will use the mesh. It's as 314 00:15:22.759 --> 00:15:25.639 radius so it doesn't scrape walls, it's height so it 315 00:15:25.720 --> 00:15:28.240 knows if it can fit under low ceilings, the maximum 316 00:15:28.240 --> 00:15:30.720 slope it can climb. You can also define off mesh 317 00:15:30.759 --> 00:15:33.399 links manually for things like telling the AI it can 318 00:15:33.480 --> 00:15:36.879 jump across a specific gap or drop down from a ledge. 319 00:15:37.240 --> 00:15:40.399 Then you hit the bake button and Unity calculates it all. 320 00:15:40.720 --> 00:15:45.480 So navmesh handles the complex pathfinding automatically, while waypoints are 321 00:15:45.559 --> 00:15:49.240 maybe better for very specific, predetermined routes. 322 00:15:49.360 --> 00:15:51.080 That's a good way to put it, and the blueprint 323 00:15:51.120 --> 00:15:55.080 actually suggests you can combine them use navmesh for general 324 00:15:55.159 --> 00:15:57.399 get me from here to their movement, but maybe use 325 00:15:57.440 --> 00:15:59.840 waypoints for a strict guard patrol route within an ap 326 00:16:00.120 --> 00:16:00.639 mesh area. 327 00:16:00.759 --> 00:16:02.279 Best of both worlds, right. 328 00:16:02.480 --> 00:16:05.559 And they also mention integrating character animations, which is vital 329 00:16:06.039 --> 00:16:09.879 making the AI visually walk, run, attack, or flee as 330 00:16:09.919 --> 00:16:13.120 its behavior state and navmetch movement dictates. It's not just 331 00:16:13.159 --> 00:16:15.000 an invisible capsule sliding around. 332 00:16:15.039 --> 00:16:18.480 Yeah, brings the character to life. Okay, AI covered. Let's 333 00:16:18.480 --> 00:16:20.519 switch back to the player's side and talk about tracking 334 00:16:20.559 --> 00:16:23.039 progress keeping score chapter. 335 00:16:22.799 --> 00:16:25.919 Six right, Stats and Achievements, giving the player feedback on 336 00:16:25.960 --> 00:16:27.679 how they're doing and goals to aim for. 337 00:16:27.879 --> 00:16:30.360 The source Blueprint lists a solid set of stats to 338 00:16:30.399 --> 00:16:34.799 track kills, deaths, gold, collected gold, spent, level, rounds one, 339 00:16:35.039 --> 00:16:36.279 rounds lost, and. 340 00:16:36.240 --> 00:16:39.279 Then it automatically calculates things like kill death ratio KDR, 341 00:16:39.360 --> 00:16:43.679 when loss ratio WLR, and total time played. Pretty standard 342 00:16:43.679 --> 00:16:44.639 stuff for many games. 343 00:16:44.679 --> 00:16:47.960 How does the Blueprint handle updating these? 344 00:16:48.240 --> 00:16:51.360 It uses functions like a set stat function that gets 345 00:16:51.399 --> 00:16:54.840 called whenever something relevant happens, kill an enemy call set 346 00:16:54.879 --> 00:16:58.960 stat kills current kills plus one, pick up gold, current gold, 347 00:16:59.000 --> 00:16:59.759 current gold. 348 00:16:59.519 --> 00:17:02.440 Plus, and the ratios KDR and WLR. 349 00:17:02.519 --> 00:17:06.480 Those aren't set directly. The blueprint calculates them automatically whenever 350 00:17:06.519 --> 00:17:10.799 the underlying stats kills, deaths, rounds, one, rounds, loss change, 351 00:17:11.119 --> 00:17:14.079 so the ratios are always up to date, inconsistent. 352 00:17:13.720 --> 00:17:17.079 Smart prevents mistakes, and the achievement system builds on top 353 00:17:17.119 --> 00:17:17.759 of these stats. 354 00:17:17.880 --> 00:17:21.680 Yeah, exactly. Achievements are typically tied to reaching certain milestones. 355 00:17:21.720 --> 00:17:25.200 For specific stats, get ten kills, collect a thousand total gold, 356 00:17:25.519 --> 00:17:28.039 reach level five, play for an hour, that sort of thing. 357 00:17:28.160 --> 00:17:31.480 The blueprint mentions tracking progress towards achievements, right. 358 00:17:31.799 --> 00:17:34.839 It suggests using variables like eight kills to store the 359 00:17:34.839 --> 00:17:37.920 player's current count towards the next kill achievement, and it 360 00:17:37.960 --> 00:17:41.759 also uses boollion flags true false variables like get kills. 361 00:17:42.039 --> 00:17:42.960 What are the flags for? 362 00:17:43.319 --> 00:17:46.279 They control whether an achievement can still be unlocked or upgraded. 363 00:17:46.599 --> 00:17:49.519 Maybe there are bronze, silver, and gold levels for kills. 364 00:17:50.119 --> 00:17:52.599 Once you want gold, you set get kills to falls, 365 00:17:52.920 --> 00:17:54.920 so the game stops checking for that achievement. 366 00:17:55.119 --> 00:17:57.880 Ah, okay, So you track progress and have flags for 367 00:17:57.920 --> 00:18:01.759 completion state and displaying this GUI again. 368 00:18:02.039 --> 00:18:05.720 You guessed it. The blueprint involves on GUI or similar 369 00:18:05.799 --> 00:18:09.319 UI functions stat's gui ash gui are mentioned to draw 370 00:18:09.400 --> 00:18:12.799 labels showing the current stat values and maybe icons or 371 00:18:12.839 --> 00:18:16.279 progress bars for the achievements. Using those tracking variables in 372 00:18:16.319 --> 00:18:18.519 flags to decide what to display. 373 00:18:18.200 --> 00:18:21.920 Gives the player that nice visual feedback and sense of accomplishment. Okay, 374 00:18:22.240 --> 00:18:25.680 foundations core systems, but what about making sure none of 375 00:18:25.680 --> 00:18:27.839 this progress vanishes when you quit the game? 376 00:18:28.200 --> 00:18:33.079 Persistence? Creating save and load systems chapter seven absolutely vital 377 00:18:33.160 --> 00:18:35.559 for well most games that aren't just short arcade sessions. 378 00:18:35.559 --> 00:18:38.599 You need to save inventory, stabs, maede, the enemy, positions, 379 00:18:38.720 --> 00:18:39.519 quest progress. 380 00:18:39.599 --> 00:18:42.319 We heard about player prefs earlier for settings, but that's 381 00:18:42.440 --> 00:18:44.640 usually for small bits of data, isn't it. This chapter 382 00:18:44.680 --> 00:18:45.599 seems to go deeper. 383 00:18:45.839 --> 00:18:49.200 It's exactly. Player prefs is great for simple settings, maybe 384 00:18:49.279 --> 00:18:51.799 a high score, but it's not really suited for saving 385 00:18:51.839 --> 00:18:57.359 complex game states. Chapter seven sploes blueprints using two main methods, 386 00:18:57.839 --> 00:18:59.720 flat files and XML. 387 00:18:59.400 --> 00:19:02.680 Files files just simple text files pretty much. 388 00:19:02.880 --> 00:19:05.960 The blueprint shows saving data line by line. You take 389 00:19:05.960 --> 00:19:09.480 your game data, player position coordinates, x, y Z, maybe 390 00:19:09.480 --> 00:19:12.240 their health there ammo count, convert each piece to a 391 00:19:12.279 --> 00:19:15.440 string using toastring, and write each string on a new 392 00:19:15.480 --> 00:19:17.640 line in a text file. Using something called a. 393 00:19:17.599 --> 00:19:20.920 Stream writer simple readable and loading. 394 00:19:20.839 --> 00:19:23.480 Just the reverse. Use a stream reader to read the 395 00:19:23.480 --> 00:19:26.000 file line by line. Then you have to convert each line, 396 00:19:26.000 --> 00:19:29.799 which is text, back into the correct data type integer, float, whatever, 397 00:19:30.079 --> 00:19:32.279 using functions like convert dot two a thirty two or 398 00:19:32.319 --> 00:19:33.240 convert duct single. 399 00:19:33.440 --> 00:19:36.319 And the blueprint mentions deleting the old file first. 400 00:19:36.279 --> 00:19:39.039 Yeah, common practice to ensure you're writing a completely new save, 401 00:19:39.279 --> 00:19:41.240