Video Game Design and Coding · PLECK lesson

PLECK lesson 177 · suggested week 36, day 2

Defend the code with predictions

Objective. Explain a real event, guard and boundary case.

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.

Code defense, design evidence, portfolio and future learning

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-L176.

Choose one event in your final game and trace actual function names from input or contact through validation, state mutation and feedback. Predict one boundary case before running it: repeated pickup, insufficient resource, malformed save, chase threshold or regenerated route. Explain why the guard or validator exists. You may refer to notes and source; this is not a memorization contest. The teacher should ask a follow-up about a small change and listen for reasoning tied to the code.

Worked example

A final explanation predicts a changed input, runs it and compares results. An unexpected result becomes a debugging opportunity rather than something to conceal. 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.

Defend the code with predictions — evidence task

  1. 1. Submit an annotated event trace and a prediction/observation boundary test.
  2. 2. Explain one alternative implementation and its tradeoff.

Deliverable. Code-defense text/private audio/video plus annotated source excerpt.

Acceptance checks

Understanding question. What is a useful answer when the observed result contradicts your prediction?

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 the submitted source, not memory alone. Choose one event and one boundary test you can explain clearly. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

Optional extra. Propose a future feature with explicit tests and risks, without implementing it into the frozen final artifact. Document one changed parameter, your prediction, and the observed effect; optional, not required for completion.

Name ____________________ Date ____________________