Video Game Design and Coding · PLECK lesson

PLECK lesson 88 · suggested week 18, day 3

Explain one system from input to output

Objective. Demonstrate programming understanding using a concrete trace.

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.

Consent-based playtesting, repairs, evidence and reflection

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

Choose a real event in your capstone and trace it through input or collision, handler, validation, state change and visible feedback. Name actual functions and variables from your project. Predict what changes if a guard is removed, but test the fault only in a duplicate. Explain why your design uses a manager, signal, helper function or data dictionary. A fluent explanation need not use advanced vocabulary; it must match the code the teacher can inspect.

Worked example

A report states candidate version, setup, action, expected result and actual result. A repair is verified by replaying exactly those steps, then checking neighboring features. Scaffold C-STATES — Explicit game states and gated scoring Setup: Attach to Node root StateLab with child Label Status. This is a standalone demonstrator; call start_round, add_points, finish_round from buttons or Remote Inspector. In a real game the manager owns this state. Additional Player and spawner scripts must also honor the manager’s state, or be disabled when finishing. ```gdscript extends Node enum Phase { TITLE, PLAY, WIN, LOSE } var phase: Phase = Phase.TITLE var score: int = 0 func _ready() -> void: _show() func start_round() -> void: score = 0 phase = Phase.PLAY _show() func add_points(amount: int) -> void: if phase != Phase.PLAY: return score += maxi(amount, 0) _show() func finish_round(won: bool) -> void: if phase != Phase.PLAY: return phase = Phase.WIN if won else Phase.LOSE _show() func _show() -> void: $Status.text = "State: %s | Score: %d" % [Phase.keys()[phase], score] ```

Explicit game states and gated scoring

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

Scene and node setup

Attach to Node root StateLab with child Label Status. This is a standalone demonstrator; call start_round, add_points, finish_round from buttons or Remote Inspector. In a real game the manager owns this state. Additional Player and spawner scripts must also honor the manager’s state, or be disabled when finishing.

extends Node
enum Phase { TITLE, PLAY, WIN, LOSE }
var phase: Phase = Phase.TITLE
var score: int = 0
func _ready() -> void:
    _show()
func start_round() -> void:
    score = 0
    phase = Phase.PLAY
    _show()
func add_points(amount: int) -> void:
    if phase != Phase.PLAY:
        return
    score += maxi(amount, 0)
    _show()
func finish_round(won: bool) -> void:
    if phase != Phase.PLAY:
        return
    phase = Phase.WIN if won else Phase.LOSE
    _show()
func _show() -> void:
    $Status.text = "State: %s | Score: %d" % [Phase.keys()[phase], score]

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.

Explain one system from input to output — evidence task

  1. 1. Create a five-step event trace with code locations.
  2. 2. Predict one guard-removal bug and compare in a duplicate.

Deliverable. Annotated trace and private explanation text/audio/video plus unchanged source.

Acceptance checks

Understanding question. What makes an explanation evidence of understanding rather than memorization?

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. Prioritize crashes, blocked completion and misleading controls before cosmetic feedback. Retest the original reproduction after each fix. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

Optional extra. Explain one alternative implementation and why you chose the current one. Document one changed parameter, your prediction, and the observed effect; optional, not required for completion.

Name ____________________ Date ____________________