How specifically should I choose between print() and print_debug()?

While print() is convenient for simple value checks early in development, use print_debug() as a rule. It basically only outputs in debug builds, so unnecessary logs are less likely to remain in production. However, behavior may vary depending on build settings, so for logs that absolutely must not appear in production, explicitly guard with `if OS.is_debug_build():`.

Why do breakpoints sometimes not work?

Several causes are possible. Most commonly, the code isn't actually being executed—for example, an if condition isn't met, or a signal isn't connected. Also, the editor and running game may not be properly connected. Try restarting the Godot editor in that case.

What's the most efficient way to identify what's making my game slow?

Using the debugger's 'Profiler' tab is the standard approach. Processing time and call count for each function are measured in milliseconds, allowing you to accurately identify bottleneck processes. Especially check for heavy processing in _process or _physics_process.

How do I change node properties in real-time in a running game?

Select the 'Remote' tab in the debugger panel and select the target node from the scene tree. The inspector will show that node's current properties, which you can freely modify. Very powerful for UI fine-tuning and physics parameter testing.

【Godot】Debugging Techniques and print_debug - Efficient Bug Fixing in Godot Engine

Introduction: Why Debugging Techniques Are Key to Game Development

In game development, bugs are unavoidable. Identifying and fixing causes of player actions producing unintended results or game crashes—debugging—significantly affects development process quality and efficiency.

Many beginners tend to rely on the print() function as the most convenient debugging method. However, as projects scale up, this approach quickly reaches its limits.

Log Flood: The console gets buried in massive logs, losing truly important information.
Extensive Rework: Needing to delete massive print() statements after debugging, with constant risk of forgetting some.
Performance Concerns: print() statements remaining in release builds slightly impact performance.

This article explains concrete methods to more efficiently fix bugs by strategically utilizing Godot Engine's built-in powerful debugging tools, especially the print_debug() function.

Choosing Between Log Outputs: `print` vs `print_debug` vs `push_error`

Godot has several ways to output messages, each with appropriate roles. Using these correctly is the first step to clean debugging.

Function	Debug Execution	Release Build	Primary Use
`print()`	Output	Output	Very temporary testing during development. Should not remain in production code.
`print_debug()`	Output	Usually not output*	Temporary information checking during development/testing.
`push_warning()`	Output as warning	Usually not output*	Non-fatal but unexpected states or deprecated usage.
`push_error()`	Output as error	Usually not output*	Notifying clear error states where program continuation becomes difficult.

*Behavior may vary depending on build settings and execution environment. For logs that absolutely must not appear in production, explicitly guard with if OS.is_debug_build():.

Since print_debug() basically only outputs in debug builds, developers can more easily embed debug information in code. Furthermore, using push_warning() or push_error() records output in the debugger's "Errors" tab with traceable stack traces, making it easier to identify problem sources.

func load_level(level_id: int):
    if level_id < 0:
        # Warn about unexpected value
        push_warning("Invalid level ID passed: %d" % level_id)
        return

    print_debug("Starting load of level %d." % level_id)
    # ... loading process

Mastering the Godot Debugger: Examining Code "Live"

The Godot debugger isn't just a log viewer. It provides powerful tools for pausing game execution and investigating internal state in detail.

1. Breakpoints and Step Execution

Breakpoints are the most fundamental yet powerful debugging feature. Simply clicking to the left of line numbers in the script editor causes game execution to stop exactly when that line is reached.

With execution paused, the following operations are possible:

Step Over (F10): Execute the current line and proceed to the next. If there's a function call, you don't enter that function's internals.
Step In (F11): Execute the current line. If there's a function call, you enter that function's internals.
Step Out (Shift+F11): Execute the current function to the end and return to the next line after the caller.
Variable Watch (Variables): In the "Debugger" panel at bottom-left, you can check values of all variables in current scope. No more writing countless print() statements.

2. Remote Inspector: Manipulating Running Scenes in Real-Time

The debugger panel's "Remote" tab displays the running game's scene tree as-is. This enables operations like:

Live Property Editing: Select a node and modify properties (position, color, custom variables, etc.) in real-time through the inspector. Perfect for UI fine-tuning or immediately seeing physics parameter change results.
Dynamic Node Creation/Deletion: Add or delete nodes in the scene tree to test their effects.

3. Profiler and Monitor: Identifying Performance Bottlenecks

When games are slow or frame rates unstable, the "Profiler" comes into play. Start the profiler and run the game to measure execution time and call count for each function in milliseconds. This makes "which process is heaviest" immediately clear, allowing precise targeting for optimization.

The "Monitor" tab also provides real-time graphs of FPS, memory usage, object count in scene, etc., helpful for understanding the overall performance picture.

Practical Code Examples: assert and Custom Visual Debugging

Beyond print and the debugger, let's look at more advanced techniques.

Contract-Based Debugging with `assert`

The assert statement describes program "contracts"—"this condition must absolutely be true." When the condition becomes false during debug execution, the program stops immediately and reports an error. This helps find bugs earlier, closer to the cause.

# Function that manipulates player HP
func set_health(new_health: int):
    # Contract that HP must absolutely be 0 or greater
    assert(new_health >= 0, "Attempted to set negative HP value: %d" % new_health)

    health = new_health
    print_debug("Player HP updated to %d." % health)

This code immediately stops with an error during debug execution if new_health receives a negative value. In release builds, assert statements are ignored, so there's no performance impact.

Custom Visual Debugging with `_draw`

Enemy AI detection ranges, navigation paths, physics force vectors—these are hard to understand intuitively when logged as numbers. Using the _draw() function, you can draw debug information directly on the game screen.

# Enemy character script
extends CharacterBody2D

@export var vision_radius: float = 200.0
var can_see_player: bool = false

# Flag to enable debug drawing
@export var enable_debug_draw: bool = true

func _process(delta):
    var new_can_see = check_player_visibility()
    # Request redraw only when state changes
    if new_can_see != can_see_player:
        can_see_player = new_can_see
        queue_redraw()  # Required to call _draw() again

func check_player_visibility() -> bool:
    # Logic for checking if seeing player...
    return false

func _draw():
    if not enable_debug_draw:
        return

    # Draw detection range as circle
    var circle_color = Color.RED if can_see_player else Color.GREEN
    draw_circle(Vector2.ZERO, vision_radius, circle_color.lighten(0.5))

Important: The _draw() function isn't automatically called every frame. To update drawing content, you need to call queue_redraw() to request a redraw.

Nodes with this script attached draw their detection range as a circle on screen while enable_debug_draw is true. Color changes based on whether the player is recognized, making AI behavior immediately clear.

Common Mistakes and Best Practices

For efficient debugging, it's important to avoid common anti-patterns and habituate best practices.

Common Mistake	Best Practice
Using `print()` for everything.	Use breakpoints for complex logic tracking and `print_debug()` for state transition checking—differentiate usage.
Commenting out `print()` statements after debugging.	Using `print_debug()` automatically disables in release builds, so commenting out is unnecessary.
Optimizing performance by intuition.	Use the profiler to identify bottlenecks based on objective data before starting optimization.
Chasing physics bugs with only `print()`.	Enable "Visible Collision Shapes" in the Debug menu to visually confirm collision detection.
Adjusting UI positions through repeated code changes and re-execution.	Use the remote inspector to directly adjust `position` and `size` properties during execution and see results.

Summary: Establishing an Efficient Debugging Flow

Efficient debugging in Godot Engine starts by moving beyond just using print() and combining the following tools and techniques.

Leverage the Godot Debugger: For complex bugs and logic tracking, actively use breakpoints, step execution, and the remote inspector—develop the habit of "peeking into" code's internal state.
Strategic Use of print_debug(): For state tracking and temporary value checking during development, use print_debug() which doesn't affect release builds, maintaining a clean codebase.
Optimization via Profiler: When performance issues arise, use the profiler to identify bottlenecks and narrow down debugging scope.

By mastering these techniques, you can significantly reduce bug-fixing time and spend more time on the creative aspects of your game.

Menu