Chapter 30 — Exercises

These exercises will retrain your ears. Do them seriously. The temptation, after a chapter as long as the previous one, is to skim the exercises and move on. Resist it. The whole point of audio design is that it is invisible until you put your attention on it. These exercises are the attention. Without them, you will read this chapter and remain audio-illiterate. With them, you will start to hear games — and your own work — at a level you did not know was possible.

Each section has a target time, a clear deliverable, and a self-grading rubric. Do them in order. The Analysis exercises are warm-up; the Design exercise is the core craft work; the Implementation exercise extends your project; the Critical exercise sharpens diagnostic muscle.

Exercise 1 — Analysis: The Mute Test on Two Games

Target time: 90 minutes (45 per game). Deliverable: Two short essays (300–500 words each).

Pick two games whose audio you have never consciously analyzed. They should be different from one another in genre and scale. Suggested pairings:

  • Hollow Knight and Hades
  • Celeste and DOOM (2016)
  • Inside and Stardew Valley
  • Outer Wilds and Hotline Miami
  • Dead Cells and Disco Elysium
  • Risk of Rain 2 and Return of the Obra Dinn

For each game:

Step 1 — Mute test (15 minutes per game). Play with sound entirely off. Take notes on what you can and cannot tell. Specifically:

  • Can you tell when an enemy attack connects with you?
  • Can you tell when you hit an enemy?
  • Can you sense the energy of the current scene (is it tense, calm, climactic)?
  • Do menu interactions feel responsive or floaty?
  • Do environmental transitions feel meaningful or arbitrary?
  • Are you missing information that the game appears to expect you to have?

Step 2 — Audio-only test (15 minutes per game). Now turn the sound back on and close your eyes. Have a friend describe what is on screen, or use a screen reader, or simply listen. What does the audio alone tell you? Specifically:

  • What instrument or musical color is the score using? Why this choice?
  • Are there layered ambient elements? Can you name three?
  • When you take an action, what is the SFX stack (number of layers, attack/body/release character)?
  • What is the relationship between music and on-screen action — does the music respond to your inputs?
  • What sound, if removed, would most damage the experience?

Step 3 — Write up (15 minutes per game). A 300–500 word essay per game with the structure:

  1. What the mute test revealed. What was the game communicating through audio that visuals alone failed to? Be specific — name the moments.
  2. What the audio-only test revealed. What is the audio doing that you had been ignoring? Be specific — name the elements.
  3. One craft lesson you will take to your own project. A concrete technique, layering pattern, mix decision, or implementation choice you can steal.

Self-grading rubric: - (3 pts) Identified at least three audio elements you had previously ignored. - (3 pts) Connected one audio choice to a design intent (not "the music is good" — why it is good and what design problem it solves). - (2 pts) Took away a concrete technique to apply to your project. - (2 pts) Avoided generic praise or vague description.

The first time you do this exercise, you will be surprised how much audio you have been processing pre-consciously. The second time you do it, you will start to hear new things on first play of any new game. This is what audio fluency feels like, and it begins here.

Exercise 2 — Design: The Survival Horror Audio Spec

Target time: 3 hours. Deliverable: A two-page audio design document for a single survival-horror scene.

You are designing audio for a single scene in a survival-horror game. The setup:

The player is a low-light flashlight-only investigator in an abandoned hospital basement. They are searching for a missing child. They do not yet know that something is hunting them. The scene begins as they descend the stairs into the basement, lasts approximately seven minutes if the player explores carefully, and ends either with the player finding a critical clue and escaping back upstairs, or with the player being grabbed by the unseen hunter and the screen going to black.

Produce an audio design document covering:

Section 1 — Ambient layers

List every ambient bed in the scene. For each, specify: - Source (what does it represent — fluorescent buzz, ventilation, distant water, distant traffic above). - Loudness (in rough dB or relative terms — "primary bed at -18 dB, secondary at -28"). - Looping behavior (continuous loop, randomized one-shots, layered crossfade triggered by player position). - Mix changes during the scene (e.g., does any ambient shift when the hunter activates?).

You want at least four ambient elements, mixed in a way that produces a consistent sonic identity for "abandoned hospital basement."

Section 2 — Music spec

Design the musical arc of the scene: - Opening (descent and early exploration). Is there music at all? If so, what character — drone, sparse piano, low strings? At what loudness? - Mid-scene (after the player has been exploring for ~3 minutes without incident). Does the music evolve? How? - Hunter activation (the player triggers the hunter's awareness — by entering a specific room, breaking line of sight to a specific object, or simply by elapsed time). How does the music respond? What technique — vertical layering, state-machine cue, hard cut to silence? - Chase or hide (if the hunter detects the player). What does the music do during pursuit, and what during a successful hide? - Resolution (clue-find escape vs. caught-and-screen-fades). Different musical handling for each ending.

Specify the technique you would use (single linear cue, state machine, layered stems) and why.

Section 3 — SFX list

Enumerate every SFX in the scene. For each, specify: - Trigger event. - Approximate duration. - Stack (single sample, or layered — and if layered, what layers). - Pitch variance and randomization rules. - Spatialization (mono UI / 2D positional / 3D positional with reverb). - Caption text (what would appear in subtitles if subtitles are on).

You should have at least 25 SFX entries. A non-exhaustive starting list: footsteps (multiple surface types), flashlight click, flashlight battery whine, door creaks (multiple), distant water drip, breathing (player), heartbeat (intensity-driven), papers shuffle, drawer open/close, key turn, whispered voice (was that real?), distant clatter, hunter footsteps (when active), hunter breathing (when nearby), hunter vocalization (attack), grab (game-over).

Section 4 — Voice

Decide your VO approach. Options: - No VO. The player and hunter are silent; story is told via found documents and environmental detail. - Minimal VO. Player has occasional muttered observations; hunter has growls; no other voice. - Full VO. Player is voiced; found documents are voiced as audio logs; hunter has full vocal performance.

Pick one and justify it. List every VO line you would record (or every audio log entry, if going document-based).

Section 5 — Mix and accessibility

How does the mix shift during the scene? Specifically: - Does ambient duck during the rare music swells? - Does music duck during VO? - Are there moments of intentional silence? When and why? - What captions are available? How do they handle non-dialogue SFX? - What controls are exposed (master / music / SFX / voice / ambient sliders, mono option, subtitle controls)?

Self-grading rubric: - (5 pts) Spec is specific enough that a sound designer could begin work without further questions. - (4 pts) Music technique justified (not "I'd use Wwise" — why a state machine vs. layered stems for this scene). - (4 pts) Ambient is layered (multiple beds), not single-loop. - (4 pts) SFX list demonstrates layering and variance thinking. - (3 pts) Accessibility is real (specific captions, real toggles), not boilerplate.

This exercise is the practical core of the chapter. If you can write this document, you have absorbed the framework. If you cannot, re-read the chapter and try again. Designers who can produce specs like this earn audio collaborators' respect immediately. Designers who cannot send their composers and sound designers wandering for weeks looking for the design intent.

Exercise 3 — Implementation: Extend AudioManager with Real Ducking

Target time: 2 hours. Deliverable: A working extension of AudioManager.gd that handles ducking automatically for VO, with a small demo scene.

The chapter introduced a manual ducking pattern (duck_music() / unduck_music()). That works, but it is fragile — you have to remember to call it in every dialogue path, and if you forget, your dialogue plays over un-ducked music.

Build a smarter version. Requirements:

  1. Automatic VO detection. Add a play_voice(stream) method to AudioManager.gd that plays the voice line on the Voice bus and automatically ducks the music for the duration of the line, restoring after. The caller should not have to remember to duck.

  2. Stacked ducking. If two VO lines play in rapid succession (line ends, next begins within 0.5 seconds), the music should stay ducked through both rather than ducking-up-ducking-down between them. This is a state-tracking problem: count active VO lines, only un-duck when count returns to zero.

  3. Configurable duck depth. The play_voice method should accept an optional duck_db parameter (default -12 dB) so different scenes can use different ducking depths — a quiet-conversation scene might only duck -6 dB, while a chase-with-screamed-instruction might duck -20.

  4. Optional duck of ambient too. Some scenes (intimate dialogue) want ambient to duck along with music. Some (action) want ambient to keep playing through dialogue. Add a parameter duck_ambient: bool = false to control this.

  5. Demo scene. Create a small Godot scene with a button labeled "Play VO." When pressed, it plays a 5-second voice line. Pressing it twice rapidly should stack-duck (no flicker). Add a checkbox toggling ambient ducking. Play music and ambient continuously and demonstrate the system with screen recordings.

Skeleton to extend:

# Add to AudioManager.gd
var active_voice_count := 0
var voice_player: AudioStreamPlayer

func _ready_voice_init() -> void:
    voice_player = AudioStreamPlayer.new()
    voice_player.bus = "Voice"
    add_child(voice_player)
    voice_player.finished.connect(_on_voice_finished)

func play_voice(stream: AudioStream, duck_db: float = -12.0,
                duck_ambient: bool = false) -> void:
    # Your implementation here
    pass

func _on_voice_finished() -> void:
    # Your implementation here
    pass

Hints:

  • Use a one-shot timer to debounce the un-duck (wait 0.5 seconds after the last VO line before raising music).
  • Track current and target volumes per bus separately so you can interrupt and resume tweens cleanly.
  • Test the rapid-fire case explicitly. If your code has a bug, it will manifest as music briefly flickering up between back-to-back lines.

Self-grading rubric: - (5 pts) play_voice works with a single line — music ducks, voice plays, music returns. - (5 pts) Stacked ducking works — two rapid lines do not produce a music flicker. - (3 pts) Configurable duck depth works. - (3 pts) Optional ambient ducking works. - (4 pts) Demo scene clearly demonstrates all features.

Bonus (+5 pts): Add a side-chain approximation. Instead of a fixed -12 dB drop, attach an AudioEffectCompressor to the Music bus with the Voice bus as its sidechain input. When voice plays, the compressor automatically reduces music. This is closer to professional mixing practice and produces a more natural sound. This is a Godot middleware-esque feature and worth learning.

Exercise 4 — Critical: Diagnose a Game Whose Audio Annoyed You

Target time: 60 minutes. Deliverable: A 500–700 word diagnostic write-up.

Pick a game whose audio you actively disliked. This could be a major release with mixing issues, an indie game with thin SFX, a free-to-play with grating UI sounds, an old favorite whose audio has aged badly, anything. The only requirement is that you remember being annoyed.

Open the game (or watch a let's-play video if you no longer own it). Listen with intent. Then write up:

Section 1 — Locate the failure

Be specific. Where in the audio stack did the failure occur?

  • Was it an SFX problem (wrong sample, no variance, too compressed, too loud)?
  • A music problem (one track for too long, wrong tonal choice for the scene, no dynamic system, abrupt transitions)?
  • A voice problem (bad cast, bad direction, bad mix, missing ducking)?
  • An ambient problem (no ambient at all, single-loop ambient, wrong tonal character)?
  • A mix problem (dialogue lost under music, SFX hurts, ambient inaudible, no headroom)?
  • An accessibility problem (no subtitles, no separate sliders, no mono option)?

Often the answer is "multiple things." Name each one specifically. "The hit SFX was the same single sample played hundreds of times per fight, with no pitch variance, which made every fight feel mechanical." Not "the audio was bad."

Section 2 — Diagnose the cause

Make an informed guess about why the failure happened. This is speculative but useful — it forces you to think about production realities:

  • Was it a budget issue (audio was cut to save money)?
  • A pipeline issue (sound design happened too late to fix the underlying problem)?
  • An ownership issue (no one was specifically responsible for audio decisions)?
  • A talent issue (the audio team did not have the experience for this scope)?
  • A design issue (the game's design did not give audio enough to work with)?
  • A platform issue (the game was mixed for a specific platform that didn't match the player's setup)?

You will not know the answer. Make a hypothesis. The exercise of hypothesizing builds production literacy.

Section 3 — Propose the fix

If you were in charge of an audio re-pass for this game, what would you do? Be specific:

  • Which SFX would you re-record or replace?
  • What changes to the music system?
  • What mix-pass priorities (which buses go up, which go down)?
  • What accessibility additions?
  • What is the highest-impact, lowest-cost change — the one thing you would do first?

Section 4 — Generalize

What pattern does this failure represent that you have seen elsewhere? Audio failures are often family resemblances of one or two underlying causes. Naming the family makes you faster at diagnosing the next instance.

Self-grading rubric: - (4 pts) Located the failure with specific moments and specific audio elements named. - (4 pts) Plausible causal hypothesis (production reality, not "audio team was bad"). - (4 pts) Concrete proposed fix with priorities. - (3 pts) Generalized to a pattern you can recognize in other games.

This exercise builds the diagnostic muscle that distinguishes designers who hear audio from designers who do not. When a future playtester says "the combat feels off," your first hypothesis should not be "we need more particles" — it should be audio first. This exercise is how you build that instinct.

Exercise 5 — Bonus: The Original SFX Recording Sprint

Target time: 4 hours including travel and recording. Deliverable: A small library of 10 original SFX, mastered and ready to import.

Optional but transformative. Spend an afternoon recording your own SFX with whatever microphone you have — a phone is fine, a USB mic is better. Build a library of ten original SFX, each tied to a need in your project:

  1. Footsteps on at least two surface types (gravel/concrete + wood/grass).
  2. A weapon swing (stick, broom, ruler, anything).
  3. A weapon impact (hit a pillow, a punching bag, a backpack).
  4. A door creak (an actual door in your house).
  5. A pickup chime (something with a clear pitch — a metal bowl, a glass).
  6. A UI click (snap your fingers, click a pen, tap a key).
  7. An ambient bed (record 30 seconds of your room, or your street, or a cafe).
  8. A negative feedback (a sigh, a wet flop, a fail buzz from your mouth).
  9. A positive feedback (a hum, a bell, a small laugh).
  10. A creature vocalization (whatever you can produce with your voice — pitch-shifted later for a monster, kept natural for a character).

Edit each in Audacity or Reaper: - Trim silence. - Normalize to -6 dB. - Apply a high-pass filter to remove hum (cut everything below 80 Hz). - Save as 44.1 kHz mono WAV (or stereo for ambient).

Import them into your Godot project. Replace at least three of your placeholder SFX with these originals. Play with them, tune them, layer two of them together for one composite SFX.

The goal is not perfection. The goal is to understand that you can do this. Once you have recorded ten SFX, you stop being a person who can only use library samples; you become a person who can choose between library and original. That choice is the foundation of an audio voice.

Self-grading rubric: - (3 pts) Ten distinct SFX recorded. - (3 pts) All edited (trimmed, normalized, filtered). - (2 pts) At least three integrated into your project, replacing placeholders. - (2 pts) At least one composite (two of your originals layered into a third sound).

When you have done this, you will never look at an SFX again the same way. Some of your favorite games' best sounds were made by a person in a closet recording a kitchen utensil. You can do that too. The mystique evaporates the first time.

Synthesis

If you have done all five exercises, you have:

  • Listened to two games as a designer rather than a player (Exercises 1).
  • Specified a complete audio design (Exercise 2).
  • Implemented a production-grade ducking system (Exercise 3).
  • Diagnosed a real audio failure (Exercise 4).
  • Recorded original SFX (Exercise 5).

This is more audio practice than most working designers do in a year. Your audio fluency, after this, will outpace most of your peers. Use it. The next time someone on your team says "the feel is off," you will be the one who diagnoses the SFX layering problem in fifteen minutes while everyone else is still arguing about screen shake. That is the value. That is why this chapter exists.

Move on to Chapter 31 with audio fully on the table — because in playtesting, audio is the single channel that produces the most "I don't know what's wrong but something is wrong" feedback, and you will need every one of these tools to interpret what your players are telling you.