<!-- Generated from applied-computing-au vic/unit3-4/sat/C08-2026/C08-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
# Debugging with Breakpoints in Godot

*Pause your game at any line, look inside, step forward. This is the level 5–6 skill on the C8-1 ladder — and the heart of the fix cycle in your screen recording.*

**Watch:** [Debugging Tips You MUST Know as a Godot Developer](https://www.youtube.com/watch?v=PB6YPnRAyjE) (DevWorm, 5:27 — breakpoints from 03:15), then do **Try this now** below on your own project.

## What a breakpoint does

A breakpoint pauses your running game at a chosen line of code so you can check what values variables have, which lines have run, and whether the code is doing what you expect — instead of guessing.

![Setting a breakpoint in the Godot script editor — the red dot in the gutter](Debugging%20with%20Breakpoints%20in%20Godot/godot_breakpoint.png)

## The workflow

1. **Set** — open your `.gd` script and click in the gutter left of the line number where you want to pause. A red dot appears.
2. **Run** — press F5. The game stops at your breakpoint; an arrow in the gutter marks the line about to run, and the **Debugger** panel opens at the bottom.
3. **Inspect** — open **Locals** in the Debugger: every variable in the current function with its current value.
4. **Step** — move through the code with the controls below, watching Locals after each step.
5. **Fix and re-run** — change the faulty line, run again, watch the test pass.

| Button | Key | What it does | Use when |
|---|---|---|---|
| **Step Over** | F10 | Runs just this line, then moves to the next (skips into functions) | Going line by line |
| **Step Into** | F11 | Follows the call *inside* a function on this line | You suspect the function itself |
| **Continue** | F8 | Keeps running until the next breakpoint | Done inspecting here |

## Check the Locals window (most important)

```gdscript
var sum = 0
sum += 1
```

After stepping over `sum += 1`, Locals shows `sum = 1`. Use it to spot mistakes: is a variable supposed to be `10` but shows `0`? Did a value change when you didn't expect it to? **Check Locals after every Step Over.**

Other tabs earn their keep too: **Stack Frames** shows which function you're in and what called it; **Breakpoints** lists every red dot so you can clear the ones you're done with; **Output** shows your `print()` messages.

## The detective loop

1. Set a breakpoint where you think the problem is.
2. Run — it pauses.
3. Check Locals — do the values match what you expect?
4. Step Over (F10) line by line; Step Into (F11) when a function is the suspect.
5. Ask: *why is this variable not changing? Is this function running at all?*

## Try this now (5 minutes)

1. Open a script in your SAT project.
2. Set a breakpoint on a line inside a function that runs every game (e.g. in `_ready()`).
3. Run the game — it pauses.
4. Look at Locals: what values do you see?
5. Press F10 and watch the values change.

**In your recording:** set a breakpoint inside the failing feature from your testing table, step to the faulty line, narrate what Locals shows, fix it, and re-run to pass — one unbroken take.