4 Techniques for Troubleshooting Godot code

in this video we're gonna look at four tips for troubleshooting problems in godot games when working on your game do you ever have that feeling like this code is just not doing what i want even when you're reading through it it seems fine but there's still a weird bug or unexpected behavior that happens to me all the time it happens to all programmers by the end of this video you'll have a solid foundation of many of the troubleshooting tools provided to you by godot before we get started quick note that i upload game dev tutorials and content to this youtube channel if you're interested in that kind of thing please subscribe so let's take a look at the demo code for this video i've got a method called defeat enemies and that takes in an array of enemies each enemy is a dictionary that has enemy name as a string like bat gives xp which is an integer like 25 and then sometimes there's an extra flag called has bonus and that's just a boolean true or false if that's true i want to double the xp that you get from defeating this enemy now let's take a look at the logic of defeat enemies so for each enemy in the list what i want to do is check if the enemy has the has bonus flag we're going to go ahead and take our xp which is a member variable and add whatever enemy.gives xp is but multiply it by 2 to get that 2x bonus however if that flag is not present or it's false we just want to add whatever the regular gives xp amount is so how do i know this method is actually doing what i think it's doing well the first technique for troubleshooting debugging what we're going to look at is just printing output to the console and so for that godot has a command called print you may have seen it before it's pretty basic but it's very effective print can take in any number of values and so you could have a string like hello or you could have a variable like in our case xp right now and when i run the game we're going to be able to see the output of print right here in the output tab and as you can see this is a little bit not pleasant to read because godot by default will just smash all the values together right in a row what you can do is add an s at the end of print here s and this s stands for space and when i save and run that now godot will separate the values with a space and if you want even more cushion you can instead of using s you can use t and that t stands for tab and now when i run the code godot is going to insert a tab between the values now let's maybe take this message and make it more helpful right now it lives in the block for when the enemy has bonus points so we'll say doubling xp gain and now our current xp is here let's go ahead and add another block though another print method in the other case and this time we're going to use a slightly fancier version there's regular print but then there's also print underscore debug and let's see we'll just say this is a regular xp ad and then again we'll give it the xp amount when i run print debug it's going to include an extra bit of information here and that information is where in the code that that print line executed so this is really useful if you end up having a lot of print lines in your code you can kind of easily lose track of where they all are and where they're coming from and so by including this extra little bit here you'll have more information to make it easier to track down where that print is and now just by observing the console here you can kind of trace the events that have happened so first we get a regular hp ad and we know that because it's the debug line and then we get another one and then we get a double a double and then another one and if we compare that to the array that we're passing in it kind of lines up right regular regular double double regular to wrap up print let's go ahead and just explore one more example say at the end of it i kind of want to you know like a recap of the points that i have now after all of this looping so i'm going to say print here and let's say that we actually want kind of a fancier more in-depth debug message here what you can do is actually use string format templating to kind of make the log a little bit more friendly to read and so we'll say you know gained this many xp by defeating n enemies now to populate these little variables here what i can do is come to the end of the string add a method dot format and then in format we're going to pass it a dictionary and in the dictionary you define the key value pair of what you want injected into the string so we'll say xp is going to be our xp and that's pointed to our member variable up here the thing that we're incrementing and n is going to be enemies.size that's the length of this enemy's array so i'll save and run the code and at the very end we get a nice little recap gain 230 by defeating five enemies so the takeaway here is that if you have some sort of complicated or looping logic and you want to be able to trace kind of what's happening in every step of that piece print can be a basic but effective way of giving yourself a nice logging history of everything that's happening in that method that said there's an even more advanced and effective way of kind of navigating this kind of code and that's by using the debugger which brings us to tip number two okay so tip number two i've gone ahead and removed all of our print lines that we added before and i'm just going to give us a little bit more space here inside the loop uh do you see this area to the left of the line numbers if you click anywhere in that gutter say like right here on line 16 it's going to place one of these red dots and that red dot is called a break point now when godot is executing our code and it sees one of these break points it's going to stop right there and halt everything and give us a moment to kind of look around and inspect what's going on so go ahead and run the code now you can see the code is stopped right here line 16 is where our break point is and it's kind of highlighted here to show us that it is stopped and here you can see that godot in the debugger area has listed out a bunch of variables for us so we have references to the n and the local variables like the enemies that we're iterating through right now which enemy that we're on so this one in the iteration and then we also have our member variables too so our xp you can see that it's at zero because we've stopped right here in the first iteration haven't made it that far into the loop so let's go ahead and continue now this continue button is going to resume the execution of the code uh and it'll just basically keep going until it hits another breakpoint and so because we're in a loop and i hit continue it went ahead and finished the iteration here and gained you know we gained our 25 points for our first enemy you can see that working here and then now that it hit another iteration or i'm sorry it hit another break point it stopped there again given us another chance to kind of stop and look around and now right next to the continue button there's two more buttons here that we're going to talk about this one on the right is called step over and you can also just hit f10 to fire it but if i click it it's going to start stepping through the code which means it's going to run line by line one line for every step that i do and that way we can just slowly kind of trace through what the code is doing so i'll go ahead and step over now i'm on line 17 it's going to evaluate you know do i have the has bonus points flag if i click it one more time you see that it went to line 20 because we didn't have the flag so it went to the else case and i'll just kind of keep going okay another iteration this time we do have the flag so you can see that it went in here and remember all the while you can see that xp is live updating right here as we go it's also worth noting that you can hover over anything in the code editor here and gojo will tell you what that is which is really handy let's continue stepping through and you can do that all the way until the code finishes now to compare this with the workflow of printing things to the console like we looked at before instead of having to sprinkle in all those print lines everywhere and then run the game and then look at the output tab and kind of compare what we saw to what we expected to see this is much more convenient because you can just slowly step through everything that's happening along the way without needing to like boot up the game and run through the whole thing every time if you start to get in the habit of using the debugger instead you're probably going to be able to get to the bottom of bugs much faster now i'm going to add just a tiny bit more code here to show you something else let's say we have a different method that's called i don't know add more xp i'm just kind of making this up as we go it's going to add xp you know 10 and then just doing something goof here 20 30 40. now at the end of this loop here i'm going to go ahead and use our other you know new method add more xp and then at the end of that i'm going to just print you know we're done adding xp i'm going to add just one more quick line here when we're done with the loop and now i've taken away our break point at line 16 and instead i'm going to place a different one right here on line 21 when that loop is over now when i run the code it's going to stop after our xp loop and i want to show you the difference between these two stepping options the one we've been using so far is called step over but right next to that one is a different option called step into and so here's the difference we are currently debugging inside the function defeat enemies and so what step over is going to do when it stops at this break point is that any other function calls that happen technically the next thing in the code that would run are all the contents of that function and so ca we do add more xp uh we're gonna hit this line and then this function's gonna start and then it's gonna do this line this line this line this line and then it's gonna come back and we'll be back in our function here sometimes when you're debugging it can be kind of disorienting when the debugger jumps around on you this is kind of a simple example but in more complex projects the next function that runs may be like in a whole new file or a completely different place in the code and so what step over is going to say is that any external function we come across just like this one it's gonna go ahead and fast forward through all the executing and just plop us out on the other side so here all of the code inside add more xp did run but the debugger didn't take us through it line by line and so that's where this neighboring button step into comes in it's gonna execute and then it's gonna keep going line by line no matter what's happening to see that the debugger bounces us into this other function here we keep going when we're done with this one it's gonna bring us through on the other side and now we're back to the function that we started debugging in using step over versus step into can kind of depend on the kind of detail you're looking for sometimes you don't really care what's going to happen in that other method maybe the bug you're interested in like the problems happening on the other side or that part's just not really relevant sometimes it is and so if you need to go super fine detail of absolutely everything that's happening that's where step into can be your friend so that wraps up our tip around the debugger next time you're working with your code and something doesn't seem like it's working right try placing one of these break points and navigating through the code this way to have more clarity on exactly what's going on and when now for our third and fourth tip today i've set us up a little bit of a test scene i'm going to walk you through that right now here we have main scene is what it's called there's a color wrecked to give it this kind of green background and then some blades of grass to make it feel all outdoorsy so those are just sprites and then we have a sprite called character that's in the middle of the screen popping over to the new demo code here when the scene enters the tree we're going to make a new variable called sum variable we'll use this in a second and then we're going to set up a timer so i have t as a new timer we're going to connect to the timer's timeout signal and when that happens we're going to go ahead and fire our move character method which lives right here the timer's interval is going to be a half a second 0.5 and then we've made sure that one shot is turned off and so in a timer when one shot is turned off that means that the timer is going to repeat firing at that cadence so it'll be fire fire fire fire it'll keep going every half second then we're going to add the timer to the scene and then start the counting when move character fires it's simply going to take our character grab the position x and add 10 pixels to it and one thing to note we are creating and adding this timer with code it doesn't initially live in our scene tree we're kind of dynamically adding it on the fly and so when i run the code you can see that it's working fine the character is moving a little bit to the side every half second but let's say that i want to pass more information into this move character signal say that i you know grab some variable here it's not really doing anything right now but just to show you if we pass it in here and now i rerun the code the character's not moving anymore it's like this thing isn't wired up and working anymore notice down here the debugger number is starting to go wild it's incrementing every half second if i click on this and then see this error tab it also has that same number that's going up and open that up you can see that godot's giving me this warning basically the connected signal expected zero arguments but i called one and so when that happens the signal still fired but this particular connected function did not because of that argument mismatch and so to fix it we basically need to be ready to accept this argument and now whenever you run the code you can see that it works again and so the takeaway here is that sometimes your code may not be firing at all when you expect it to and you're not getting like any clear runtime errors or crashes or anything like that it's just something's not happening pop over to this error tab and see if it's warning you about anything it's very likely that maybe you have one of these mismatches or something else isn't quite wired up right the error tab will tell you hopefully what's going wrong and finally our last technique for today is going to be learning to use the remote tab for debugging the live scene tree of your actual running game and so again here's our main scene it's got all the nodes that we've set up during development but if i run the game you see that this extra section appears we have local and remote so if i click over to remote the scene tree here is going to switch to the actual scene tree that's running inside our live game this one right here and so see that the tree mostly looks the same except there's this extra timer and that timer is the one that we dynamically played with and added with code and so here if you want to grab the timer and kind of make sure that everything was set properly on it you can even play with the values in real time and the game will update so now that just increased it to like six will go down like crazy um let's see where our character is by now our character is completely off the screen but what i can do say i need to be like hey come back here what i can do is inspect the character find his x position and see that it's slowly well quickly updating every uh every time that timer goes off i can just grab it and sort of live edit it so i'll say now you're at zero and when i did that our character warped all the way back here in real time and so i have two main takeaways for the remote tab the first is that if you run your game and maybe things that are dynamically placed end up in weird places like they're off screen and don't kind of line up with where you expected them to be instead of just guessing get in here with the remote tab find them in the tree and look at where they landed with their positions you can then just move them around from there and kind of figure out why they landed where they did the second main takeaway is that if you're working on tweaking presentational stuff like maybe ui positions or animation speeds or things like that you can try them out right here in context of the running game rather than tweaking the code stopping the game rebooting the game tweaking the code again that kind of workflow you can get it right where you want it right here and then just commit it to the code when you know what you want alrighty that's the end of the four tips we had print we had the debugger we had the error tab and we had the remote tab i hope you take these tips integrate them into your workflow and be more productive than ever if you got some value out of this video i really appreciate it when you hit the like button and again if you're interested in this kind of content subscribe for more i have more godot videos on this channel so if you're interested in that one more is going to play right after this one be sure to stick around and finally if you've been working on a game or you have an idea for a game but you're not really quite sure how to get started you should join our discord we've got a supportive group of people that are making and playing indie games so if you have an idea for a project or you've been working on a project pop in there tell us about it we'd love to see you there that's all for this one thanks everybody catch you next time you

Channel: Drew Conley

Views: 1,583

Keywords: godot tutorial, gdscript, beginner tutorial, troubleshooting, debugging, gamedev

Id: -LCBgGK-BAk

Length: 16min 40sec (1000 seconds)

Published: Wed Apr 07 2021