How to improve your debugging skills - Be a better game dev

[Music] welcome back to another episode of be a better Game Dev in this episode we are going to be taking a look at how you can actually improve your debugging skills a little bit with making use of the blueprint debugging tools that we have available in Unreal Engine and with that we're going to be going through things like the data flow the call stack showing you how you can keep track of your break points and showing also your execution trains among other things as keeping track of your different object and variables that you might have in your scene to to find your issues as quickly as possible so let's check it out welcome back so in this video we are going to be checking out how we can take our debugging to the next level in software development and game development as well uh debugging is a crucial critical tool to have your game and code running as you expect it to it is Essen ential for for troubleshooting and finding problems in your code so I done tutorials in the past uh on the topic of debugging and today we're going to be enhancing upon that a little bit so for that I have created some code here inside of my third person character and I'm going to setting a breako over here and then we're just going to run our code and have that code execute and stop on our breakpoint now what we're going to be doing today is we're going to make use of our blueprint debugging tools and these you can access either by going to in this case you have in your third person map you have tools available to you you can go to debug and just blueprint the bugger but you can also access this from another blueprint like this one you can see here we don't have tools available but you can go to debug and click on uh blueprint debugger and you get it over here so that is how you uh start it off uh when you need access to it now depending on how you started it if you started it from your your tools or if you started it from the debug window uh this might look a little bit different here uh because the debug tools here are set up in such a way that you have a few different options if you click on window you can see you have a call stack and you have a data flow uh the call stack is the window over here to the left where you can see currently these things and to the right right here we have the data flow and in this case uh we started the blueprint debugging tool from our third person character which means that it's going to be using that as its filter here for which uh class it is will be debugging if we were to choose none here for example you can see we get no instances of this blueprint in this let's see if we can move this out a little bit in the in existence so so no blueprint is chosen here but going in here you can actually select whatever blueprint uh class that you want to make use of at all so if we go back and choose our third person character you can see that what we currently have going on here is uh a few things we have a yellow arrow here this is denoting that this is where our breakpoint took place and inside of that you can just expand it and you can see that you have access to all of this information here so this information will be in real time updated as you uh run your code and step through it so that's that's one part but the part that we're going to be looking at first is actually if we go to the call stack the call stack is a a hierarchy of uh different functions and events and how they were called in sequence so to visualize this I created a little bit of an example here so on the event key of one here we have a function that's being called that's called function one so we can see here in our call stack we have that we first have a one key so that's the event that was triggered over here and if we were to click on it it will take us to that point in the code as well U if we click on event graph over here you can see that this is the function that is going to be running now if we were to debug here and you can debug either by the normal debugs up here and also the same over here doesn't really matter it's the same but if we were to step into this code now we can see that we're going into function one which in turn is going to be calling function two now you can see we have another level added to our call stack which is showing that we have the event graph over here and we have a function one over here being called and as we keep going through like this you can see that we have more code that's being executed and we get deeper and deeper and we get more layers on our stack right so what is the purpose or what is the the main benefit of having something like this well when you uh the bug around in blueprints normally and you step through the code uh you might have if you're doing objectoriented code you might have a function or a class or something that's happening many many times uh from many different points uh could be like different places that they're called from it's being executed on multiple different actors things of that nature right so if we have something like uh let's see here our event graph let's remove this breakpoint for now if we were to have something like this here we have an event where we're going to be attempting to destroy something this this case it's just going to be destroying an actor of a type reference and this reference over here is currently set to be doesn't show anything here but if we go into our character over here and we scroll down to over here we can see that our active reference here is a champer cube this is actually this blue cube over here so if I were to run this game and press two you can see that we're deleting that cube right nothing really special about that but but this attempt to destroy here might be coming to this code without having that reference set for example right so in this case here I have another piece of code I have a three event and after that I clear out the reference that we have and then I try to destroy this uh active reference so the same thing I press three we see nothing happens but when we stop we get an error saying that we had a runtime error of access none so we might be like thinking ah at some point in the code I'm running into this problem where um I'm trying to destroy my my Cube and it doesn't work for some reason right well what you want to do you add a break point to where you have the issue in this case is the destroy actor and we run the code we press our key and we uh encounter our blueprint uh debug uh breakpoint okay now going to our blueprint debugger tools you can now see that we have a call stack here and we can can see that we're attempting to destroy inside of this third person character which in turn was called by the third person character event graph which in turn was called by the third person character three event and then other than that we can also see that there's native C++ code being called here which is uh not something that's visible straight up like this but for blueprint debugging that won't really be a problem in most cases so in this specific case we are able to see that ah okay so this specific time that I'm actually trying to delete this and I'm getting this problem the reason is because I'm calling it over here and ah okay I'm clearing out the reference okay that makes sense right so that's what call stack generally is useful for you can locate a place where you have a problem and then set a break point there and then when you end up in that situation when you know that it's going to go wrong you can backtrack through your call stack and see if you can find the problem along the way right moving on uh if we go into our third person character again and we put a breakpoint here on a new piece of code here we can see I have some code here running that's going to be adding an actor to an array uh if we were to run this code and press four you can see that if we go back to our blueprint uh debugging tools again and instead of being in the stack part we go to the data flow part uh we can see a few things uh first of all we have two different uh sections here the first one here is called breakpoints this one will keep track of all the different break points that you have so if you have been like trying to debug um some issue a lot of different levels and a lot of different places U you can see the break points here and you can even navigate to them by clicking on them so that's a good way to keep track of where your breakpoints are and if you want to remove some and stuff like that uh in addition to that we also have if we go into our third person character I showed you that you had all of the different um actually let's go back to the other more relevant breakpoint uh we can see that we have all of the different uh variables that are contained within of this blueprint in this case so we can keep track of things so here I put some example code we go in here we just add a an actor to an actor of arrays and if we step through this we can see that in real real time it is getting updated so that when we click here our array of class actors you can see we have now one and it's containing an actor if we continue with the code we can go in here we're adding a sky sphere can see that we now have a sky sphere added and we continue like this and we now add a AI controller and we now have another AI controller so you can go through this code and you can see it update as you're going along right again if we were to have something like U uh let's see running like this and we have our blueprint and we just want to uh see how this array of class actors change and we know that that's what's going on here we don't have to debug through the whole thing it keeps updated as your code is executing right so after having run this first function we have our actor after running the second one we have our Sky spere after running the third one we have our AI controller so that's how you can keep track of your data as you're debugging through all of it in addition to that you can also go and check out your execution trays the execution Trace uh has a bunch of different filters to it um you you can you can uh remove certain things from from this if you want to um actually not not the trace itself this this window has a few different things if you take the trace the traces it's it's going to go away uh but uh in this execution Trace you have a few different a bit more detailed information about the nodes that they're executing as opposed to the call stack for example the call stack is very good because you can use the call stack to see the specific levels that are being called from functions and events as the code is being run through the execution Trace will be much more detailed and we can navigate to all of the different parts uh just like the call stack by just clicking on them so if we click here we can see that we're actually going to the print string and we can see that there's an arrow here showing that that's actually where we are in the execution of the code flow we can see also that there's a left Arrow here showing that this is some code that we have passed so this in this case is showing of this function over here that add AI controller clicking on that we can see a return node inside of the AI controller you can see that we actually get multiple um instances of the log for this before that we have an ad after that we have or before we have a add AI controller to array node and then we go out and we come out into the sky sphere and so on so uh this is a way for you to step through your code in a more detailed manner if that is needed uh and the the call stack itself is not enough this this uh window also contains a bunch of different information you can see IDs and stuff like that you can also see times I believe uh you can see there 1. six s seconds so you can get some kind of reference I'm not sure how accurate it is to see as a measure of performance but you can see uh some some kind of time stamps for uh when the different parts were executing as well um if nothing else it can be used as a reference note to see when your code flow is running different parts if you're expecting them to be sequential but they're not actually you know that sort of thing um so yeah that that's also a very good thing to keep in mind of so now now I've added a little bit more code to this project so if we press play we can see that this is a main menu widget up here in text as above us this is essentially just a simple widget that we have added and the reason for this that we have this is because now when we press our five key here we want to call on our widget and say we want to do something inside of it so we debug inside of it and we see that our blueprint debugger is gone what's going on here we'll just go back to our third person character we see it over here okay it's just docked over here where we can just undock it and then have it as a free flowing window and that way we can make use of it in our W widget right no it disappears when we go into the widgets okay what's going on here is it because we have our third person character we need to show our widget no that doesn't change anything either uh this is a little bit of a finic Behavior Uh which I want to make you aware of that it exists essentially it it lives in its own instance where it U sort of was created and placed but only under certain circumstances so if we were to for example in this case close this down and go inside our main menu widget and we go to debug and choose blueprint debugger if we had the other window still docked it would just be moving over to a third person character but now you can see that the window is actually existing and persisting through our different tab clicks right so something to be aware of and it might feel a little bit frustrating if you're starting out so hopefully this will give you a little bit over that hump so you can focus on actually troubleshooting your problems themselves but yeah so now we're inside of this widget here now we can go through its code here and we can see okay we have an integer value we go through we add something to it we set it okay it's gets updated and we can keep track of all our different things here as well so uh the these things exist within a a filter of the objects that you're uh trying to work with which uh depending on how many objects you have might be uh fine uh if you want to have a specific object let's say you had a bunch of different widgets that were all main menu you could go through your uh filter up here to make sure that you're only executing on a specific uh or actually see so when your uh breake points run and you debug through that you're running through that instance of the widget or the other class that you're debugging uh itself uh but if you were to have multiple main widgets uh main menu widgets in this case they would also all show up here if you didn't have a filter up here uh so you can debug them and show them all in parallel and compare them to each other which also has some value to it right because maybe you have four different classes of um uh four different objects of a class and one of them is weird and you want to see why maybe you can see the differences here and then correlate it back with your call stack or some of the other things we've gone through uh to see what the actual error is so yeah I hope that this brief overview of the debugging tools will allow your debugging to be slightly more proficient and helpful I feel that the call stack is actually a very important part of debugging I use it in a lot of different other languages when I debug so hopefully that at least will prove useful to you in the future anyway that's going to be all for now keep on learning take care a big thank you to all of you who like comment subscribe and share my videos or through other means support this channel you are what makes this channel grow and become a resource for other people to learn from

Channel: LeafBranchGames

Views: 4,081

Keywords: learning hub, unreal engine, tutorial, unreal engine 5, blueprints, game design, game dev, unreal engine 5 tutorial, unreal engine 5 beginner tutorial, ue5 beginner tutorial, building user interfaces for unreal, engine ui design, user interface, design ui, design tutorial, building user interfaces, unreal engine user interface, Leafbranchgames, Good habits, Best practice, How to build menus and UI for Unreal engine 5, the right way, UE4, UE5, Reuse, Recycle, be a better game dev

Id: OR_yKdp0_40

Length: 16min 55sec (1015 seconds)

Published: Tue Jan 16 2024