Milestone 4 — Screen Layout
GAME 1303 · Week 11 — Tuesday, November 3 · Implemented screens, demoed in class · 5 points
The deliverable
Your game's complete screen flow, implemented and navigable:
Title → Game → Pause → Win → Lose → back to Title
Not mockups. Working screens, in the build, that you can move between with a controller or keyboard while someone watches.
This is the milestone that turns a prototype into something that reads as a game. A build that opens straight into gameplay and has no way out is a demo; a build with a title screen and a lose state is a game.
Required screens
| Screen | Must contain | Must do |
|---|---|---|
| Title | Game title, Start, Quit | Start enters the game |
| HUD | Live game state — health, score, timer, moves, whatever your game tracks | Updates as the game runs, bound to real values |
| Pause | Resume, Restart, Quit to title | Actually freezes the game; resume returns to the same state |
| Win | Confirmation of winning, and a route onward | Restart or return to title |
| Lose | Confirmation of losing, and a route onward | Restart or return to title |
Both directions. Every screen you can enter, you can leave. Getting stuck on a menu is the single most common failure here.
Feeding exercise: Ex 7 — Screen Flow (Wk 10), where you build this structure with UIManager on a starter scene. This milestone applies it to your own game.
Technical requirements
Section 001 — Unity 6.x: UI Toolkit — UXML documents and USS stylesheets, driven by UIManager. Not legacy uGUI Canvas. The starter GameUI.uxml and GameUI.uss are yours to restyle.
Section 002 — Unreal 5.8: UMG widgets with a widget-switching HUD class.
Both: screen state is driven by GameStateManager (or your Blueprint equivalent), not by scattered per-screen logic. Pause must genuinely halt gameplay — time scale or time dilation, not just a visual overlay.
HUD binding is required. A health bar that shows a hard-coded three hearts is not a HUD; it must read from Health and change when you take damage.
The design decision
Restyling matters here. The starter UI is deliberately plain, and shipping it unchanged reads as unfinished.
Ask of every HUD element: what does the player do differently because this is on screen? If the answer is nothing, cut it. Screen space is the scarcest resource in your game, and most student HUDs show two or three things that nobody ever looks at.
Consider:
- Diegetic vs. non-diegetic. Can the information live in the world instead of on an overlay? Health shown as damage on the character is stronger than a bar in the corner.
- Readability. Contrast against your busiest background, not your emptiest. Test it over the noisiest part of your level.
- Consistency. One font, one button style, one spacing rhythm across all five screens.
- Safe area. Nothing critical within about 5% of the screen edge.
By track
| Track | Notes |
|---|---|
| 2D | Standard five screens |
| Puzzle | HUD shows move count or timer; Reset must be reachable in one input from gameplay |
| Narrative | Dialogue UI counts as HUD. Text size, contrast, and line length are graded here. |
| 3D | Standard five screens; watch contrast over varied environments |
| VR | World-space UI, not screen-space. Comfort options — vignette, locomotion toggle, height calibration — belong on the pause screen. A screen-space overlay in VR is uncomfortable and does not meet the requirement. |
Submission
- Build:
lastname_screenlayout.zip(same build targets as previous milestones) - Screenshots: one per screen, five total,
lastname_screens.pdf - Where: Canvas → Assignments → Screen Layout
- Due: start of class. Live demo during the exercise block — you'll be asked to navigate the full flow in front of the room.
Rubric — 5 points
| Criterion | Pts | Met when |
|---|---|---|
| All five screens present | 2 | Title, HUD, pause, win, and lose all exist in the build |
| Flow works both ways | 1 | Every screen is reachable and escapable; no dead ends; pause genuinely pauses |
| HUD is live | 1 | Bound to real game values and updates during play |
| Visual design | 1 | Deliberately restyled, readable over gameplay, consistent across screens |
Common failure modes
- No lose screen. Games with no fail state usually have no tension either — worth examining before Week 15.
- Pause that doesn't pause. The menu appears, the game keeps running behind it.
- Dead-end win screen. Player wins, screen appears, nothing responds, they close the app.
- Unstyled starter UI. Loses the design point and reads as unfinished in the Week 15 build.
- Hard-coded HUD. Looks correct in a screenshot, doesn't move during play.
- VR overlay UI. Uncomfortable, and doesn't meet the track requirement.
Looking ahead
Four weeks from now these screens are the first thing anyone sees in your published build. Time spent here is disproportionately visible in the Week 15 grade — the Published Game rubric awards 3 points for exactly this, and it is the easiest place in the course to look finished.