Home A - Z
Page Index

An Otter Wiki

Blame

50ea2e lisa 2026-08-16 22:03:23
sd: add C08 reference (debugging & alpha testing) — 9 pages ported from C08-Reference-Godot; hub link Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 
<!-- 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. -->
2
# Debugging with Breakpoints in Godot
3
4
*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.*
5
6
**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.
7
8
## What a breakpoint does
9
10
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.
11
12
![Setting a breakpoint in the Godot script editor — the red dot in the gutter](Debugging%20with%20Breakpoints%20in%20Godot/godot_breakpoint.png)
13
14
## The workflow
15
16
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.
17
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.
18
3. **Inspect** — open **Locals** in the Debugger: every variable in the current function with its current value.
19
4. **Step** — move through the code with the controls below, watching Locals after each step.
20
5. **Fix and re-run** — change the faulty line, run again, watch the test pass.
21
22
| Button | Key | What it does | Use when |
23
|---|---|---|---|
24
| **Step Over** | F10 | Runs just this line, then moves to the next (skips into functions) | Going line by line |
25
| **Step Into** | F11 | Follows the call *inside* a function on this line | You suspect the function itself |
26
| **Continue** | F8 | Keeps running until the next breakpoint | Done inspecting here |
27
28
## Check the Locals window (most important)
29
30
```gdscript
31
var sum = 0
32
sum += 1
33
```
34
35
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.**
36
37
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.
38
39
## The detective loop
40
41
1. Set a breakpoint where you think the problem is.
42
2. Run — it pauses.
43
3. Check Locals — do the values match what you expect?
44
4. Step Over (F10) line by line; Step Into (F11) when a function is the suspect.
45
5. Ask: *why is this variable not changing? Is this function running at all?*
46
47
## Try this now (5 minutes)
48
49
1. Open a script in your SAT project.
50
2. Set a breakpoint on a line inside a function that runs every game (e.g. in `_ready()`).
51
3. Run the game — it pauses.
52
4. Look at Locals: what values do you see?
53
5. Press F10 and watch the values change.
54
55
**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.