Chapter 8 Exercises: Feedback Systems

Exercise 1: Juice a Flat Prototype

Type: Implementation
Time: 60-90 minutes
Deliverable: Before-and-after video of a juiced prototype

Start with the flattest possible prototype. If you have your progressive project from Chapter 7 without any juice, use that. If not, create a minimal scene: a character that moves, an enemy that can be hit, and a collectible item. The prototype should work --- the enemy should take damage, the item should be picked up --- but it should have zero feedback beyond the basic state change.

Record a 15-second video of the un-juiced prototype. Then add the following, one at a time, in order:

1. Damage flash on the enemy when hit (white modulate for 80ms)
2. Hit sound on attack impact (use SFXR or BFXR to generate a procedural hit sound)
3. Screen shake on hit (intensity 6-8, decay 5.0)
4. Hit freeze on impact (40-60ms)
5. Particles on enemy death (12 particles, short lifetime, gravity-affected)
6. Pickup sound and pickup particles on item collection (8 particles, float upward)
7. Health bar with ghost/trail bar for the player

After each addition, play the game for 30 seconds and note how the feel changes. Does the game feel progressively more satisfying? At which addition did the biggest qualitative shift occur?

Record a 15-second video of the fully juiced prototype. Compare the two videos. Write a half-page reflection on what changed. The mechanics are identical in both videos --- the only difference is feedback.

What this teaches you: The before-and-after comparison makes the value of juice viscerally obvious. You will never ship an un-juiced game again after seeing the difference.

Exercise 2: Feedback Audit of a Favorite Game

Type: Analytical / Observational
Time: 45-60 minutes
Deliverable: Complete feedback inventory table and written analysis

Choose a game you consider to have excellent game feel. (Celeste, Hades, Dead Cells, Hollow Knight, Ori and the Blind Forest, Katana Zero, Hyper Light Drifter, DOOM 2016, Devil May Cry 5, and Returnal are strong candidates.)

Play for 15 minutes. Focus entirely on feedback. For the game's primary action (attack, jump, dash --- whatever the core verb is), catalog every single piece of feedback the game produces for that action:

After completing the inventory:

1. Count the total feedback elements for a single instance of the primary action. If the game has excellent game feel, expect 8-15 elements per action.

2. Identify the hierarchy. Which elements are present for every hit (baseline feedback)? Which appear only for special hits --- critical hits, combo finishers, kills? How does the game escalate feedback for higher-importance events?

3. Run the mute test. Mute the game and perform the primary action ten times. Which feedback elements did you lose? Can you still play effectively? Rate the visual-only experience from 1-5.

4. Run the invisible test. Close your eyes and perform the primary action ten times (if the game allows this safely). Can you tell when your attack landed? Rate the audio-only experience from 1-5.

5. Identify the MVP feedback element. If you could keep only ONE piece of feedback and remove all others, which would you keep? Why?

Write a one-page analysis explaining what makes this game's feedback effective. What principle connects all the individual elements? What could your progressive project learn from this game's approach?

What this teaches you: Deliberate observation of professional feedback design builds your vocabulary and your standards. You cannot design what you cannot see, and most players never see feedback because it is designed to be invisible. This exercise makes the invisible visible.

Exercise 3: Implement Screen Shake

Type: Implementation
Time: 30-40 minutes
Deliverable: Godot project with three levels of screen shake

Implement the ScreenShake.gd script from Section 8.7 in your progressive project or a test scene. Then create three different shake configurations:

1. Light shake: intensity 3-5, decay 6.0. Use this for minor impacts (landing after a jump, bumping into a wall). The shake should be barely perceptible --- the player feels it more than sees it.

2. Medium shake: intensity 8-12, decay 5.0. Use this for combat impacts (hitting an enemy, being hit by an enemy). This should be clearly visible but not disorienting.

3. Heavy shake: intensity 16-25, decay 3.0. Use this for dramatic moments (explosion, boss entrance, critical hit). This should feel like the screen is being punched.

Create three test triggers (three buttons or three collision areas) that fire each shake level. Play with each one. Adjust the values until:

• The light shake is just barely noticeable
• The medium shake feels satisfying without being annoying
• The heavy shake feels dramatic and is clearly different from medium

Then try these experiments:

• Fire two medium shakes in rapid succession. Does the max() behavior work correctly? (The second shake should not reduce the first if the first is still stronger.)
• Fire a light shake during a heavy shake. Does the light shake interfere? (It should not --- max() should prevent this.)
• Fire a heavy shake with a very slow decay (1.5). How does prolonged shaking feel? At what point does it become nauseating?

Write down the final values you chose for each level. These are your project's shake parameters going forward.

What this teaches you: Tuning is the core skill of juice implementation. The code is trivial. Finding the right values is the real work. This exercise forces you to tune deliberately rather than accepting default values.

Exercise 4: The Mute Test

Type: Experiential / Diagnostic
Time: 25-30 minutes
Deliverable: Diagnostic report and fix list

Choose three games from your library. For each game, play for 5 minutes with the sound completely muted. (Do not just turn down the volume --- mute it entirely. Turn off speakers. Remove headphones. You must not hear any audio at all.)

For each game, answer:

1. Can you tell when your primary action succeeds? (Attack lands, jump reaches platform, shot hits target.) Rate 1-5. If less than 3, identify specifically what visual feedback is missing.

2. Can you tell when you are in danger? (Health is low, enemy is attacking, timer is running out.) Rate 1-5. What audio cues are you missing? Are there visual replacements?

3. Can you tell when you pick up items or resources? Rate 1-5. Is the collection feedback purely audio, or is there a visual component?

4. Can you distinguish between different types of events? (Weak hit vs. strong hit, normal enemy vs. elite enemy, common item vs. rare item.) Rate 1-5.

5. Overall, how much worse is the experience on mute? Rate the degradation on a scale from "barely worse" (1) to "unplayable" (5).

After testing all three games, rank them by mute-test performance. The game that works best on mute has the strongest visual feedback design.

Now apply the mute test to your progressive project. Rate it on the same criteria. Identify the three weakest points --- the three situations where muting the audio causes the most information loss. For each weak point, propose a specific visual feedback addition that would address the gap.

What this teaches you: Audio carries more information than most designers realize. The mute test reveals exactly how much your game relies on sound, and whether that reliance is a strength (rich audio design) or a vulnerability (visual feedback gaps). Every critical event should be readable through at least two channels.

Exercise 5: Feedback Magnitude Mapping

Type: Design / Analytical
Time: 30-40 minutes
Deliverable: Feedback magnitude chart for your progressive project

List every event in your progressive project that currently produces (or should produce) feedback. Organize them into a magnitude chart:

Rules:

1. No two events with different importance levels should have identical feedback. If a coin pickup and an enemy kill produce the same screen shake, one of them is wrong.

2. Higher importance events should have strictly more feedback than lower importance events. You should be able to sort your table by importance and see the feedback columns increase monotonically.

3. At least two channels (visual + audio, visual + haptic, etc.) should be active for every event rated importance 3 or higher.

After completing the chart, identify:

• Any inversions where a low-importance event has more feedback than a high-importance event
• Any dead zones where an event has no feedback at all
• Any oversaturated tiers where too many events share the same feedback level, making them indistinguishable

Redesign the chart to fix any problems found.

What this teaches you: Feedback is a budget. You have a limited range of intensities (from "barely noticeable" to "screen-shaking spectacular"). If you spend your budget on low-importance events, you have nothing left for the moments that matter. Deliberate magnitude mapping prevents this.

Exercise 6: Hit Freeze Tuning Lab

Type: Implementation / Experiential
Time: 25-30 minutes
Deliverable: Tuned hit freeze implementation with documented values

Implement the hit freeze function from Section 8.8 in your progressive project. Then systematically test a range of freeze durations:

1. 16ms (1 frame at 60fps): Can you perceive it? Most players cannot. This is the threshold of perception.

2. 33ms (2 frames): Barely perceptible. A subtle "catch" in the action. Suitable for very fast, light attacks.

3. 50ms (3 frames): Clearly perceptible. The standard for normal melee attacks. This is your baseline.

4. 83ms (5 frames): Strong emphasis. Suitable for heavy attacks, charged attacks, or critical hits.

5. 117ms (7 frames): Very noticeable pause. Use only for the most impactful moments (boss kill, combo finisher).

6. 167ms (10 frames): Dramatically long. The game clearly stops. Use only for cinematic moments.

7. 250ms (15 frames): Too long. The player perceives this as a bug or a lag spike, not emphasis. This is the upper boundary of useful hit freeze.

For each duration, attack an enemy ten times. Rate the freeze on a 1-5 scale for: - Satisfaction: Does the freeze make the hit feel better? - Naturalness: Does the freeze feel like emphasis or like a bug? - Disruption: Does the freeze interrupt your flow?

Plot the three ratings on a chart. You should see satisfaction and naturalness peak around 50-80ms, then decline. Disruption should rise steadily after 100ms. The optimal freeze for your game is where satisfaction and naturalness are highest and disruption is lowest.

Write down your chosen values for normal attack, heavy attack, and kill shot. These are your project's freeze parameters going forward.

What this teaches you: Hit freeze values cannot be derived from theory. They must be felt. Two frames versus three frames is a difference you can only evaluate by experiencing it repeatedly. This exercise builds the physical intuition that no amount of reading can provide.

Exercise 7: The Feedback Sandwich

Type: Implementation
Time: 40-50 minutes
Deliverable: Complete feedback stack for one action

Choose the single most important player action in your progressive project (most likely the primary attack). Implement a complete feedback stack for that action, following the timing table from Section 8.20:

Layer 1 (0ms, Input confirmation): - Attack animation begins - Swing/activation sound plays

Layer 2 (~60ms, Impact): - Hit freeze (50-80ms) - Enemy damage flash - Impact particles at contact point - Impact sound - Controller rumble (if applicable)

Layer 3 (~120ms, Aftermath): - Screen shake (200ms decay) - Enemy knockback or stagger animation - Damage number appears (optional)

Layer 4 (~200ms, Resolution): - Enemy health bar updates - Shake decays - Damage number floats up and fades

Layer 5 (on kill only): - Death particles (more than hit particles) - Death sound (distinct from hit sound) - Brief slow-motion (optional) - XP/resource gain notification

Implement every layer. Test the complete stack at full speed. Then record and review at quarter speed to verify that the timing is correct and no layers are missing or out of order.

After the stack is complete, try removing each layer one at a time. Play without the damage flash. Play without the hit freeze. Play without particles. For each removal, rate how much the experience degrades on a 1-5 scale. This reveals which elements are carrying the most weight in your feedback stack.

What this teaches you: Feedback is not a list of independent effects. It is a sequence --- a carefully timed composition where each element enters at the right moment to create a unified impression. Building the stack deliberately and then testing removals teaches you which elements are essential and which are enhancement.

Exercise 8: Feedback Loop Type Identification

Type: Analytical
Time: 25-30 minutes
Deliverable: Annotated loop diagrams for three games

Choose three games that are currently in your library or that you have significant experience with. For each game, identify and diagram:

1. One positive feedback loop in the game. Draw the loop showing how success feeds more success. Label each connection with what flows along it (power, resources, access, information). Explain in 2-3 sentences why this positive loop is fun for the player who is winning and potentially frustrating for the player who is losing.

2. One negative feedback loop in the game (if present). Draw the loop showing how the system pushes back against the leader. Explain how it prevents the positive loop from becoming a runaway snowball. If the game has no negative feedback loop, explain what would happen if it did.

3. The balance point. On a spectrum from "pure positive feedback" to "pure negative feedback," where does this game fall? Is it closer to Monopoly (extreme positive, no catch-up) or Mario Kart (strong negative, heavy rubber-banding)? Explain why the designers chose this balance point, considering the game's genre, audience, and session length.

After completing all three games, compare the balance points. Is there a correlation between genre and feedback loop balance? (For example: do competitive multiplayer games tend toward negative feedback, while single-player power fantasies tend toward positive feedback?)

What this teaches you: Systemic feedback loops are the invisible architecture of game balance. Understanding them gives you a vocabulary for discussing why some games feel fair, why some feel frustrating, and why some feel like foregone conclusions. This analytical skill applies to every game you design.

Exercise 9: Accessibility Feedback Audit

Type: Design / Evaluation
Time: 30-35 minutes
Deliverable: Accessibility feedback audit report with action items

Audit your progressive project's feedback for accessibility across four dimensions:

Dimension 1: Visual impairment. Turn your monitor brightness to minimum. Can you still read all feedback? Are any feedback elements that rely entirely on color to communicate information? (A red damage flash is invisible to players with protanopia. A green-to-red health bar gradient is unreadable for players with red-green color blindness.) List all color-dependent feedback and propose a non-color alternative for each (pattern, shape, size, position, animation).

Dimension 2: Auditory impairment. Mute all audio. Can you still play effectively? For each audio-only feedback element, propose a visual alternative. Verify that the visual alternative is present and readable.

Dimension 3: Motor sensitivity. If a player has difficulty pressing buttons rapidly, which feedback elements become inaccessible? Are there time-sensitive feedback responses that could be extended? (For example: if input buffering allows a 100ms window, could it be extended to 200ms in an accessibility mode?)

Dimension 4: Photosensitivity. Are there any feedback elements that could trigger photosensitive epilepsy? Screen flashes, rapid alternation between bright and dark, and intense particle effects can all be triggering. Identify any potential triggers and propose options to reduce or disable them.

For each dimension, produce a list of action items rated by priority:

• Critical: Feedback is inaccessible and prevents gameplay. Fix immediately.
• High: Feedback is degraded and significantly impacts experience. Fix before release.
• Medium: Feedback is slightly worse but gameplay is unimpacted. Fix when possible.
• Low: Nice-to-have improvement. Add to backlog.

What this teaches you: Accessibility is not a checklist you complete after the game is finished. It is a design constraint that should inform every feedback decision from the start. Auditing early, during the prototype phase, prevents expensive retrofitting later. And the fixes you implement will often improve the experience for all players, not just those with specific accessibility needs.

Exercise 10: Sound Design from Scratch

Type: Creative / Implementation
Time: 35-45 minutes
Deliverable: Four original sound effects integrated into the progressive project

Create four sound effects for your progressive project using SFXR, BFXR, or ChipTone (all free, browser-based procedural sound generators). You are not looking for final-quality audio. You are looking for functional placeholder sounds that communicate the right information.

Generate the following:

1. Attack swing — the sound of the weapon moving through air. Should feel fast and sharp. Typical parameters: short duration (0.1-0.2s), high frequency, slight frequency sweep downward.

2. Hit impact — the sound of the weapon connecting with a target. Should feel weighty. Typical parameters: short duration with a bass thud, noise component for "crunch," slight sustain.

3. Item pickup — the sound of collecting something positive. Should feel rewarding and bright. Typical parameters: ascending pitch, short duration, bell-like or chime quality.

4. Player damage — the sound of the player being hurt. Should feel alarming. Typical parameters: low frequency impact, slight distortion, longer sustain than the hit impact, a quality that says "something bad happened to you specifically."

For each sound, generate at least five variations before choosing the best one. Then implement all four in your progressive project. Trigger each sound from the appropriate event handler.

Play the game with the new sounds for 5 minutes. Then mute the sounds and play for 2 minutes. The difference should be significant --- the sounds should be carrying real information and emotional weight that is absent when they are muted.

Stretch: Add pitch variation to the hit impact sound (random pitch between 0.9x and 1.1x on each play). Notice how the variation makes repeated hits sound more natural and less robotic.

What this teaches you: Sound design does not require expensive tools or professional training. Procedural sound generators can produce functional placeholder audio in minutes, and having any sound is dramatically better than having no sound. The gap between "no audio" and "placeholder audio" is much larger than the gap between "placeholder audio" and "professional audio."

Exercise 11: The Feedback Budget

Type: Design / Constraint
Time: 20-25 minutes
Deliverable: Constrained feedback design document

Design a complete feedback system for a game concept under the following constraints:

Constraint 1: You can only use THREE feedback elements total. Not three per action --- three for the entire game. A screen shake, a damage flash, and a sound effect, for example. That is your entire feedback budget.

Choose a simple game concept (a Flappy Bird-style game, a single-screen arena shooter, a basic platformer). Decide which three feedback elements you will use. Then design how those three elements will communicate:

• Hit confirmation
• Damage taken
• Death
• Score/collection
• Danger/warning

You will need to differentiate events using variations of your three elements (different shake intensities, different flash colors, different sound pitches) rather than adding new element types.

Write a one-page design document listing every event in the game and the exact feedback configuration (which of your three elements, at what intensity/duration/variation) for each.

Then: Relax the constraint to five elements. What two elements would you add? Which gaps in the three-element design are they filling?

Then: Relax to ten elements. What five more? At what point does adding more elements stop producing meaningful improvement?

What this teaches you: Constraints expose priorities. When you can only choose three feedback elements, you discover which ones are truly essential. This exercise reveals your personal hierarchy of feedback importance and helps you understand that a small number of well-chosen, well-tuned elements can do more than a dozen poorly chosen ones.

Exercise 12: Comparative Juice Analysis

Type: Analytical / Comparative
Time: 40-50 minutes
Deliverable: Side-by-side comparison with annotated screenshots or video

Choose two games in the same genre that have noticeably different levels of juice. Good pairs:

• Hollow Knight (high juice) vs. a generic indie Metroidvania (low juice)
• Nuclear Throne (extreme juice) vs. a standard top-down shooter (moderate juice)
• Celeste (high juice) vs. a typical indie platformer (moderate juice)
• Dead Cells (high juice) vs. an older Castlevania game (minimal juice)
• DOOM 2016 (extreme juice) vs. a military shooter like Insurgency (deliberate low juice)

For both games, perform the same action (attack an enemy, kill an enemy) and catalog every feedback element. Use the table format from Exercise 2:

Game A (high juice):

Game B (lower juice):

Compare the two tables. Answer:

1. How many more feedback elements does Game A have per action? Is the difference 2x? 3x? More?

2. Which specific elements does Game A have that Game B lacks? Are they visual, audio, or haptic?

3. Does Game B's lower juice level feel like a deficiency or a deliberate choice? (Some games, like Insurgency or Papers, Please, use minimal juice deliberately to create a specific tone --- mechanical, bureaucratic, realistic.)

4. Does Game A's high juice level ever become overwhelming? Is there a point where the juice hurts readability?

5. Which game would you rather play for 20 hours? Is your answer correlated with juice level? If not, what other factors matter more?

Write a one-page comparison arguing which game uses feedback more effectively (not which uses more feedback --- effectiveness is not the same as quantity).

What this teaches you: Juice is not universally "more is better." The right amount of juice depends on the game's tone, genre, and audience. Comparing high-juice and low-juice games in the same genre reveals when juice serves the design and when it might conflict with it. This nuance prevents the common beginner mistake of applying Vlambeer-level juice to a game that calls for restraint.