Godot Debugging Techniques EVERY Dev Should Know

Summary

This video script offers a detailed guide on advanced debugging techniques for game development, moving beyond basic 'print' statements. The speaker uses a Metroid Vania prototype to demonstrate scenarios where traditional console logging is insufficient and introduces more powerful methods like 'push error' and the debugger. They also show how to use the remote tree for runtime inspection and editing, as well as how to set breakpoints for step-by-step code analysis. The script concludes with tips on using visual aids like collision shapes for debugging, advocating for a more efficient and insightful approach to finding and fixing bugs in game development.

Takeaways

• 😀 The script emphasizes the transition from using print statements to more advanced debugging techniques to save time and improve efficiency.
• 🔍 It suggests that while print statements can be helpful, they can be visually mixed with other console output, making it difficult to isolate errors.
• 🆕 The video introduces the use of 'print_err' to make error messages stand out more in the console, but notes it doesn't add new functionality.
• 💡 The script recommends using the 'push_error' method to send errors to the debugger, allowing for better inspection and navigation to the source of the error.
• 🔧 It highlights the importance of using the debugger to expand and follow the logic of the code, providing a clearer path to identifying the root of the problem.
• 📚 The speaker discusses the various print functions and how to navigate to their definitions for further investigation of alternative options.
• 👀 The script introduces the concept of using the 'remote view' to inspect objects live during gameplay, offering a more dynamic debugging approach.
• 🛠️ It explains how to use the 'remote tree' for debugging, allowing real-time inspection and editing of game objects to identify and fix issues on the fly.
• 📱 The video shows how to use breakpoints effectively to pause the game at specific points, inspect variables, and step through the code to find where logic fails.
• 🔄 The script discusses the use of 'step into' and 'step over' features in the debugger to navigate through code methodically and understand the flow of execution.
• 🎛️ It also touches on the use of visual aids like 'visual Collision shapes' in the debugger to get immediate feedback on game mechanics and interactions.

Q & A

What is the main issue with using 'print' statements for debugging in the script?

The main issue is that 'print' statements can be underpowered and visually mixed with less critical outputs, making it difficult to isolate and identify errors effectively.

What alternative to 'print' is suggested in the script for better debugging?

The script suggests using the debugger or methods like 'push error' for better visibility and functionality in identifying and resolving errors.

How does using 'push error' improve the debugging experience compared to 'print'?

'push error' pushes the error message to the debugger, where it can be expanded and investigated in a more organized manner, separate from other console outputs.

What is the advantage of using the debugger over 'print' statements?

The debugger allows for the inspection of the state of the program at specific points, enabling the developer to follow the logic and directly jump to the line of code causing the issue.

What is the 'scene manager' mentioned in the script, and why is it relevant to debugging?

The 'scene manager' is a part of the game that handles the loading and transitioning between different game scenes. It is relevant to debugging because issues in scene loading can cause the game to fail or behave unexpectedly.

What is the purpose of the 'remote view' in the debugger, and how does it help with debugging?

The 'remote view' in the debugger shows the current state of the game objects and variables at runtime. It helps with debugging by providing a real-time inspection of the game's internal state, which is more useful than the static 'local view' from edit time.

How can the 'always on top' setting in the project settings improve the debugging process?

The 'always on top' setting ensures that the debugger window remains visible and in focus, allowing developers to inspect variables and objects without losing focus when interacting with the game.

What is the benefit of using breakpoints in the debugger?

Breakpoints allow the developer to pause the execution of the code at specific points, enabling them to inspect the state of variables and objects at that moment, which can be crucial for understanding and fixing complex issues.

What are the two main actions available when the code execution is paused at a breakpoint, and what are their purposes?

The two main actions are 'step into' and 'step over'. 'Step into' allows the developer to enter a function and execute it line by line, while 'step over' executes the current function without stepping into it, moving to the next line. These actions help in auditing the code and understanding the flow and state changes.

How can the 'visual Collision shapes' setting in the debugger help with game development?

The 'visual Collision shapes' setting provides visual feedback on collision detection within the game, allowing developers to see and adjust the positions and sizes of collision areas for better game mechanics and interactions.

What is the final advice given in the script regarding the use of 'print' statements and debugging?

The script advises not to completely quit using 'print' statements but to incorporate additional techniques such as using the debugger, breakpoints, and remote views to enhance the debugging process and write fewer bugs in the first place.

Outlines

00:00

🐞 Advanced Debugging Techniques

The speaker discusses the limitations of using 'print' statements for debugging and suggests more effective methods like using a debugger. They demonstrate using 'push error' to isolate errors in a game development scenario with a Metroidvania game prototype. The video also introduces the concept of using the debugger to trace and inspect the game's logic and objects in real-time, providing a clearer path to identifying and fixing bugs.

05:02

🔍 Inspecting Objects and Debugging Live

This paragraph delves into the process of inspecting game objects at runtime to debug issues. The speaker explains how to use the remote view in the debugger to observe the game's state and make real-time edits to variables, such as player strength, to test hypotheses about the source of bugs. They also highlight the importance of using breakpoints to pause the game at critical points and inspect the state of data being passed between levels.

10:03

🛠️ Utilizing Breakpoints and Step-by-Step Debugging

The speaker provides a detailed explanation of how to use breakpoints in the code to identify the source of errors. They illustrate the process of stepping through code line by line to observe variable states and the order of operations, which is crucial for understanding where logic fails. The paragraph emphasizes the utility of stepping into or over functions to focus on specific parts of the code where errors are suspected, without getting bogged down by parts that are known to be correct.

15:04

🎨 Visual Debugging with Collision Shapes

In the final paragraph, the focus shifts to visual debugging tools such as collision shapes and area 2D triggers. The speaker explains how enabling visual collision shapes can provide immediate feedback on the game's collision mechanics, helping to identify issues that may not be immediately apparent through code inspection alone. They also touch on the importance of visual feedback in conjunction with other debugging techniques to ensure a comprehensive understanding of the game's behavior.

Keywords

💡Debugging

Debugging is the process of finding and resolving bugs or defects that prevent correct operation of computer programs. In the video, the theme revolves around improving debugging techniques beyond using simple print statements to the console. The script discusses various methods such as using a debugger tool, setting breakpoints, and inspecting objects at runtime to effectively hunt down and fix bugs.

💡Print Statements

Print statements are lines of code used to output information to the console for debugging purposes. The video suggests that while print statements are a basic method for debugging, they can be visually mixed with other console output and may not provide enough functionality for effective bug hunting. An example from the script is when the scene manager fails to load a level due to a typo, and using print statements doesn't help isolate the issue clearly.

💡Debugger

A debugger is a tool used by programmers to test and debug their code by examining its execution step by step. The script emphasizes the use of a debugger as a more powerful alternative to print statements, allowing for the examination of variables and code flow in real-time. The video shows how to use the debugger to pause execution at breakpoints and inspect the state of the program.

💡Breakpoints

Breakpoints are markers in the code that tell the debugger to pause the program's execution at that point. The script describes how to set breakpoints in the margin of the code, which allows the programmer to stop the program just before a particular line of code is executed, making it easier to inspect the current state of variables and objects, as demonstrated when the scene manager is about to pass data between levels.

💡Scene Manager

A scene manager is a component in a game engine responsible for switching between different scenes or levels in a game. In the script, the scene manager is used as a context for demonstrating debugging techniques, such as using print statements and breakpoints to troubleshoot issues with loading a level file.

💡Remote View

Remote view in the context of the script refers to inspecting the objects and variables of a running game as they exist at runtime, as opposed to the local view which shows the state at edit time. The video suggests enabling the remote view for a more useful debugging perspective, allowing the programmer to see and interact with the game's current state, such as the player's strength or the scene manager's variables.

💡Step Into / Step Over

Step Into and Step Over are controls in a debugger that allow the programmer to execute code one line at a time, with Step Into entering into functions and Step Over executing the current function without stepping into it. The script uses these terms to explain how to carefully inspect the code line by line or function by function to find the source of a bug, such as when testing the logic of moving objects in the game.

💡Data Packet

A data packet, in the context of the video, refers to a collection of data being passed from one level to another in a game. The script discusses how to use the debugger to inspect the contents of a data packet at runtime, which is not directly visible in the scene tree, to ensure that the correct information is being passed, such as the door the player is exiting through.

💡Visual Collision Shapes

Visual collision shapes are graphical representations of the collision areas in a game, used for debugging purposes. The script mentions turning on visual collision shapes in the debugger to get immediate visual feedback on whether elements in the game are colliding as expected, which is useful for adjusting things like the length of a raycaster.

💡Raycaster

A raycaster in gaming is a method used to detect collisions or intersections with objects along a line extending from a point, often used for line-of-sight or aiming mechanics. The video uses the raycaster as an example of how visual debugging can help a programmer see and correct issues like ensuring a raycaster is long enough to reach its intended target.

Highlights

Transitioning from using 'print' statements to more advanced debugging techniques can save time and improve efficiency in bug hunting.

In scenarios where 'print' is underpowered, using a debugger provides a more effective way to track down bugs.

Demonstration of debugging a Metroid Vania game prototype to illustrate the use of debugging tools over 'print' statements.

Using 'push error' instead of 'print' can help isolate error messages and make them more visible in the debugger.

The debugger allows for expanding and following logic, providing a clearer path to identifying the source of an error.

Different 'print' functions can be used, and clicking on them can lead directly to their definition for further exploration.

Switching to 'remote view' in the debugger provides a live representation of the game state, aiding in debugging.

Enabling 'always on top' for the debugger window keeps it in focus, allowing for continuous inspection without losing the view.

Using the debugger's 'remote tree' to inspect and edit variables at runtime can help identify and fix issues on-the-fly.

Setting breakpoints in the code allows for introspection at specific points, providing deeper insight into the program's state.

Stepping through code line by line with the debugger can help identify exactly where logic breaks or variables are undefined.

The debugger's 'step into' and 'step over' features are useful for auditing code and checking variable states incrementally.

Visualizing collision shapes and triggers during debugging can provide immediate feedback on game mechanics and interactions.

Debugging can be applied to non-scene tree elements like data packets passed between levels, which are not directly inspectable.

Using breakpoints to walk through code can reveal issues with generated or dynamically created elements that aren't easily inspectable.

Debugging not only helps in identifying bugs but also in understanding the flow of execution and variable states over time.

The video concludes with a reminder that while 'print' statements are not entirely obsolete, incorporating debugger tools can significantly enhance the debugging process.

Transcripts

for the better part of my career I did

most of my bug hunting by desperately

printing messages to the console like a

caveman cave

person anyway it's time to quit using

print and save yourself a bunch of time

in the process let's

[Music]

go all right so I'm not actually

suggesting you never use print again but

there are some scenarios where print is

underpowered the debugger or methods

might be a little bit more effective for

hunting down one of those pesky bugs in

this video I'm going to use this Metroid

Vania sooon prototype I've been fiddling

with we're going to look at a couple of

scenarios where I might need to debug

this prototype let's take a look at this

scene manager so this is actually an

early version of what later became the

scene manager video that I made I'll put

that up in the corner now if you want to

check that out the game when I run it

will attempt to load this level two file

and and let's just suppose for a second

that I mistyped this and if I come down

here I've got this check where if the

resource it's trying to load doesn't

exist it's going to dump out of it and

it's going to print you know a message

to that effect so if I run this you see

nothing loads and I come down in here

and yeah I do get this error showing you

know does not exist you know it's kind

of mixed in visually with all this other

stuff that I've been outputting stuff

that's probably less critical because

none of this is forcing the game to fail

to load you know I I can't click on this

I can't really do anything useful with

it and yeah maybe in this example I

might just right here notice that oh

it's that extra two but maybe I forgot

where that's defined so the sort of next

line of defense here is instead of using

print I can use print err and if I run

this I still get that same error stands

out a little more but I'm not getting

any new functionality out of this so

instead of that we can use push error

what you'll see now instead of showing

up here with with all this other stuff

it's actually gotten pushed over to the

debugger where I can now actually expand

it first of all and I can follow the

logic okay the ready fired uh and then I

got into the scene manager which called

load scene and I can literally click on

this move this to the side and it's

going to take me right to that line and

now I can investigate a little bit

further and go okay so this failed in

the scene manager let me scroll up oh

yeah okay this is just a typo and now if

I close this and rerun it it would be

fixed there are actually quite a few

different print functions and if you

command click or control click on a PC

it'll take you right to the definition

and then you can scroll through and have

a look at some of the other options that

are

[Music]

available we could actually take that a

step further cuz let's pretend for a

second that this wasn't the error maybe

following that thread into the scene

manager got me closer but not all the

way there the next line of defense is

looking at some of these objects live um

inspecting them so let's go up to editor

editor settings and search for remote

and then come down to debugger and check

this always switch to remote scenry let

me uncheck that real quick so you can

see what this does when you run the game

you get your window here and then here

is my local view this is everything I

did at edit time if I switch manually

over to the remote view it's going to

show me what's actually represented

right here I've got the scene manager

and Global these are my autol loads and

then if I click Start it's going to take

take us into well it's actually not

going to take us in because that error

is still there but what you would see is

that level loaded you can see it already

started doing some of that um but we're

stuck because we haven't fixed that so

if I come into editor settings and check

this on now when I play this you see it

automatically switches over to our

remote view which generally from a

debugging perspective is way more

interesting and useful than your local

view so I like to turn this on the other

thing I like to turn on is under project

settings with your advanced settings

turned on you can search for always and

then go to window and turn on always on

top if I uncheck this and we run our

game comes up automatically switches

over to the remote but if I want to

inspect one of these see as soon as I

click it pushes that window to the

background because it's lost Focus so

with that turned on it switches to my

remote view I can click on the scene man

manager and look at the information in

it I can click on all of these things

and this is still going to stay front

and center I find those to be to very

helpful settings not just for debugging

but for working on your game in general

in a minute we're going to talk about

how to use the debugger but before we do

that I want to talk about how to use the

remote tree to debug rather than having

to use print statements so let me fire

up this level one of the things in this

game is that you can push more than one

block at a time and so there's the sense

of of the player strength and then the

concept of the weight of the total

objects that are being pushed so if I

push this block up and try to push it

again with the strength of one I can

only push one block so this effectively

is now solid because I can't move two at

a time if I collect this strength object

it should allow me to push both of these

but it's not and this could be for a

number of reasons it could be because

the thing I collected is broken it could

be that the logic behind tallying the

total weight of the push is broken it

could be a whole bunch of different

things and I could go through my code

and put print statements all over the

place and try to figure out exactly

where the error is but instead I can

click over here onto my globals which is

where I'm managing the player strength

you can see it's set to one right now

and now I can move my player around and

I can collect this and I can see oh you

know what player strength hasn't changed

hang on a second so let me take a look

at my strength upgrade oh well here's

the issue I'm not adding one I'm adding

zero so if I save this and play now when

I collect this I can push one and oh now

I can now I can push two great that's

fixed not only can you inspect things at

runtime but you can also edit them as a

way to debug whether that's even the fix

so let's say for example you know I push

these and okay so my strength is one I'm

trying to push two so of course of

course that doesn't work let me click on

globals and increase my strength to two

now I can come back to the game and push

and oh it works okay so the issue

actually is the player strength it's not

something else and then that might be

where I go in and fix this but what if

we're running into an issue we want to

test that isn't represented in our scene

tree how do we inspect that that's where

the debugger can give you insight into

things that the scene tree

[Music]

can't

so let's jump over to our scene manager

again this portion of code right here is

where we're passing data from one level

to the next so this is this data to pass

packet is where we're defining a bunch

of things like the door that the player

came through and whether they're

bringing a crate with them this doesn't

exist in the scene tree it gets created

by the level you're exiting and passed

off to the level that you're entering so

there isn't really an easy way to come

into the scene to click on something and

take a look so we can use the debugger

by clicking in this margin here you see

this little red dot when I click here it

creates this little red dot which means

that it's going to execute code up until

that point and then it's going to stop

before it continues and I can put as

many of these as I want and I can walk

through them and take a look into the

variables and objects and other things

in that moment in time before continuing

on so if I run this now we're going to

see it when I click Start because it's

using that scene manager so you see it's

paused that's why I have this little

arrow in here and I don't know where to

put this so with it paused I have a

couple of options I can step through my

code one line at a time um and we'll get

into why you might do that in a second

or I can click this little continue

button which is just going to say all

right just continue executing from here

on out until you hit another break point

so I'm going to click that because I

don't actually want to inspect anything

right now I'm going to keep clicking

this until we get into our level and

then what I actually want to do is I

want to look at the data packet that I'm

handing off oh actually got to move the

blocks into place now the door is open

and I can pass and now I'm going to hit

that break point so we're we're right

here and so this data to pass does exist

and I can actually just scroll down here

and you can see right here here's my

data to pass and if I click on this it's

going to open up in our properties

window just like we're used to seeing

when we're editing our game this is the

departing door ID so we're exiting

through East and when we enter into the

next level we're entering through the

west door so if I hit continue again my

player gets positioned right here which

is one unit to the right of the west

door now granted this level is a

placeholder and only has the one West

door but if we had a North a South and

an East door it's not going to know

where to put the player unless I tell it

where I came from but if for example I I

came through this door actually here we

can do this we can do this live so if I

go to

level two and click on my level Gateway

here right you see over here I'm

defining destination G Gateway West well

maybe I duplicated this from another

door in the room and then I forgot to

change it maybe it said East if I play

this again oops hang on oh this is

actually a good opportunity to show you

this so the reason it started Us in the

level that we left from is that I'm

actually in the middle of writing the

save system and and it remembered that I

was in that room when I quit and so it

put me back there and that's not what I

want during this test so an easy way to

undo that is I can go into project open

user data folder and it's going to bring

up this it's my save file which I can

just delete and now if I test this again

and we're going to have to skip through

this break point now we're in this level

let me push my crates into place and now

when I go through this door it's

actually going to CRA well it's not

going to crash let me continue through

now you see I'm here and not here and

that's because this is the default

starting point I currently have in this

temp level so let's do this one more

time so we've got that breakpoint set up

right now if I go through this now it

pauses and I can come in here to the

data to pass and

go huh destination gate East well that's

not right because I'm coming from the

East so I have to end in the west so I

can quit this and go back in here and

you know reselect that and fix this

issue here so you might be thinking well

do you really need the break point can't

you just come in here click on level

Gateway and look at this and see that

it's wrong yes you absolutely can do

that this is a contrived example where

we know the problem at a time if I had a

much more complex game maybe it's

procedurally generated stuff and you

know it's harder for me to recreate

exactly the scenario you know one uh I

don't know where to look in the first

place um that's what the break point

might get you is that introspection but

also maybe it just doesn't exist in a

form like this because things are being

generated on the fly so you know that's

where using break points and inspecting

your code uh one line at a time and

looking at the objects as they exist in

that moment uh can be really powerful

getting back to the the different

controls here in the debugger let's um

let's uncheck that because we don't want

to do that anymore and let's go over to

our level objects and the way this

system works is when the player presses

a direction the request move fires and

we check whether or not we're able to

move into that space if we are then we

attempt to move the tile and then when

everything is done this move ended

function fires and the turn is over

let's say I've got an error somewhere in

that chain of actions and I'm not

exactly sure where it is I can put a

break point here and this might be a

kind of a janky game to check it on to

test it on because we're going to get a

lot of break points because the turns

are short but you know if I press left

you'll see it's attempting to move and

now it's paused here and instead of

hitting continue I might want to step

through my code one line at a time and

see how the variables change and in what

order and you know where the logic

breaks so I can actually I can press

these two items down here will

respectively step into a function or

step over a function and both of them

will move one line at a time so if I

click this one what you see is going to

happen is it's going to go to the next

line and if I click it one more time

it's going to go from line 11 to line 12

it still executed that function it's

just not going to walk you line by line

through it why is that important well in

this case maybe I know that my check all

moves function is perfectly fine you

know if this were let me pause this for

a second let's say there was a line here

that was significantly more benign I

know this is working so if I run this

code and I start stepping through it I

get to this and I'm like I don't need to

granted that's one line but if this were

a a larger function that I know to be

sound I can step over that function

instead of into it and I can actually

verify okay here's X yeah okay X is four

that's correct If This Were a really

long function that I knew to be working

I wouldn't want to jump into it and go

through that line by line I just I want

to continue through and you know look at

other lines where I think the logic

might be failing me so you know if I ran

this again and I try to move and I hit

my break point if I I step down to this

and then into my check all moves

function as an example by clicking the

step into you see it's going to take me

here check all moves and now I can

either continue through the entirety of

this or I can step through line by line

and follow the breadcrumbs as I'm going

and at any point if I go well if it's

working up until this point let me just

continue and it's going to you know you

can see it's continued the execution and

now it's actually waiting for input and

if I move again we're going to hit that

breakpoint again and everything's going

to repeat so these two features step

into and step over can be really helpful

if you have a hunch for roughly where

your error might be but you're not sure

and you want to go through and kind of

audit like okay let me run this one line

check the variables does everything line

up the way it's supposed to be you know

what sometimes you'll find is you're

trying to access something before it

exists and so you step through your code

one line at a time and you go oh this is

undefined I was expecting this to be

defined at this point so let me figure

out why this thing isn't existing at the

moment that I expected it

[Music]

to as you've probably noticed when I'm

testing this I'm not actually seeing my

Collision shapes and sometimes that can

be an issue so here's my Ray Caster

here's all the different triggers more

or less these are area 2DS if I under

debug I can actually turn on visual

Collision shapes and various other

things to give me that feedack back

while I'm also testing so that I can see

oh you know what I thought these two

things were overlapping or they're not

so for example you know now I can see my

raycaster and let's say and actually

it's helping me visualize when that Ray

Caster is see that it turns red because

it's it's colliding with something so

maybe you know if I thought my Ray cter

was long enough and it wasn't uh this

would give me that visual feedback that

oh you know what I just need to make

this a little bit longer for what I'm

using it for okay so you don't have to

completely quit using print but I hope

this gives you a couple extra techniques

for hunting down bugs in your code and

if you'd like some tips for writing

fewer bugs in the first place check out

this video right up here until next time

be kind to yourself and be kind to

others I'll see you in the next

[Music]

video