Godot Debugging Techniques EVERY Dev Should Know
Summary
TLDRThis 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
🐞 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.
🔍 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.
🛠️ 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.
🎨 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.
Mindmap
Keywords
💡Debugging
💡Print Statements
💡Debugger
💡Breakpoints
💡Scene Manager
💡Remote View
💡Step Into / Step Over
💡Data Packet
💡Visual Collision Shapes
💡Raycaster
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
関連動画をさらに表示
5.0 / 5 (0 votes)