Week 10 — Oct 27 — Ex 7: Screen Flow

Exercise: Ex 7 — Screen Flow. Title → game → pause → win/lose screens, built in UI Toolkit.

Feeds: directly into the Screen Layout milestone next week (Wk 11) — the same exercise-then-milestone pairing as Ex 5 → Level Map.

Lecture topics, expanded

UI Toolkit — UXML and USS. The engine's retained-mode UI system: UXML defines structure (buttons, labels, containers) the way HTML defines a page, USS styles it the way CSS does. The mental model shift for students coming from OnGUI-style thinking is that UI is now a document you style once, not something drawn imperatively every frame.

UIManager screen switching. The helper library's UIManager handles showing/hiding whole screens (title, HUD, pause, win, lose) as a state machine of visibility, so only one screen panel is ever active at a time. Students wire it once here and reuse it for every screen state through the rest of the project — this is this exercise's version of Ex 2's "the player prefab everyone builds on."

Binding buttons and events to game state. A Play button needs to actually start the game (GameStateManager.StartGame or equivalent), not just hide the title screen — the common failure is a UI that looks functional in isolation but doesn't talk to game state at all. This is where the semester's UnityEvent/C# event pattern (first seen with TriggerZone in Ex 3) extends naturally to UI: a button's OnClick is just another event source.

Connecting it to the milestone

Screen Layout asks for title, HUD, pause, win, and lose screens implemented — which is Ex 7 verbatim, at full scope instead of exercise scope. A student who wires all five states cleanly this week is largely done with next week's milestone already; a student who only gets title-and-HUD working should be told explicitly today that pause/win/lose are not optional extras for Wk 11, they're the other 60% of the grade.