Video Game Design and Coding · PLECK lesson

PLECK lesson 138 · suggested week 28, day 3

Read an error from the first useful cause

Objective. Distinguish parse, runtime and logic errors.

Godot Engine Standard desktop editor 4.7.2-stable, GDScript (Godot 4), Compatibility renderer. Headless Godot 4.7.2.stable.official.ed1daf0bf passed 106 assertions on the supplied scaffolds, including malformed JSON saves. Audio used the Dummy driver and a synthetic WAV, not a speaker. The visual editor, browser export, and signed-in submission were not tested. The desk still does not run a student's own upload.

About 55 minutes. The due date is chosen by a parent.

Pure functions, boundary cases, error reading and focused repair

Suggested pace: Recall and predict 5 min; Read instruction and scaffold 12 min; Build or design the assigned artifact 25 min; Run acceptance tests 8 min; Explain and checkpoint 5 min.

Materials: Godot Standard 4.7.2 desktop editor (GDScript, Compatibility renderer), Local course folder and prior checkpoint, No paid assets or public account required.

Comes after VGC-L137.

A parse error means the script could not be interpreted; a runtime error occurs while executing; a logic error runs but produces the wrong result. A misspelled variable may be caught before play, a missing $HUD/Score path may fail at runtime, and subtracting twice may silently produce the wrong score. Read the first relevant error and its file/line, then inspect the named context. Fixing a downstream symptom before the initial cause often wastes time. Use a duplicate lab for deliberate faults.

Worked example

A capacity function tested at below-minimum, middle and above-maximum inputs is easier to trust than one demonstrated only at a normal value. Scaffold C-TESTS — A tiny pure-function test harness Setup: Attach to Node TestLab. If using command line, create a separate SceneTree harness rather than running this Node script with --script. Run current TestLab scene in editor; assert reports a failed condition in Debugger. No external test framework or package is needed. ```gdscript extends Node func bounded_score(old_score: int, change: int) -> int: return clampi(old_score + change, 0, 999) func _ready() -> void: assert(bounded_score(10, 2) == 12) assert(bounded_score(0, -3) == 0) assert(bounded_score(998, 9) == 999) print("3 score checks passed") ```

A tiny pure-function test harness

GDScript (Godot 4, not Scratch, Python, JavaScript or C#). Scaffold C-TESTS. Copy starts from this text. The desk does not run it.

Scene and node setup

Attach to Node TestLab. If using command line, create a separate SceneTree harness rather than running this Node script with --script. Run current TestLab scene in editor; assert reports a failed condition in Debugger. No external test framework or package is needed.

extends Node
func bounded_score(old_score: int, change: int) -> int:
    return clampi(old_score + change, 0, 999)
func _ready() -> void:
    assert(bounded_score(10, 2) == 12)
    assert(bounded_score(0, -3) == 0)
    assert(bounded_score(998, 9) == 999)
    print("3 score checks passed")

Checks to run in the editor

Native Godot 4.7.2.stable.official.ed1daf0bf headless compile and representative node-tree/runtime tests passed; see native-qa-results.json. Visual UI, audible output, exports and website submission still need separate checks.

Read an error from the first useful cause — evidence task

  1. 1. Create one safe example of each error category in a duplicate.
  2. 2. Record symptom, diagnostic clue and repair.

Deliverable. Three-category debugging report and clean lab.

Acceptance checks

Understanding question. Is a game that runs without debugger errors necessarily correct?

Include a downloadable project ZIP with project.godot, .tscn, .gd and original asset files when code changes. A private, teacher-accessible download link to that ZIP is equivalent. Screenshots or a playthrough do not replace editable source.

If this is still shaky. Use C-TESTS and one ordinary plus two boundary cases. Keep a known-good snapshot before injecting faults. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

Optional extra. Add a property that should hold for many inputs and test a small finite range. Document one changed parameter, your prediction, and the observed effect; optional, not required for completion.

Name ____________________ Date ____________________