Video Game Design and Coding

Week 36 packet

Student instructions, tasks, and checks. The answer key is not in this packet. Links stay as text. This page does not embed a clip or run a file.

# Week 36 — Final demonstration and reflection

## VGC-L176 — Prepare a concise playable demonstration

**Objective:** Show the game’s loop and richer system with source evidence.

**Time:** 55 minutes

### Instruction
Plan a three-to-five-minute demonstration that introduces the goal, shows the core action, demonstrates the richer system, reaches an ending and restarts. Use a local live demo or private recording without a face or personal desktop information. Keep the source artifact open or linked for teacher inspection. A demo should show actual behavior, not a sequence of mockup slides. Include one limitation honestly. If recording is inaccessible, a written walkthrough with screenshots and test references is equivalent.

### 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")
```

### Assignment
1. Create a five-step demo plan and rehearse it.
2. Capture or present the actual loop and one richer-system behavior.

### Acceptance checks
- The demonstration corresponds to the final artifact version.
- Programming source remains available independently of the demo.

**Submit:** Demo plan and live/private recording or written walkthrough with screenshots.

**Question:** Why identify the artifact version during a demonstration?

**Support:** 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 extension:** 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.

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html), [Exporting for the Web](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html)

---

## VGC-L177 — Defend the code with predictions

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

**Time:** 55 minutes

### Instruction
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")
```

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

### Acceptance checks
- Function names match the artifact.
- Prediction is compared with the actual result and explained.

**Submit:** Code-defense text/private audio/video plus annotated source excerpt.

**Question:** What is a useful answer when the observed result contradicts your prediction?

**Support:** 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 extension:** 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.

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html), [Exporting for the Web](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html)

---

## VGC-L178 — Evaluate design using playtest evidence

**Objective:** Support design claims without confusing preference and correctness.

**Time:** 55 minutes

### Instruction
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.

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

### Acceptance checks
- Claims cite specific tests or observations.
- Preferences are not presented as universal facts.

**Submit:** Design-evidence reflection.

**Question:** Can one tester’s preference prove all players will like the game?

**Support:** 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 extension:** 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.

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html), [Exporting for the Web](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html)

---

## VGC-L179 — Assemble a private portfolio and self-assessment

**Objective:** Select artifacts that demonstrate growth across the course.

**Time:** 55 minutes

### Instruction
Choose three milestones: an early lab or Pocket Orchard, the midyear capstone and the final game. For each, include a screenshot or diagram, source artifact reference, one code concept and one test you learned to use. Complete the teacher rubric as a self-assessment with evidence rather than only numbers. This portfolio can remain entirely private in the school assignment system or a local folder. Do not publish a child’s work or personal identity to satisfy the course.

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

### Assignment
1. Assemble three milestone entries and an evidence-based self-assessment.
2. Verify all artifact references point to recoverable local/private files.

### Acceptance checks
- Each milestone demonstrates a different stage of growth.
- Portfolio contains no required public profile or personal data.

**Submit:** Private three-entry portfolio and rubric self-assessment.

**Question:** Why include an early imperfect project in a portfolio?

**Support:** 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 extension:** 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.

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html), [Exporting for the Web](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html)

---

## VGC-L180 — Submit and plan a responsible next step

**Objective:** Close the course with a complete artifact and realistic learning plan.

**Time:** 55 minutes

### Instruction
Submit the final source artifact, readme, credits, twelve-test contract/results, richer-system evidence, playtest/repair reports, demo and reflection. Keep a restore-tested local backup. Choose one future skill, such as more advanced level design, navigation or deeper GDScript data structures, and define a small experiment with a pass condition. Do not modify the frozen final artifact to begin that experiment. Completion here records evidence of learning; the parent/teacher determines evaluation without an automatic credit or accreditation claim.

### 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")
```

### Assignment
1. Submit the final evidence checklist and confirm backup restoration.
2. Write one next-step experiment with objective, materials, risk and measurable result.

### Acceptance checks
- All required artifacts are present or honestly flagged missing.
- Future work is separate from the assessed final version.

**Submit:** Final capstone evidence bundle, backup confirmation and next-step plan.

**Question:** What should you do before experimenting beyond the final release?

**Support:** 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 extension:** 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.

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html), [Exporting for the Web](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html)

---