Video Game Design and Coding · PLECK lesson

PLECK lesson 178 · suggested week 36, day 3

Evaluate design using playtest evidence

Objective. Support design claims without confusing preference and correctness.

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

Comes after VGC-L177.

Choose two design decisions, such as a checkpoint, hint ladder, difficulty option or visual symbol. Compare intended effect with observations from alpha or beta testing. A claim such as “the new hint helped” needs evidence: a tester found the lever after reading it, for example. Discuss one result that did not match your expectation and one remaining limitation. Distinguish correctness tests from player-experience evidence; both matter, but neither proves everything about the game.

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.

Evaluate design using playtest evidence — evidence task

  1. 1. Write a 250-word analysis or equivalent private explanation with two evidence-backed design claims.
  2. 2. Include one counterexample or limitation.

Deliverable. Design-evidence reflection.

Acceptance checks

Understanding question. Can one tester’s preference prove all players will like the game?

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