Chapter 29 — Exercises

These exercises move from analysis to implementation. By the end, you will have critiqued three games' UIs against accessibility criteria, mocked up a complete UI for a survival game, extended your project's UIManager to handle controller focus correctly, and written a critical reflection on a confirmation dialog that ruined a moment for you. Budget 12-18 hours total; do them in order, because each builds on the previous.

Difficulty markers: 🟢 introductory (1-2 hours), 🟡 intermediate (3-5 hours), 🔴 advanced (5+ hours).

Exercise 29.1 — UI Audit of Three Games 🟢

Pick three games you own and have played to at least the first major mechanical milestone (the first dungeon, the second hour, the first boss). Pick games that are different from each other. A useful trio: one indie 2D game (Hollow Knight, Celeste, Dead Cells), one AAA 3D game (The Last of Us Part II, God of War, Horizon Forbidden West), and one game older than 2010 (Half-Life 2, Resident Evil 4, the original Mass Effect).

For each game, fill in the following audit table.

After filling in the table for each game, write 250-400 words per game on what you found. Where did each game excel? Where did it fail? Were the failures the kind that could have been added in a polish sprint, or do they reflect deeper architectural choices?

Then write a fourth comparative paragraph (200-300 words). Of the three games, which felt most respectful of varied players? Which felt least? What was the cost of that respect (or its absence) in your own play experience?

Submit: three audit tables plus four written sections (~1,200-1,800 words total).

Why this exercise matters. Reading about accessibility is not the same as testing for it. Most designers never sit down and audit a game against a checklist. Doing so trains your eye for what is missing — and the next time you play a game, you will catch failures automatically. More importantly, you will catch them in your own builds.

Exercise 29.2 — Diegetic vs. Non-Diegetic Decision Mapping 🟢

Pick a game in your portfolio (a project you are working on, or a recent prototype). List every piece of information your UI currently presents to the player. Examples: health, ammo, current weapon, currency, inventory contents, current quest, minimap, dialogue choices.

For each piece, answer four questions:

1. What category is this currently? (Diegetic / Non-diegetic / Spatial / Meta)
2. Could it plausibly be moved to a different category? Sketch how.
3. What would you lose by moving it?
4. What would you gain?

Then pick the one piece of UI you most wish you had handled differently. Write 300-500 words on what you would change, why, and what the engineering cost would be.

Submit: the table plus the written reflection.

Why this exercise matters. The diegetic/non-diegetic distinction is most useful as an active choice rather than a passive description. Forcing yourself to catalog and then re-imagine every UI element trains the muscle that says "this could be a watch on the character's wrist instead of a number in the corner." You will not move everything. But you will move some things, and the things you move will be the ones that lift your game most.

Exercise 29.3 — Survival Game UI Mockup 🟡

Design a complete UI for a hypothetical survival game. The premise: the player is a single human survivor in a post-collapse landscape. They must manage hunger, thirst, temperature, and stamina; they craft tools and shelter; they fight occasional hostile wildlife; and they navigate a 4 km² procedurally generated map.

Your deliverables are:

1. HUD wireframe. Mock up the in-game HUD. Decide what is Tier 1 (always visible), Tier 2 (contextual), and Tier 3 (hidden). Justify each placement in 1-2 sentences.

2. Pause menu wireframe. Show the layout. Decide the default focus position. Decide what shortcuts are visible (e.g., "Save & Quit" might be a primary button rather than a sub-option).

3. Inventory wireframe. Decide whether your inventory is "as tool" or "as gameplay" (Resident Evil 4 briefcase style versus Skyrim list style) and justify in 100-150 words. Then mock up the layout for your chosen approach.

4. Crafting menu wireframe. Crafting is the most UI-dense screen most survival games have. Show how you would lay out: list of craftable items, currently selected item details, required ingredients, "Craft" action. Use Hick's Law to constrain options visible at once.

5. Settings menu structure. Tab structure with categories listed. No need to wireframe each tab; just list the categories and what would be in each.

Use any tool you like for wireframing — Figma, Excalidraw, paper-and-pen photographed, even ASCII. The fidelity does not matter; the thinking matters. A wireframe submitted with thoughtful rationale beats a beautiful mockup with no justification.

Total written justification across all five deliverables: 800-1,500 words.

Submit: wireframes plus written rationale.

Why this exercise matters. Designing UI for a hypothetical game forces you to engage with every constraint at once: what to show, how often, in what hierarchy, in what tier of accessibility, with what input method primarily in mind. The survival genre is chosen specifically because it pushes the HUD harder than most genres — many simultaneous status states demanding visibility.

Exercise 29.4 — Extend the UIManager for Controller Focus 🟡

Take the UIManager.gd from this chapter and extend it to handle three controller-focus problems that the chapter's version handles incompletely.

Problem 1: Focus loss on dynamic content. When a menu adds or removes elements at runtime (e.g., the inventory adds a new slot when the player picks something up), focus can be lost — the controller stops responding to navigation because no Control has focus. Add a _check_focus_health() helper that runs each frame and re-grabs focus on the first focusable child if no Control currently has focus and a controller is being used.

Problem 2: Mouse-vs-controller mode switching. When the player moves the mouse, the cursor should appear and focus-highlights should hide. When the player presses a controller direction, the cursor should hide and focus-highlights should show. Implement a small InputModeManager autoload that detects the most recent input source and broadcasts a signal mode_changed(mode) where mode is "mouse" or "controller". Have the UIManager subscribe and adjust mouse cursor visibility and focus visualization accordingly.

Problem 3: Tab navigation between focus regions. A complex menu (e.g., the Settings) may have multiple Tab containers. Pressing the controller's right shoulder button should advance to the next tab; left shoulder, to the previous. Implement input handling for this in the UIManager's _unhandled_input.

For each problem, write 100-200 words explaining the approach you took and the tradeoffs.

Submit: extended UIManager.gd plus the new InputModeManager.gd plus written explanations.

Why this exercise matters. Controller UX is the area where the gap between "playable" and "feels right" is widest. A menu where the focus subtly tracks input mode, never gets lost, and supports tab navigation from the shoulders is one a controller player can zip through without thinking. A menu without these is one they fight. Building the affordances yourself, in your own engine, is how the muscle memory for "how does this feel?" forms.

Exercise 29.5 — The Annoying Confirmation Dialog 🟢

Find a confirmation dialog in any video game that has annoyed you in the last year. Write 600-900 words analyzing it.

Cover:

1. What action triggered the dialog. Be specific. "I tried to sell a gem in Diablo IV" is better than "I was selling things in an RPG."
2. What the dialog said and offered as options. Quote it if you can remember.
3. Why it was annoying. Was the action trivial enough that the dialog was overkill? Was the dialog ambiguous? Did it default to the wrong answer? Did it nag every time even though you had done this hundreds of times?
4. What you (the designer in the chair) would do instead. Remove it entirely? Replace with undo affordance? Default to "yes" with a longer hold? Show only the first N times?
5. What design pressure (you suspect) led the team to add the dialog. Fear of bug reports? A specific high-profile incident? A producer's request after a focus group?
6. What this teaches you about confirmation design.

Submit: the analysis (~600-900 words).

Why this exercise matters. Most confirmation dialogs are added in response to one annoyed user complaint, and they cost the next million users a tax. Reflecting on a real example helps you see the calculation: who benefits, who pays, and what the alternative would have cost. The "boy who cried wolf" failure mode is easier to recognize when you remember the wolf.

Exercise 29.6 — Accessibility Pass on Your Project 🔴

Take your project's current state. Audit it against the Chapter 29 accessibility baseline (subtitles with size and background options and speaker labels, fully remappable controls for keyboard and controller, at least three colorblind modes, reduce-motion toggle, audio cues for off-screen events, aim assist if relevant, difficulty options separate from challenge sliders).

For each item, mark Pass / Partial / Fail, and for each Partial or Fail, write 150-300 words on what would be needed to bring it to Pass.

Then implement one of the items end-to-end. The most achievable choice for most students is probably the colorblind mode — implement the full pipeline, including the post-processing shader (Godot supports this via CanvasLayer and a ColorRect with a custom material), the settings UI, and the persistence to user://settings.cfg. Test with a simulated colorblindness preview (browser plugins like Color Oracle help if you do not have colorblind testers handy).

Submit: the audit document, the chosen implementation (code + screenshots), and a 200-400-word reflection on what you learned implementing it.

Why this exercise matters. Accessibility implementation is its own craft. You can read about it forever and still be surprised at how the actual integration touches every layer of your code. Doing one item — really doing it, not just stubbing it — gives you a calibrated sense of cost. And the next item is easier because you have built the architecture.

Exercise 29.7 — Reading Order Heatmap 🟢

For one playable scene in your project (about 3-5 minutes of gameplay), record yourself playing. Watch the recording and, using a screenshot from a representative frame, mark on the screenshot where your eye actually went during the play session. Use color-coded dots: red for "looked here repeatedly," yellow for "looked here a few times," green for "looked here once," blank for "never looked here."

Now overlay your HUD. Where did your HUD elements land relative to the heatmap?

If a Tier 1 element (e.g., health bar) is in a green or blank zone, that is bad — the player is not glancing at it where it sits. Either move it closer to a red or yellow zone, or accept that it is non-essential and consider demoting it.

If a Tier 3 element (e.g., a corner-stuck "Press M for map" hint) is in a red zone, that is also bad — it is screaming at the player constantly when it should be quiet.

Write 300-600 words on what the heatmap revealed and what you will change.

Submit: the screenshot with overlay and the written analysis.

Why this exercise matters. Reading order is empirical, not theoretical. You can argue forever about where the health bar belongs. A heatmap (even a rough self-observed one) settles the argument. The corners-of-screen are not always where the eye goes; in some games, the eye is locked to the crosshair or the center; in others, it is darting all over. Matching UI placement to eye traffic is the difference between a HUD that disappears into the periphery and one that has to be hunted for.

Exercise 29.8 — Persona-Driven UX Walkthrough 🟡

Recall the player personas you wrote in Ch 4. If you do not still have them, write three new ones now: pick a 14-year-old casual mobile-first player, a 35-year-old console enthusiast with limited free time, and a 60-year-old player with mild presbyopia and arthritis. Give each a name, a session length, a primary input device, and any specific accessibility considerations.

Now walk each persona through your project's UI from launch to ten minutes of play. For each persona, record:

1. Where they would get stuck. A button too small for the 60-year-old. A tutorial too long for the 14-year-old. A pause-to-quit flow that loses the 35-year-old's progress when they get pulled away by their kid.
2. Which menu they would never find. Be honest. The 14-year-old will not browse settings; if accessibility lives only in settings, they cannot find it.
3. What they would say after their session. One sentence in their voice.

Do this for all three personas. The contrast will be revealing. Designs that work for the 35-year-old enthusiast often fail the 14-year-old casual and the 60-year-old presbyopic player simultaneously, and the failure modes are different.

Write 600-1,000 words across the three walkthroughs.

Submit: the three persona walkthroughs.

Why this exercise matters. UI testing in your own head is biased toward how you play. Personas force the bias visible. The 60-year-old persona in particular is the one most frequently absent from internal testing, even though the 50+ demographic is one of gaming's fastest-growing segments. Build the muscle of imagining other bodies and other lives at the controller.

Exercise 29.9 — Localized Text Stress Test 🟡

Take any text-heavy screen in your game (the inventory, the dialogue UI, the settings menu). For every string visible on that screen, generate three alternate versions:

• A 30%-longer version (simulating German, Russian, Polish localization).
• A 50%-longer version (simulating worst-case literal translations of idioms).
• A 60%-shorter version (simulating Chinese / Japanese density).

Drop the long versions into your UI and see what breaks. Text overflowing buttons. Wrapped text breaking layouts. Truncated text losing meaning. Dropdown options no longer fitting.

Now drop the short version. The opposite problem appears: vast empty space, awkward proportions, design elements designed for length now floating in void.

Document each break with a screenshot and a 50-100 word description of how you would address it. The two main strategies are flexible layout (containers that resize with content) and content constraints (limit string length at the design stage to a safe maximum that survives translation).

Submit: the screenshots, the descriptions, and a 200-300 word summary of which strategy you favor and why.

Why this exercise matters. Localization breaks UI in ways that English-only testing never reveals. By the time your game ships in eight languages, half your UI is a small disaster you did not anticipate. Stress-testing in advance with synthetic long and short strings catches the problems while you still have time to fix the architecture, not just patch the symptoms.

Wrap-Up

If you completed all nine exercises, you have done about as much UI/UX practice as a junior UI designer does in their first two months on a job. You have audited, mocked up, implemented, walked personas through your design, stress-tested for localization, and reflected on your own annoyances as a player. You have looked at existing games with a critical eye and at your own game with a self-critical one.

A few habits to build going forward:

Notice UI for the first ten minutes of any game you play. After ten minutes, the UI should fade — that is success. If after ten minutes you are still aware of the menu structure, the font, the awkward navigation, write down what jumped out. Build a private notebook of UI annoyances. Over a year, this notebook becomes the most useful document in your design library, because it is a long list of mistakes you now know to not make.

Watch other people play your game without commentary. Sit next to a friend, a family member, a stranger if you can recruit one. Do not explain. Do not coach. Just watch. Where do they pause? Where do they squint? Where do they ask "what do I do here?" — those are your UI bug reports, and they are more honest than any internal QA pass.

Read one Game UI Database screenshot per day. A standing fifteen-minute habit of looking at how other games solved problems you are about to solve. Over a year, you will have absorbed thousands of patterns. Pattern recognition is the fastest path to design intuition that holds up under deadline.

The work in this chapter is the difference between a game that plays well and a game that feels like a finished product. The combat is great. Make sure the player can find it.