Video Game Design and Coding · PLECK lesson

PLECK lesson 105 · suggested week 21, day 5

Release an accessibility revision privately

Objective. Compare a revised artifact against the earlier baseline.

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.

Text, focus, motion, privacy and evidence-based claims

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

Create a separate accessibility edition of the midyear game. Keep the baseline for comparison. Run the original eight minimum tests plus keyboard, muted, non-color, reduced-motion and text-layout checks appropriate to your design. Report improvements with evidence and list unresolved barriers. Packaging is private: submit source and a readme to the teacher, not a public social account. A private playthrough may demonstrate changes but the source artifact remains necessary.

Worked example

A barrier audit might test whether Tab can reach Restart. The result is a specific supported capability, not a claim that every assistive technology is supported. 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.

Release an accessibility revision privately — evidence task

  1. 1. Package the revised source and a before/after barrier table.
  2. 2. Restore and run core plus accessibility regression checks.

Deliverable. Accessibility-edition source artifact and comparison report.

Acceptance checks

Understanding question. Can an accessibility fix create a regression?

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. Test one barrier at a time: keyboard only, muted audio, reduced motion and enlarged text. Keep a checklist of actual results. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

Optional extra. Let a willing tester choose a comfort setting before the test without asking why they need it. Document one changed parameter, your prediction, and the observed effect; optional, not required for completion.

Name ____________________ Date ____________________