Week 11 — Nov 3 — Screen Layout (critique)

Milestone: Screen Layout (5 pts) is due and critiqued live — title, HUD, pause, win, and lose screens implemented. No new exercise.

Fed by: Ex 7 Screen Flow (Wk 10). This is the most direct exercise-to-milestone handoff of the semester: the deliverable is the same five screens at full polish rather than a new build.

Lecture topics, expanded

Menu and pause flow. Time.timeScale = 0 pauses physics and most gameplay, but not UI or audio unless students specifically account for it — a common bug is a pause menu that itself freezes because a script reads Time.deltaTime for its own animation. The fix (use Time.unscaledDeltaTime for UI-driven timing) is a good five-minute aside.

GameStateManager-driven scene flow. Revisiting the helper library's GameStateManager from Ex 3, now carrying real weight: Playing → Paused → Won/Lost → Restart is a genuine state machine, and every screen from UIManager should be a direct function of the current state rather than toggled ad hoc from wherever a script happens to detect a win or loss.

Save/load and PlayerPrefs. PlayerPrefs is the lightweight option for what this course actually needs — a high score, a last-selected level, an options setting — not a full save-game system. The teaching point is scope discipline: most student games don't need JSON serialization or a save file at all, and reaching for PlayerPrefs.SetInt/GetInt first prevents a lot of wasted engineering time this late in the semester.

Connecting it to the critique

The rubric question today is whether the five screens actually gate one another correctly — can the player reach Win from Lose without a restart, does Pause block input to the HUD behind it, does Restart genuinely reset state rather than just reloading visuals. A screen that displays correctly but doesn't block or route input properly is the equivalent of Week 5's "unwired UnityEvent": it looks right until someone actually plays through it.