Debugging projects in Godot | Codeco

This may come as a surprise, but not all code works on the first try. (Insert surprisingly copyright-safe yellow electrical rodent here)
Therefore, most integrated development environments (IDEs) include a debugger that allows developers to find and resolve problems during multiple development iterations. The following pseudocode illustrates this:
while developing == true:
code
test
debug
However, there are other issues to consider when developing a game, such as game balance or verifying behavior that may be too fast or too subtle to notice during gameplay.
Think about it. You carefully designed your game’s challenge levels, so you want to make sure it’s up to the challenge. But how do you count enemies in a game when they are moving around and shooting at you?
You may want to check game balance. Are the number of enemies spawning at a given moment what you expected? Did the power-up add to the damage boost you expected?
These are just some of the questions you might want to answer when testing your game. This is where Godot’s debugging tools come in handy, helping you test and verify all of this.
getting Started
The example project is the same as the example project that published the Godot project to the itch.io tutorial. However, in this article, the code has been changed to enhance the gaming experience. Unfortunately, the game crashes during this process, and you’ll need to use debugging tools to figure out the problem. How convenient! :]
You can download the project using Download information Links are at the top and bottom of this article. Please note that this project requires Godot 4.3 or higher to work.
The starting project has the same structure as the previous article, but three files have changed: bomb.gd, enemy ship.gdand Main game.gd.
Now is a good time to download and run the project to see how it works and note how bugs affect the game. The main thing you’ll notice is that while enemy ships can destroy your ships, it’s impossible to destroy them, so it’s debugging time!
Debugging Tools Overview
Godot has a powerful set of debugging tools that you can use to check for logic errors in your code, or performance issues in your graphics, or even to understand how your game uses its processing time.
Although there is a debug The selection is at the top of the screen. This article will focus on the options available through debugger The panels are at the bottom of the screen because these are the tools that collect information while executing the project Run project button.
Debug tool panel
The debugger panel is by default located at the bottom of the screen and can be accessed from debugger Options are located on the right side of the bottom of the window output options. The picture below shows the debugging panel:
At the top of the panel you can see some tabs. From left to right, the tabs are:
- stack trace: Shows the execution stack, context, and its variables, and allows control over how the game executes during a debugging session. You’ll learn more about this tab later in this article.
- mistake: Display error and warning messages during game execution.
- Analyzer: Shows what code is running and how it affects game performance. You’ll learn more about this tab later in this article.
- visual analyzer: Displays a graph showing which code is running and how long it takes to execute. You’ll learn more about this tab later in this article.
- monitor: Charts containing game information such as frames per second (fps), memory usage, scene nodes, etc. The material in the debugging session is saved even after the session ends, so it can be viewed even after execution.
- video memory: Shows the resource list and the amount of video RAM used during execution, as well as the total at the top of the panel.
- Miscellaneous: Monitor and identify control nodes clicked during runtime.
- network analyzer: Contains a list of all nodes communicating through the Godot multiplayer API, and the amount of data each node received or sent during the debugging session.
This article focuses on tabs 1, 2, 3, 4, and 5. Some of them, e.g. network analyzer There won’t be any interesting news, though, as the game doesn’t use the multiplayer API at any time.
Use breakpoints
After playing the game, you should have noticed that the main problem is the impossibility of destroying enemy ships. So, logically, there must be something wrong with the function called when damaging an enemy ship – maybe the ship isn’t taking damage when it should be?
To test whether this is true, check the function that deals damage to the enemy: open projectile.gd and find Injury body Function. The function code is:
func damage_body(body: Node2D) -> void:
# 1
body.take_damage(3)
# 2
create_explosion()
# 3
queue_free()
This code does the following:
- When the bullet collides with an enemy ship, the ship’s health will be reduced by 3 points;
- An explosion occurred at the site of the collision;
- The bullet is erased from memory;
It’s a simple function and its logic seems correct. How could it not work? Wouldn’t it be nice if there was a way to gain more insight into how your code works? This is where breakpoints come in, allowing you to stop code execution and dig deeper to find problems.
breakpoint
When analyzing code, errors may not be obvious just by looking at the code; you may want to view the code as it runs. To do this, you use breakpoints and watches, which work together to assist and verify what your code is doing.
When you define a breakpoint, Godot knows that it will need to execute the project normally up to that point. Afterwards, it stops execution and allows you to control how quickly your code executes, and lets you see which code is executed in case of conditionals or loops.
Now the description should be a bit abstract, but you will find that in practice it is very simple and convenient!