Video Game Design and Coding

Week 34 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 34 — Beta evidence and repairs

## VGC-L166 — Prepare a privacy-respecting beta test

**Objective:** Write a short task script and consent statement.

**Time:** 55 minutes

### Instruction
A beta test asks whether a near-complete game works for someone outside its development process. Write a brief explanation of purpose, duration, voluntary participation and the ability to stop. Use anonymous tester codes and do not ask age, school, location or diagnosis. Tasks should cover finding controls, performing the core action, reaching a milestone, using a comfort setting and restarting. Optional recording requires separate consent; written notes are sufficient and preferred when privacy is uncertain.

### Worked example
A neutral beta task asks the player to find and use a comfort setting. Notes record what they tried before proposing an interface repair.

### Assignment
1. Write a five-task beta script and short consent statement.
2. Prepare an anonymous results sheet tied to the candidate version.

### Acceptance checks
- Tasks do not coach exact solutions.
- No identifying data or public posting is required.

**Submit:** Beta test script and anonymous results form.

**Question:** Why ask consent separately for recording?

**Support:** Test locally with an anonymous script. If no tester is available, label a structured self-test and follow the same tasks. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

**Optional extension:** Ask for one optional qualitative preference only after task observations are recorded. 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-L167 — Observe beta play without leading the player

**Objective:** Collect task outcomes and concrete usability evidence.

**Time:** 55 minutes

### Instruction
Run the test locally with a willing family member or conduct a labeled self-test after a break. Record completed, difficult or failed for each task and note observable actions. Ask neutral questions such as “What did you expect?” rather than “Was that button confusing?” Let the player stop. Do not upload recordings publicly. Capture the candidate version, but not the tester’s real identity. A test can be useful even when it reveals that your favorite feature is hard to understand.

### Worked example
A neutral beta task asks the player to find and use a comfort setting. Notes record what they tried before proposing an interface repair.

### Assignment
1. Conduct the five-task beta test.
2. Record at least five observations and separate interpretation from fact.

### Acceptance checks
- Each task has an actual outcome.
- Notes remain anonymous and tied to a version.

**Submit:** Beta observation report.

**Question:** Why is “What did you expect?” less leading than “Was that bad?”

**Support:** Test locally with an anonymous script. If no tester is available, label a structured self-test and follow the same tasks. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

**Optional extension:** Ask for one optional qualitative preference only after task observations are recorded. 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-L168 — Rank beta findings by impact

**Objective:** Distinguish blockers, barriers and preferences.

**Time:** 55 minutes

### Instruction
Classify each finding as crash/data risk, blocked goal, major usability barrier, minor defect or preference. Frequency and severity both matter. One reproducible data-loss bug may outrank several cosmetic complaints. A preference is not automatically a defect, but repeated confusion can justify a design change. Select three repairs in priority order and define a verification test for each. Keep suggestions that exceed scope on the future list rather than rebuilding the entire game at release time.

### Worked example
A neutral beta task asks the player to find and use a comfort setting. Notes record what they tried before proposing an interface repair.

### Assignment
1. Classify all beta findings and choose three repairs.
2. Write a verification test and regression area for each.

### Acceptance checks
- Priorities cite impact and evidence.
- Each repair has a measurable completion condition.

**Submit:** Beta triage table and three-repair plan.

**Question:** Should every tester suggestion become a feature?

**Support:** Test locally with an anonymous script. If no tester is available, label a structured self-test and follow the same tasks. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

**Optional extension:** Ask for one optional qualitative preference only after task observations are recorded. 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-L169 — Repair focused defects and prove the change

**Objective:** Use small edits and before/after reproductions.

**Time:** 55 minutes

### Instruction
Implement the highest-priority feasible repairs one at a time in a new candidate. Save a checkpoint after each focused fix. Repeat the original reproduction and then test adjacent systems. If a save defect is repaired, test both valid and invalid data; if a layout defect is repaired, test the longest passage and keyboard focus; if a collision defect is repaired, test neighboring edges and checkpoint safety. Do not combine an unrelated new mechanic with the repair.

### Worked example
A neutral beta task asks the player to find and use a comfort setting. Notes record what they tried before proposing an interface repair.

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. Implement up to three prioritized repairs.
2. Record before/after evidence and adjacent regression results for each.

### Acceptance checks
- Each claimed repair passes its original reproduction.
- No required neighboring feature regresses.

**Submit:** Beta-repaired source artifact and repair log.

**Question:** Why test adjacent systems after a focused fix?

**Support:** Test locally with an anonymous script. If no tester is available, label a structured self-test and follow the same tasks. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

**Optional extension:** Ask for one optional qualitative preference only after task observations are recorded. 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-L170 — Create release candidate one

**Objective:** Freeze a complete build for final acceptance.

**Time:** 55 minutes

### Instruction
Name the repaired build rc1 and package a source ZIP, readme, credits and test suite. Run the twelve required tests and all fixed-bug reproductions from a restored copy. Any blocker returns the build to repair; minor remaining issues must be disclosed. A release candidate is a stable artifact, not a promise of perfection. Do not publish it or ask the student to create a hosting account. Local teacher testing is sufficient for the course.

### Worked example
A neutral beta task asks the player to find and use a comfort setting. Notes record what they tried before proposing an interface repair.

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. Package rc1 and run final minimum plus repair tests.
2. Write a known-issues list with severity.

### Acceptance checks
- No undisclosed blocker is claimed as passing.
- The candidate is reproducible from the submitted source.

**Submit:** RC1 source artifact, acceptance log and known issues.

**Question:** What makes rc1 useful even if it still has a minor defect?

**Support:** Test locally with an anonymous script. If no tester is available, label a structured self-test and follow the same tasks. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.

**Optional extension:** Ask for one optional qualitative preference only after task observations are recorded. 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)

---