Week 16 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 16 — Midyear proposal and vertical slice
## VGC-L076 — Pitch a one-room remix
**Objective:** Define an original, achievable midyear capstone.
**Time:** 55 minutes
### Instruction
Choose collector, avoidance, narrative puzzle or platformer as a base, then make an original one-room game with a different theme and one meaningful rule change. A remix may reuse your own movement code, but it should not merely rename a tutorial. Limit required features to one core action, one obstacle or condition, visible progress, a win state and restart. Write who the game is for without collecting personal data. Separate must-have features from optional polish so the project can finish.
### Worked example
A minimum one-room collector can be described by one action, one obstacle, visible progress, one ending and restart. Extra rooms are optional until that loop works.
### Assignment
1. Write a 150-to-250-word pitch and must/optional feature list.
2. Describe the one original rule change and how the player discovers it.
### Acceptance checks
- The minimum can be played in two to five minutes.
- No feature requires a new paid tool or public account.
**Submit:** Midyear proposal and scope list.
**Question:** Why is a smaller finished loop preferable to five unfinished genres?
**Support:** Choose one earlier genre and one room. Keep one player action, one obstacle type and one goal until the loop works. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.
**Optional extension:** Propose an optional mechanic but do not build it before the minimum tests pass. 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-L077 — Write acceptance before implementation
**Objective:** Translate a design promise into observable tests.
**Time:** 55 minutes
### Instruction
An acceptance test describes setup, action and expected result. “Game works” is not testable enough. For a collector, a good test is “from a fresh round, collect the third item; completion appears once and movement stops.” Write tests for launch, core action, obstacle, progress, ending, restart and one accessibility feature. Include one boundary case such as a repeated goal event or insufficient inventory. These tests become the contract for your minimum game and keep optional ideas from moving the finish line.
### Worked example
A minimum one-room collector can be described by one action, one obstacle, visible progress, one ending and restart. Extra rooms are optional until that loop works.
### Assignment
1. Write seven minimum acceptance tests and one boundary test.
2. Mark which artifact or log will demonstrate each.
### Acceptance checks
- Every test names an observable result.
- At least one test checks a failure or repeated-event condition.
**Submit:** Eight-test capstone contract.
**Question:** What is missing from “the player can collect items” as a full test?
**Support:** Choose one earlier genre and one room. Keep one player action, one obstacle type and one goal until the loop works. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.
**Optional extension:** Propose an optional mechanic but do not build it before the minimum tests pass. 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-L078 — Plan ownership and signal flow
**Objective:** Choose one owner for each important piece of state.
**Time:** 55 minutes
### Instruction
Draw the node tree before writing the manager. Assign ownership: Player handles motion, pickup or hazard detects local contact, Manager owns round state, and HUD displays manager values. Arrows show signals from local objects to the manager and commands from the manager to views or actors. Avoid every node directly modifying every other node. A clear architecture reduces accidental double scoring and makes explanations easier. List the exact node names needed by any $ paths, then keep them consistent.
### Worked example
A minimum one-room collector can be described by one action, one obstacle, visible progress, one ending and restart. Extra rooms are optional until that loop works.
### Assignment
1. Draw the node tree and a state-owner table.
2. Trace one event from player action through state update to HUD.
### Acceptance checks
- Each state variable has one owner.
- The event trace does not depend on reading HUD text as game state.
**Submit:** Architecture diagram and state-owner table.
**Question:** Why is one owner per state variable useful?
**Support:** Choose one earlier genre and one room. Keep one player action, one obstacle type and one goal until the loop works. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.
**Optional extension:** Propose an optional mechanic but do not build it before the minimum tests pass. 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-L079 — Build the smallest playable slice
**Objective:** Integrate input, one challenge and a visible outcome.
**Time:** 55 minutes
### Instruction
A vertical slice is a thin but complete path through the game: launch, act, encounter one challenge, see progress and reach an ending. It is not a polished menu with no gameplay. Start from a copy of your own earlier project or a clean project with the relevant recipes. Replace theme text and layout with original work. Use placeholder shapes. Save a checkpoint once the first slice runs; do not overwrite the only working version while adding features.
### Worked example
A minimum one-room collector can be described by one action, one obstacle, visible progress, one ending and restart. Extra rooms are optional until that loop works.
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]
```
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. Build one playable route through the minimum loop.
2. Run the first four acceptance tests and record actual results.
### Acceptance checks
- Input, challenge and feedback work together in one scene.
- A named working backup exists.
**Submit:** Midyear vertical-slice source and first test results.
**Question:** Why call it vertical rather than a list of disconnected systems?
**Support:** Choose one earlier genre and one room. Keep one player action, one obstacle type and one goal until the loop works. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.
**Optional extension:** Propose an optional mechanic but do not build it before the minimum tests pass. 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-L080 — Review scope using evidence
**Objective:** Adjust the plan before expanding the implementation.
**Time:** 55 minutes
### Instruction
Review the slice against your eight-test contract. Mark pass, fail or not yet implemented for each test. A failed minimum requirement takes priority over optional particles, extra levels or online features. If the project is too large, reduce content while preserving the stated learning goals and a complete loop. Record the scope decision rather than quietly deleting tests to claim success. A parent may approve a reduced minimum; the final readme must describe the actual game honestly.
### Worked example
A minimum one-room collector can be described by one action, one obstacle, visible progress, one ending and restart. Extra rooms are optional until that loop works.
### Assignment
1. Complete the eight-test status table.
2. Choose the next three tasks in dependency order and identify one feature to defer.
### Acceptance checks
- No failed test is marked pass without evidence.
- The next tasks address minimum functionality before optional polish.
**Submit:** Scope review and three-task build plan.
**Question:** When is changing an acceptance criterion legitimate?
**Support:** Choose one earlier genre and one room. Keep one player action, one obstacle type and one goal until the loop works. Start with the first assigned task and re-run its acceptance test before adding the remaining feature.
**Optional extension:** Propose an optional mechanic but do not build it before the minimum tests pass. 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)
---