Answers to Selected Exercises

How to Use This Appendix

This appendix contains worked sample answers to a curated selection of exercises from the book — roughly one to three per chapter, across 24 of the 40 chapters. It is not exhaustive. Most design exercises have no single right answer; the book's exercises are deliberately open-ended, because that is how design actually works.

So: what is this for?

These answers exist for you to check style and depth against a worked model, after you have already attempted the exercise on your own. If you read the sample answer first, you will rob yourself of the thinking. If you attempt the exercise, then read the sample, you will see where a thoughtful answer goes deeper, where it hedges honestly, where it names trade-offs rather than pretending they do not exist.

A few notes on these answers:

• They are written in the same practitioner voice as the book. They are not "A+ term paper" answers. They are working-designer answers — with asides, opinions, and occasional admissions that a question is harder than it looks.
• Where an exercise is truly open-ended ("design a level," "write a post-mortem"), I have instead written a critique rubric — the questions I would ask of your answer, and what a good answer does differently from a weak one.
• When I quote a specific chapter number for a referenced technique, I am pointing you back at the section that established it. Use those as a reading path.

Chapters covered below: 1, 3, 5, 6, 8, 9, 11, 13, 16, 17, 20, 21, 24, 25, 26, 27, 29, 30, 31, 32, 33, 35, 37, 40.

Chapter 1: What Is a Game?

Exercise 1.1 — Analyze a Non-Game

Pick an activity you do not usually consider a game (doing dishes, a commute, grocery shopping). Apply the book's five-part working definition — voluntary, rules, goal, feedback, meaningful outcome — to it. Is it a game? Partially? What would make it one?

Sample Answer:

Let me try grocery shopping.

• Voluntary? Partially. I have to eat, so shopping is compulsory; but how I shop — this store, that store, list or no list — is voluntary. So: partial.
• Rules? Yes. Budget, store layout, posted prices, things-I-can-and-cannot-buy (allergies, preferences, the pantry). Informal but real.
• Goal? Yes — buy the week's food, ideally under budget, with minimum backtracking in the aisles.
• Feedback? Running total at checkout. Empty pantry at home indicating success or failure. Delayed, mostly.
• Meaningful outcome? Yes — you eat well or you do not.

So by the book's definition, grocery shopping is about 80% of a game, missing mostly the voluntary leg. The interesting move: turn it into a game by adding a non-instrumental layer of rules. Some people already do this — "the $40 challenge," "only things on the list, no impulse buys," "get in and out under fifteen minutes." These voluntary meta-rules lift it across the threshold. Which matches exactly what we said in the chapter: the line between a non-game and a game is voluntary constraint added for its own sake.

The deeper lesson for you as a designer: your players are doing this all the time. They invent goals on top of your game that you did not write. Speedrunners, deathless runs, no-upgrade runs, self-imposed constraints. They are adding leaves to the tree you planted. Honor them by leaving space in your rules for it to happen.

Chapter 3: Setting Up Your Design Laboratory

Exercise 3.2 — Godot Installation and First Scene

Install Godot 4.x, create a new project, and produce a scene where a sprite moves when you press arrow keys. Submit a screenshot of the editor and the one-line description of one thing that surprised you.

Sample Answer:

A correct answer here is "I did it and here is the screenshot." The interesting part is the thing-that-surprised-you.

Common surprises I have heard in a classroom:

• "The physics body did not move when I set position. It moved when I used move_and_slide." (Welcome to the difference between kinematic position and physics-driven movement — Ch. 5 goes into this.)
• "_process(delta) fires every frame, but _physics_process(delta) fires on a fixed clock." (Good. You noticed. Use physics for movement, process for everything else.)
• "Godot uses scenes-within-scenes, not prefabs." (Correct. The "scene tree" is the organizing principle of the engine. Spend an afternoon with it before proceeding.)
• "I thought GDScript would be weird, and it is basically Python." (Yes.)

What a bad answer looks like: "Nothing surprised me." If nothing surprised you, you probably did not experiment enough. Try moving the sprite by changing rotation instead of position. Try making the sprite twice as wide by changing scale. Try doing both at once. Something in that will surprise you.

Chapter 5: Game Mechanics

Exercise 5.1 — Verb Decomposition

For three games you know well, list every player verb. Classify each as primary, secondary, or progression. Identify one verb that could be removed without significantly changing the experience.

Sample Answer (partial — one of three games):

Celeste.

Primary mechanic: Dash. The game is about the dash — the verb that makes the rest of the movement expressive. Remove the dash, and Celeste collapses into a mediocre platformer.

Verb that could be removed without damage: Pick up / carry strawberry. You can complete the game without ever collecting a strawberry. Strawberries exist for optional mastery challenges and completionist goals, not for the core experience. Removing the carry verb would eliminate a particular kind of high-skill challenge, but the spine of the game survives.

The useful insight: Celeste has only five real movement verbs. The depth comes from how the verbs interact in constrained spaces — a wall right next to a climbable surface, a dash angle that must thread between two spikes. The game's richness is not in its verb count; it is in the density of verb-combination opportunities per screen. That is the general lesson. Add verbs only when they unlock combinations; never add verbs because the design doc feels thin.

Chapter 6: The Core Loop

Exercise 6.1 — Diagram a Game's Core Loop

Pick a game and diagram its core loop. Identify the inputs and outputs of each step, and what happens when the loop is "broken" (run out of resources, die, etc.).

Sample Answer (Hades):

       ┌──→ enter chamber
       │        │
       │        v
       │    fight enemies → gain currency / keepsakes
       │        │
       │        v
   complete ← choose door reward
       │        │
       │        v
       │   meet minor NPC / use boon
       │        │
       │        v
    die ← boss fight
       │
       v
   return to House of Hades → spend meta-currency
       │
       v
   pick new weapon / upgrades → start new run

Inputs to the loop: your skill, your current weapon's kit, the boons you pick up. Outputs: currency (short-term), keepsakes/weapons (meta), narrative dialogue (progression).

The loop is broken when Zagreus dies — but that is also the loop resetting, not a failure state. Hades' design insight is that the "fail" branch leads to the most narrative content in the game. Every death is a scene in the House. The loop has no dead end. That is why players keep playing long after they have "beaten" the game: the meta-loop is where the story is.

A good answer for any game names: (a) the inner 30-second loop (what you do every ten seconds), (b) the outer 5-minute loop (the minute-scale structure), (c) the meta-loop (the session-spanning structure), and (d) where failure lives — inside the loop or outside it.

Chapter 8: Feedback Systems

Exercise 8.1 — Juice Audit

Play a game you find unsatisfying. List every piece of feedback missing that would make a basic action (jumping, attacking) feel better. Rank them by impact.

Sample Answer:

Let me pick a hypothetical flat indie 2D platformer and list what I would add, ranked:

1. Squash and stretch on landing. A single-frame vertical squash (~20% squish) on landing, resolving over 80ms. Free, huge impact.
2. Input buffering on jump. If you press jump up to 120ms before touching ground, it registers. Turns "missed jumps" into "forgiven jumps."
3. Coyote time. 100ms after walking off a ledge, you can still jump. Same category — forgiveness feedback.
4. Landing dust particle. Twelve pixels of procedural dust on impact. Free, sells weight.
5. Screen shake on hard landing or hit. 3–4 pixels max, 120ms duration. Anything bigger and it becomes nauseating.
6. A quieter footstep sound. Most indie platformers have no footsteps and the absence is deafening. A short 30ms low-volume tap per frame of running.
7. Pitch-shift the jump sound. Same sample, ±5% pitch variance per jump. Eliminates the "same sound every time" feel.
8. Audio-ducking when music should get out of the way. On attack hit, duck music 6dB for 200ms.

Ranked by perceived impact per hour of implementation work, items 2 and 3 (buffering and coyote time) are the game-changers — they can make a mediocre platformer feel like a good one with about an hour of code.

A weak answer lists twenty things with no sense of which matters. A strong answer ranks and justifies.

Chapter 9: Emergence

Exercise 9.1 — Find the Emergence

Play Breath of the Wild (or another systems-driven game) for three hours. Document five emergent interactions — moments where two or more systems produced a result the designers likely did not hand-author.

Sample Answer (three of five):

1. Metal sword + Lightning in a thunderstorm. I had no idea this would happen. I put on metal armor in a storm, got struck, died. I dropped the metal weapon and survived. The systems: weather (thunderstorm RNG), material tagging (metal), area-of-effect damage (lightning strike), player inventory. None of these were designed specifically for the others; they were designed as primitives. The interaction is emergent.

2. Fire spreads on grass to push enemies off a cliff. I lit grass. Wind carried the fire. Enemies standing on the grass burned and panicked; two ran off a cliff to their death. Systems: fire propagation, wind direction, AI fear response, environmental physics. I did not intend this. I did not even intend to set the grass on fire — I threw a torch at an enemy and missed.

3. Updraft from fire → glider traversal. Setting grass on fire creates an updraft. With the paraglider, you can ride that updraft vertically. Suddenly, fire becomes a traversal tool. The designers probably saw this during playtesting and decided to keep it. This is my favorite kind of emergence: the designers discover it, too, and choose not to fight it.

The key insight for you as a designer: emergence comes from orthogonal primitives. The systems in BOTW are orthogonal (they can each operate independently) but they all observe a small shared vocabulary — material tags like "metal," "flammable," "cold." You do not design emergent interactions. You design the primitives, and you design the shared vocabulary. The interactions arise.

Chapter 11: Flow

Exercise 11.1 — Flow Diary

Play a game for an hour. Every fifteen minutes, pause and write: what challenge was I facing? What was my skill level? Was I in flow?

Sample Answer (hypothetical session of Celeste, Chapter 3):

• 0:00. Challenge: easy early screens, getting used to the dash. Skill: low. State: slight boredom — below the flow channel (too easy for my skill).
• 0:15. Challenge ramp — introduction of spikes and a dashing-through-gaps pattern. Skill level: catching up. State: flow. Died 6 times on one screen. Did not feel bad. Felt alive. This is what Csikszentmihalyi means.
• 0:30. Hit a screen requiring three consecutive dashes with no margin. Died 22 times. Above the flow channel for about 4 minutes — anxiety. Then skill caught up and I was back in flow for the completion attempt.
• 0:45. Checkpoint, breather. Brief narrative moment with Madeline. Below flow (no challenge). Designed that way intentionally — recovery zone.

What I learned: the flow channel is not a steady line. Celeste oscillates you above and below it — challenging, breather, challenging, breather. The design is not trying to keep you in flow constantly; it is pacing flow against recovery.

If your answer reads "I was in flow the entire hour," either you are kidding yourself or you were playing something that does not actually challenge you. Neither is interesting. Honest answers have "I got frustrated" and "I got bored" somewhere in them.

Chapter 13: Challenge and Mastery

Exercise 13.1 — Design a Skill-Teaching Sequence

Design a three-part sequence that teaches a single skill: introduce, practice, test. Describe each screen/room.

Sample Answer (teaching "wall-jump"):

• Introduce (Screen 1): A pit. Too wide to simply jump across. On the far wall, a short stretch of climbable vertical surface. The player cannot cross by running and jumping alone. They experiment. They jump at the wall. If they press jump a second time, they wall-jump. The pit is shallow — falling is instant-restart, not punishing. Goal: demonstrate the verb exists.

• Practice (Screen 2): Two walls opposing each other, with upward distance between them. Player has to wall-jump back and forth to climb upward, three or four hops. No enemies, no spikes. Goal: let the player repeat the verb enough times to internalize it.

• Test (Screen 3): A tall room with two walls, spikes at the bottom, a collectible near the top. Player must wall-jump upward under mild pressure (spikes = real consequence) to reach the collectible. Goal: apply the skill in a meaningful context where success feels like achievement.

The mistake new designers make on Screen 3 is to also introduce a second new mechanic. Do not. Screen 3 tests only the skill from Screens 1–2. Combine skills with each other in later rooms, not the rooms where you are still teaching.

This pattern — introduce → practice → test — is the spine of tutorial design in Portal, Half-Life 2, Breath of the Wild, and virtually every other game with strong onboarding.

Chapter 16: Level Design Fundamentals

Exercise 16.2 — Paper-Prototype Three Levels

Create paper prototypes of three levels with pacing charts (intensity-over-time).

Sample Answer — Critique rubric (this is open-ended; I will describe what a good submission looks like):

A strong paper prototype submission has:

1. A clear spatial drawing — grid paper, top-down or side view, showing walls, enemies, items. Legible without explanation.
2. A legend — what icons mean what. If you have to ask, the legend is wrong.
3. A pacing chart — a graph of intensity (y-axis) vs. progress through the level (x-axis). Peaks at encounters; valleys at breathers. A good level has at least three peaks and three valleys. A great level's chart rhymes — the final peak echoes the first, slightly higher, maybe with a twist.
4. A one-paragraph designer statement — what this level is teaching, what the player is supposed to feel.

A weak submission has only the drawing and no statement. That is the most common mistake: drawing the map and forgetting to articulate why. A level is not an aesthetic object. It is an intentional experience. If you cannot say in a sentence what the level is teaching the player to do, the level does not know what it is.

Chapter 17: 2D Level Design

Exercise 17.3 — Teardown of a Classic Level

Write a teardown of Super Mario Bros. World 1-1. Where is the tutorial? Where is the challenge? Where is the signposting?

Sample Answer:

The opening of 1-1 is a quietly perfect tutorial:

• Mario spawns on the left third of the screen, facing right. You walk right because there is nothing to the left.
• The first Goomba approaches. The only verbs you have are walk and jump. If you walk into it, you die. If you jump over it, you live. (If you jump on it, you learn stomping exists. If you jump too short and into it, you learn timing.)
• The first ? block is placed exactly at jump height so that as you jump over the Goomba, you head-bump the block. A mushroom pops out. It moves right — following the player's direction. You probably touch it. You grow.
• The first pit arrives right after: you learn jumping = traversal, not just combat.
• A pipe to hide behind while the next Goomba passes. Then two Goombas together. Then a Koopa Troopa: a new enemy type, slightly different rules.

No text. No tutorial pop-ups. No "press A to jump." The level design is the tutorial.

Where is the challenge? The flagpole at the end — the first place where precision of jump matters for score.

Where is the signposting? The world itself points right. The ? blocks are positioned so that a natural jump intersects them. The mushroom moves in the direction of the player's travel. The camera scrolls only right. Everything points toward progress.

Shigeru Miyamoto designed this level with a deliberate intent: teach the player every core mechanic without a single instruction, in under 30 seconds of play. It has been studied for four decades because it is still the exemplar of this approach.

Chapter 20: Narrative in Games

Exercise 20.1 — Mechanic-Narrative Alignment

Pick a game whose mechanics clash with its narrative. Describe the clash. Then propose a fix.

Sample Answer:

Uncharted (any entry). The narrative casts Nathan Drake as a charming, roguish adventurer. The mechanics cast him as a mass murderer. Over a ten-hour campaign, Drake kills hundreds — if not thousands — of human enemies. The cutscenes treat him as a light-hearted guy with a good heart.

This is called ludonarrative dissonance, a term coined by Clint Hocking in 2007 specifically to critique BioShock.

The fix is not "less killing." The fix is one of:

1. Acknowledge it — have a character notice. "How many men have you killed today, Nate?" A single line recontextualizes without changing mechanics.
2. Reduce enemy humanity — make them clearly mercenaries, not conscripts. Make them shoot first. This is a partial fix; it helps but does not eliminate the problem.
3. Reduce kill count — have fewer, more meaningful combat encounters. This is The Last of Us Part II's approach: every kill feels weighty because there are fewer of them.
4. Lean into it — Drake is supposed to be haunted. This is The Last of Us' solution for Joel. Rewrite Drake as a darker character. Not an Uncharted fit, but it would be internally consistent.

There is no perfect solution. Every option changes the game meaningfully. That is the nature of narrative-mechanic alignment: you cannot patch it over — you have to choose a posture and commit.

The general lesson: mechanics make arguments whether the writer meant them to or not. A cover-shooter makes arguments about violence; a farming sim makes arguments about labor; a dating sim makes arguments about intimacy. Your job as a designer is to make sure the argument your mechanics make is the argument your story wants to make.

Chapter 21: Dialogue and Characters

Exercise 21.2 — Write a Branching Dialogue

Write a short branching dialogue (two NPCs, three branches) where the player's choice changes the NPC's state permanently.

Sample Answer:

Guardsman Vek (leaning on a spear, not making eye contact).

Vek: "You're that outsider. The one they've been talking about."

[1] "Who is 'they'?"
[2] "I don't want trouble, just passage."
[3] "What's your name, stranger?"

---
Branch 1 (investigative):
Vek: "The council. They don't trust you. Honestly? Neither do I. But 
you haven't done anything yet, so I haven't done anything either."
→ Sets Vek.suspicion = HIGH. He will watch you in the marketplace.

Branch 2 (deferential):
Vek: (sighs, shifts grip on spear) "That's what they all say. Go on. 
But if I see you near the keep, we have a problem."
→ Sets Vek.suspicion = MEDIUM. He stands down but remembers your face.

Branch 3 (friendly, probing):
Vek: (surprised the player asked) "Vek. Just Vek. Nobody asks." 
(small smile, almost involuntary)
→ Sets Vek.suspicion = LOW. He will greet you by sight next time.
→ Sets Vek.humanized = TRUE, unlocking a later side-quest line.

Notes on what I did:

• Each branch has a mechanical consequence. Not just different text — a permanent state change. That is the difference between choice theater and real choice.
• The "friendly" branch produces the best outcome narratively, which is a small trap: it means most players will take it on second playthroughs. A more interesting design would make each branch open different paths rather than one being strictly better. I have not done that here, but in a real game I would.
• The stage directions (in parens) are subtle: "not making eye contact," "almost involuntary," "shifts grip." These are more important than the text itself. They make Vek read as a person, not a vending machine.

Chapter 24: Game Economy Design

Exercise 24.1 — Economy Audit

Pick a game with an in-game economy. Identify the sources, sinks, and faucets. Is it balanced?

Sample Answer (Stardew Valley):

Sources (where gold enters the economy): - Crop sales (primary) - Foraging - Fishing - Mining (ore → bars → sale) - Artisan goods (cheese, wine, preserves) - Quests - Spring items (flowers, events)

Sinks (where gold leaves): - Seeds - Upgrades (tools, house, community center) - Buildings (coop, barn, greenhouse) - NPC gifts - Inn food (rare) - Travel tickets

Faucets (passive inputs — time, not action): - Farm animals producing milk/eggs daily - Trees growing fruit seasonally - Crops growing over days

Is it balanced?

Year 1: tight. You feel the economy. Every purchase is a real decision. Do I upgrade my watering can or buy Spring sprinklers?

Year 2–3: loose. Once the greenhouse is built and you have cask-aged wine, you become wealthy fast. The economy's pressure evaporates.

Post-perfection: vestigial. Money is no longer a constraint. The economy is gone, and what is left is the meta-game (community center, perfection goals, romance) holding player interest.

Stardew's economy is a ramp, not a plateau — early scarcity, late abundance. For many players, this is fine: the game's late-game identity shifts from "survival farmer" to "cozy master-of-the-valley." For others, it is where the game loses them.

Design lesson: an economy is not meant to be perfectly balanced forever. Decide when it is supposed to matter, and let it deliberately decay after that point. Just be honest about the plan.

Chapter 25: Progression Systems

Exercise 25.2 — Design an XP Curve

Design an XP curve for a 50-level RPG. Graph the required XP per level. Justify your choice.

Sample Answer:

I will use a quadratic curve with a gentle early ramp:

$$\text{XP}(L) = 100 \cdot L^{1.6}$$

That gives approximately:

• Level 1→2: 100 XP
• Level 5→6: 760 XP
• Level 10→11: 2,512 XP
• Level 25→26: 14,929 XP
• Level 50→51: 100,000 XP

Why not linear? Linear curves mean the last level feels the same as the first — a failure of mastery-progression.

Why not purely exponential (say, XP = 100 * 2^L)? Exponential curves make late levels impossible in reasonable time and push designers into "hand out more XP" fixes. Quadratic is the sweet spot: early levels are fast (encouraging experimentation), later levels are slow (rewarding commitment).

Tuning questions to ask yourself after drawing the curve:

• How long (in minutes of play) does each level take? Level 1 should take 2–5 minutes; level 50 should take maybe 4–8 hours of focused play.
• What rewards does each level grant? New levels need to unlock something — a skill point, a new ability, an equipment slot. If level 30 feels identical to level 29, the curve is meaningless.
• Is there a wall? Around level 40 on my curve there is a grinding wall. That is either intentional (hold players in endgame content) or a flaw. Decide which.

Every XP curve is a tuning problem, and you will not get it right on paper. Playtest and adjust.

Chapter 26: Combat Design

Exercise 26.3 — Design a Boss Fight

Describe a three-phase boss fight. Specify each phase's telegraphs, weaknesses, and pacing.

Sample Answer (hypothetical mid-game boss: The Ashen Warden, for our 2D action-adventure):

Phase 1 — The Test. - HP: 100%–66%. - Telegraphs: large wind-up on every attack, clearly colored weapon glow (red = damage, yellow = knockback). - Mechanic: the Warden throws their axe (projectile). Player can dodge through the projectile window or use it as cover. - Weakness: after the axe throw, 1.5 seconds of vulnerability. - Pacing: deliberate, rhythmic. The player should figure out the pattern within 60–90 seconds.

Phase 2 — The Escalation. - HP: 66%–33%. - Telegraphs: slightly faster wind-ups. One new attack added: a ground slam that cracks a zone of the arena. - Mechanic: the cracked zones remain hazards for the rest of the fight. The arena shrinks as the fight progresses. - Weakness: same as Phase 1, but the window is now ~1.0 seconds. - Pacing: rising tension. Player should survive Phase 1 well, struggle with Phase 2.

Phase 3 — The Furious. - HP: 33%–0%. - Telegraphs: minimal. Wind-ups shortened to the limit of readability. - Mechanic: the Warden dual-wields, attacks become combos, and the arena is ~60% hazards. - Weakness: the Warden exposes their back for 0.5 seconds after each three-hit combo. - Pacing: all-out. Most players will die here on first encounter. The "aha" moment is realizing the combo-back-exposure.

Why three phases? Because two is too few (no sense of escalation), four is too many (pacing drags in a 2D context). Three is the standard for a reason.

Why the shrinking arena? Because spatial constraint intensifies without requiring the enemy to hit harder. Damage numbers get boring; a shrinking battlefield never does.

What the boss teaches: reading telegraphs, managing space, recognizing combo patterns. A good boss is the exam at the end of a level, testing the skills the level taught.

Chapter 27: AI Design

Exercise 27.2 — FSM to Behavior Tree

Design a simple enemy AI as a finite state machine. Then redesign the same AI as a behavior tree. Compare.

Sample Answer (a basic patrolling enemy):

FSM (states and transitions):

[IDLE] ──(timer expires)──> [PATROL]
[PATROL] ──(player seen)──> [CHASE]
[PATROL] ──(reaches waypoint)──> [IDLE]
[CHASE] ──(player in attack range)──> [ATTACK]
[CHASE] ──(player lost)──> [SEARCH]
[ATTACK] ──(attack complete)──> [CHASE]
[SEARCH] ──(timer expires)──> [PATROL]

Seven transitions. Five states. This works, but notice: if I want to add "flee when HP low," I need to add transitions from every existing state to a FLEE state. That is five new transitions. For every new state I add, I multiply the edges.

Behavior tree (priority-ordered):

Root: Selector
├── [If HP < 20%] Sequence: Flee
├── [If Player in attack range] Sequence: Attack
├── [If Player seen] Sequence: Chase
├── [If lost player recently] Sequence: Search
└── Default: Sequence: Patrol

Five leaves, one root. Each tick, the tree evaluates top-down and executes the highest-priority valid branch. Adding "flee when HP low" is a one-line insertion.

Comparison:

• FSMs are explicit about transitions. Easy to visualize. Hard to modify.
• Behavior trees are priority-ordered. Easy to modify. Harder to debug when behaviors flicker between frames.
• FSMs scale poorly beyond ~10 states. Behavior trees scale to complex AI because you can nest branches.

For our project's enemy AI in Ch. 27, FSM is fine — we have five states. For a game with tactical AI (XCOM, F.E.A.R., Halo), a behavior tree is the right tool. Jeff Orkin's F.E.A.R. GOAP paper and Damian Isla's Halo 2 talk (both in the bibliography) are where to go if you want to see the craft at its most developed.

Chapter 29: UI and UX

Exercise 29.1 — Diegetic UI Audit

Find a game with diegetic UI (UI presented as part of the world). Describe it, and describe a piece of non-diegetic UI in the same game. Which works better, and why?

Sample Answer (Dead Space):

Diegetic: Isaac Clarke's health meter is a row of glowing bars running up his spine on the outside of his spacesuit. His stasis meter is on his shoulder. Interactions with consoles are projected holograms that appear in front of him, as if the suit is projecting a display. Inventory management is done via a holographic pop-up tethered to his arm.

Non-diegetic: There is still a small reticle in the center of the screen when aiming. Not world-embedded.

Which works better?

The diegetic UI works better in this context. Not always — there are games where pulling info off the HUD is friction you do not want. But in Dead Space, the horror is about Isaac's isolation inside his suit. Putting the HUD on the suit itself reinforces the claustrophobia. You are Isaac in a way you cannot be if the HUD floats over him like a television.

The reticle is diegetic-adjacent — a laser dot from his weapon, technically inside the fiction. It preserves the aesthetic without sacrificing the functional clarity of aiming.

The general rule: diegetic UI is better when it reinforces the fiction of embodiment (Dead Space, Metro Exodus, Signalis). Non-diegetic UI is better when information density or clarity is worth more than fiction-integrity (Civilization, League of Legends, any strategy game). Never choose diegetic for its own sake. Choose it because it says something about who the player is inside the fiction.

Chapter 30: Sound Design and Music

Exercise 30.1 — Describe a Game's Audio Layers

Pick a game and describe its audio in four layers: ambient, music, SFX, voice/dialogue. How do the layers mix?

Sample Answer (Hollow Knight):

• Ambient. The layer you do not notice. Cave drips in the Forgotten Crossroads. Wind in the Howling Cliffs. Water in the City of Tears (also rain — constant, inescapable). These tell you where you are without showing you.
• Music. Christopher Larkin's score. Each area has its own theme. Transitions between areas cross-fade seamlessly. Boss themes are layered on top of area themes, not replacements — the boss music has an ambient thread that returns when the fight ends.
• SFX. Pogo-stick bounce on a surface, slash-and-crack of the nail, the distinctive "shing" of a successful parry. Enemies have audible tells — the Great Husk Sentry's heavy breathing announces itself from two rooms away.
• Voice/Dialogue. Minimal. Most NPCs "speak" in a nonsense-chatter (procedural vocal-syllable generation), not real words. Hollow Knight is functionally voiceless, which was a scope decision and a stylistic one simultaneously.

How do they mix?

Priority ducking. When music is high-energy (boss fight), ambient ducks. When you enter a dialogue, music ducks. When you swing the nail, the slash SFX briefly ducks both music and ambient to ensure readability.

The Larkin score is the most recognizable element, but the ambient layer is the one doing invisible emotional work. Turn the music off and play for fifteen minutes. The dread — and the loneliness — are in the ambient.

Sound design is 50% about what plays. It is 50% about what ducks so the right thing is heard.

Chapter 31: Playtesting

Exercise 31.2 — Run a Playtest

Run a 30-minute playtest of your project with a non-designer friend. Document three findings that surprised you.

Sample Answer — Critique rubric:

A strong submission is specific and honest. A weak one says "the playtester liked it."

Typical surprises when running a first playtest:

• "They did not find the exit." You showed them exactly where the exit was in your head. They did not see it. Why? Probably your signposting is weaker than you thought. Every designer goes through this the first time.
• "They did not know [verb X] existed." You tutorialized verb X on screen 2. They missed it. Now verb X is locked away from them for the rest of the playtest.
• "They used [verb] in a way I did not design for." Sometimes this is great emergence. Sometimes this is a bug exposing itself. Either way, it teaches you that the player's model of your system is not your model.
• "They got frustrated at [X] and stopped." You thought X was the interesting challenge. They thought it was a wall. The gap between your intended difficulty curve and their actual experience is where the design work lives.

The quality of your playtest write-up is measured not by whether the playtester liked the game but by how specific and unflattering the findings are. "They liked it" is useless. "They spent 90 seconds trying to open a door that required a key they did not know existed" is priceless.

Chapter 32: Game Balancing

Exercise 32.2 — Balance a Weapon

You have three weapons: fast/weak, medium/medium, slow/strong. Design DPS parity such that each has a reason to exist.

Sample Answer:

Let me set DPS target at 30 per second as a reference.

On paper, all three have the same DPS. Why would a player pick one over another?

Fast weapon (Dagger) — advantages: - Low commitment: the 0.2s attack window means you can interrupt your own animation if an enemy telegraphs. - High hit-rate forgives aim slightly: if you swing and miss by a hair, you get another swing in 0.2s. - Good against weak multi-enemy groups. - Poor against armored enemies with threshold damage (below a threshold, damage is reduced or ignored — 6 may not penetrate).

Medium weapon (Sword) — advantages: - Best general-purpose. - Typical reach. - No major weakness; no major strength. - The default. Most players gravitate here.

Slow weapon (Hammer) — advantages: - One-hit-threshold advantage: 45 damage clears most armored enemies in one hit. - Knockback: crowd control effect. Creates space. - Poor against fast enemies that punish the 0.8s commitment.

The DPS parity is a starting point, not the end of the design. The real balance lives in context. When does each weapon shine? When does each weapon suffer? If every weapon was equally good in every situation, why would you ever switch? The job of the combat designer is to make each weapon situationally dominant and situationally disadvantaged.

Watch for: players who play the whole game with Sword because it has no sharp weakness. That is not a balance failure; it is a design one. You need an encounter that punishes Sword and rewards Hammer or Dagger. Introduce that encounter.

Chapter 33: Game Design Ethics

Exercise 33.2 — Ethics Statement

Write a one-page ethics statement for your project. What patterns will you not use?

Sample Answer — a working ethics statement for our 2D action-adventure:

This game has no loot boxes. No gacha. No paid currency. No battle pass. No ads. It is a one-time purchase ($X), and it is finite.

It does have: - An assist mode, available from the first menu. Players can turn on invincibility, infinite stamina, or level-skip. This will not disable achievements. - Accessibility options for input remapping, color-blindness modes, and text scaling. - A pause button that actually pauses, even in boss fights.

It does not have: - Engagement metrics we do not need. We do not track session time to optimize retention. We track bugs. - Social-comparison systems. No leaderboards. No visible death counts from other players. No shaming. - Difficulty gating on cosmetics. What you unlock is what you unlock; visual customization is given freely, not sold.

When we added features during development, we asked: does this make the player's experience better, or does this make our metrics better? If the answer was the second, we did not ship it.

This does not make our game ethical. An ethical game is defined by its treatment of the player across the whole arc, and players will tell us where we fell short. We will listen, and we will patch what we can.

What makes a strong ethics statement:

• Specific decisions, not abstract principles.
• Honest about what you did include.
• Acknowledges you might be wrong.
• Does not claim ethical superiority.

What makes a weak one:

• "We believe in respect for our players." Empty words.
• No concrete decisions.
• Reads like a press release.

Chapter 35: Genre Analysis

Exercise 35.1 — Genre Hybridization

Pick two genres that are rarely combined. Design a game concept that combines them. What conventions transfer? What conflicts?

Sample Answer:

Concept: Rhythm game + roguelike.

A game exists in this category — Crypt of the NecroDancer. So let me take two less-obviously-combined genres.

Concept: Dating sim + horror game.

(Several exist, but let me design one specifically.)

What transfers from dating sim: - Relationship meters with key NPCs. - Dialogue trees with affection-impacting choices. - Time management — you have N days, you can only spend time with a few characters. - Endings based on whom you end up with.

What transfers from horror: - Atmospheric dread; audio dominance. - Paranoia — NPCs whose trustworthiness is uncertain. - Permadeath or permanent loss mechanics. - A threat that exists regardless of your choices.

The conflict:

Dating sims reward trust. Horror games reward suspicion. The core mood of "maximize relationships" and the core mood of "someone here might kill you" are at war.

The solution: make the player navigate this tension deliberately. The horror NPC is one of the romance options. You have to decide whether to pursue them. The depth of the relationship you build increases both the reward (a true, dangerous love story) and the risk (they might betray you).

Doki Doki Literature Club does something adjacent. Coffee Talk has horror-adjacent moods. Signalis has romance buried in a horror game. The genre is possible; it just requires you to lean hard into the conflict rather than resolving it.

General principle: genre-hybrids work when they take the conflict seriously. They fail when they paste one on top of another.

Chapter 37: Scope Management

Exercise 37.2 — Scope Cut

List every feature in your game. Cut 40%. Defend every cut.

Sample Answer (for our progressive project):

Original feature list (partial): 1. Player movement (keep) 2. Attack (keep) 3. Dash (keep) 4. Wall-jump (CUT — nice but not essential; Ch. 17 level can be re-designed without it) 5. Enemy AI (keep) 6. Boss AI (keep) 7. Inventory (keep) 8. Shop NPC (keep) 9. Multiple weapons (CUT — one weapon with upgrades instead) 10. Skill tree (keep — modest, 8 nodes) 11. Crafting system (CUT — out of scope for first game) 12. Cooking system (CUT — we are not Breath of the Wild) 13. Pet companion (CUT — adds AI complexity we do not need) 14. Two hub towns (CUT to one) 15. Day/night cycle (CUT — visual polish only) 16. Weather system (CUT — visual polish only) 17. Dialogue system (keep — 2 NPCs) 18. Environmental storytelling (keep) 19. Boss fight (keep) 20. Post-credits secret (CUT — after ship, maybe)

Defense summary:

• Wall-jump is great but it is a vertical-traversal feature that demands level design around it. Without it, we ship sooner.
• Multiple weapons means balancing multiple movesets, which means playtesting combinatorially. Not for Book 1.
• Day/night and weather are polish, not mechanics. They matter only in the top 20% of any game's final shine.
• Pet companion introduces AI we have not designed. The cost is not the pet; it is every place in every level where the pet could be in the way.

The pattern: cut anything that multiplies rather than adds. A weapon is additive. A second weapon means balance-testing against everything. Cut the multiplier.

The general rule from Ch. 37: every feature has a hidden cost. Every feature you cut is time you did not realize you needed.

Chapter 40: Capstone

Exercise 40.1 — Write a Post-Mortem

Write a 1,000-word post-mortem of your project. What went right, what went wrong, what did you learn?

Sample Answer — Critique rubric (this is uniquely yours — I can describe what a strong one looks like):

A strong post-mortem is honest in four dimensions. Most new designers nail two and skip two.

(1) What went right. The easy one. List 3–5 things. Be specific. "The core loop works" is too vague. "Playtesters spent 40+ minutes without wanting to stop; the cycle of fight → upgrade → explore kept them engaged without explicit session goals" is specific.

(2) What went wrong. Most post-mortems are honest here for about 2 items and then soften. Push further. List 5–8 things. Include things that did not ruin the project but meaningfully hurt. "The dialogue system ate three weeks for two conversations' worth of content." "I implemented save/load twice because I did not plan the serialization format."

(3) What I learned about the craft. The hardest dimension. Not "I learned Godot." What did you learn about designing games themselves that you did not know before? "I learned that my first pass at any mechanic is always 30% too generous — I have to take power away in the second pass." That kind of thing.

(4) What I learned about myself. Often skipped. Did you learn that you are better at systems than at narrative? That you dread playtesting but need it most? That your natural instinct is to add features, and scope control is a discipline you must practice?

A weak post-mortem: - Praises what went right, skims what went wrong, draws vague conclusions. - Blames external factors. - Ends with "I can't wait to make my next game!" without specifying what that next game will do differently.

A strong post-mortem: - Admits its author's specific errors and tendencies. - Names concrete changes it will make next time. - Reads like a letter from the version of you who finished the project to the version of you who is about to start the next one.

Jason Schreier's Blood, Sweat, and Pixels is full of reported post-mortems. Read three of those chapters. Notice the honesty. Notice the specific detail. That is your model.

And: when you finish your post-mortem, save it. In two years, go back and read it. You will laugh at some things, wince at others, and notice how much you have grown. That is the only real purpose of a post-mortem — a gift you write to your future self.

A Final Word on Answers

These answers are one designer's approach. Yours may be different and still correct. The working-designer's instinct is to be opinionated and specific; the student's instinct is often to be generic and defensible. Push past generic. A design answer that could apply to any game applies to no game.

When you submit an exercise and it is returned with notes, the note you are hoping to avoid is "be more specific." When you see that note, go back and replace every abstract claim with a concrete one. "The mechanic is balanced" becomes "the mechanic is balanced against enemies with 20–40 HP, but is underpowered against the 80-HP mid-boss because its cooldown is 3.5s while the boss's invulnerability window is 4.0s." That is the difference between student work and designer work.

Write like a designer. Your future team will know the difference.