Video Game Design and Coding

Week 18 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 18 — Midyear assessment

## VGC-L086 — Run a structured capstone playtest

**Objective:** Observe task success without collecting personal data.

**Time:** 55 minutes

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

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

### Acceptance checks
- The report identifies the candidate version.
- A self-test is labeled honestly if used.

**Submit:** Anonymous midyear playtest report.

**Question:** Why separate an observation from a proposed fix?

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

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html)

---

## VGC-L087 — Triage and repair the most important defect

**Objective:** Use severity and reproduction to prioritize work.

**Time:** 55 minutes

### Instruction
Triage sorts defects by impact. A crash or impossible goal blocks the game; unreadable instructions may block some players; a slightly uneven decoration is lower priority. Choose the highest-impact reproducible issue and write steps, expected result, actual result and suspected cause. Make one focused repair in a new version, then repeat the exact reproduction and the full minimum checklist. If no real defect appears, inject a reversible fault in a duplicate and show the same process.

### 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-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. Rank at least three issues by impact.
2. Repair one high-impact issue and document focused plus regression tests.

### Acceptance checks
- The original reproduction now passes.
- Previously working minimum features still pass.

**Submit:** Triage table, repaired source and before/after report.

**Question:** Does a dramatic-looking visual issue always outrank a silent state bug?

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

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html)

---

## VGC-L088 — Explain one system from input to output

**Objective:** Demonstrate programming understanding using a concrete trace.

**Time:** 55 minutes

### Instruction
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]
```

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

### Acceptance checks
- Trace names match the submitted source.
- Prediction explains a real state inconsistency rather than only a visual difference.

**Submit:** Annotated trace and private explanation text/audio/video plus unchanged source.

**Question:** What makes an explanation evidence of understanding rather than memorization?

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

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html)

---

## VGC-L089 — Submit the midyear playable capstone

**Objective:** Deliver a complete artifact with accessible evidence.

**Time:** 55 minutes

### Instruction
Submit the final source ZIP or a private HTTPS link to that downloadable ZIP, readme, asset credits, eight-test log, playtest report and one repaired-bug report. Include at least one original design diagram and a short reflection. A video may show the game but must not be the only programming evidence. The teacher rubric evaluates understanding, implementation, design, accessibility, testing and communication separately so decorative polish cannot conceal a nonworking loop. No public upload or account is required.

### 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-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. Restore the final artifact and run all eight acceptance tests.
2. Submit the evidence bundle with a clear final-version name.

### Acceptance checks
- Teacher can open source and locate all evidence.
- The readme honestly states remaining limitations.

**Submit:** Midyear final source artifact and complete assessment bundle.

**Question:** Can a polished playthrough replace a broken or missing project artifact?

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

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html)

---

## VGC-L090 — Reflect and choose the next skill

**Objective:** Use evidence to set a specific programming growth goal.

**Time:** 55 minutes

### Instruction
Reflection is a claim supported by evidence, not a list of compliments or apologies. Identify one design choice that improved task success, one code decision that simplified maintenance and one unresolved limitation. Cite the test or artifact supporting each. Then choose a next skill such as safer saves, clearer audio feedback or enemy state logic. Write a small measurable goal you could demonstrate in a later project. Keep the finished midyear version backed up before beginning new experiments.

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

### Assignment
1. Write a 200-word or two-minute private reflection with three evidence references.
2. Set one measurable next-skill goal and verify the final backup.

### Acceptance checks
- Each claim points to a specific artifact or observation.
- The growth goal describes an observable outcome.

**Submit:** Midyear reflection and next-skill goal.

**Question:** What makes “get better at coding” too vague as a growth goal?

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

**Optional free reading:** [Your first 2D game](https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html)

---