Video Game Design and Coding · PLECK lesson

PLECK lesson 86 · suggested week 18, day 1

Run a structured capstone playtest

Objective. Observe task success without collecting personal data.

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: Paper and pencil or a private text document, Local course folder and prior checkpoint, No paid assets or public account required.

Comes after VGC-L085.

Ask a willing family member to launch the restored candidate, find the goal, use the core mechanic and restart. Use an anonymous tester code and record only task outcomes and observations. If no tester is available, follow the same script yourself after a break and label it self-test. Optional recording needs consent and should exclude faces and personal files. A tester can stop at any time. Keep opinions, observations and proposed fixes in separate columns.

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.

Run a structured capstone playtest — evidence task

  1. 1. Run four scripted tasks and record pass, difficulty or failure.
  2. 2. Note three observations without names or identifying details.

Deliverable. Anonymous midyear playtest report.

Acceptance checks

Understanding question. Why separate an observation from a proposed fix?

Submit readable text or photos/scans of each numbered design page. Audio explanation may supplement a diagram or text, not replace requested artifacts.

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 ____________________