SuperAPI AI Directory

designing-retro-arcade-sound-kits

Design & creation

View repository

Updated 10-15 11:58

About this skill

Use this skill to design a compact, era-authentic arcade sound kit and prove it stays event-like rather than turning into background music. It assumes an event-boundary architecture: game logic emits abstract event names and a separate audio layer resolves each event to a program and plays it.

Core Rules

  • Event boundary. Game code emits abstract event names (e.g. emit("laser")); it never instantiates or calls the synth directly. The audio layer owns the event -> program mapping and playback.
  • Design from gameplay moments, not synth presets. List the moments the player must hear first, then decide which need sound.
  • Classify each moment as SE, jingle, or nothing. Do not give every state transition a sound.
    • SE = short, repeated gameplay feedback: player actions (shot, dash, place, rotate, confirm), consequences (hit, block, collect, miss, split, capture), warnings (low timer, nearby threat, invalid move), and ambient events that affect play (spawn, wave step).
    • Jingle = rare state changes that should read as a musical phrase: start/ready, bonus or major reward, wave/stage clear, danger entering a new phase, final miss / game over.
  • Keep it readable under load. Repeated SEs must stay distinct when several fire in one frame; rare jingles must not mask player-control feedback.
  • Write a one-line sound target before coding each sound (e.g. // wave clear: rising 5-note glassy arpeggio). Author to the target, not to whatever the synth happens to produce.
  • Per-game identity. Each game ships its own kit; do not reuse a sample kit unchanged, and derive variants from your own programs, not from another game's.
  • Era authenticity. Recombine a fixed primitive set (oscillators, LFSR/metallic noise, distortion, bit-crush) through one fixed, clamped master chain. Add no new synth primitives, no samples, no long modern tracks. The fixed master chain is what keeps the "1980 board" character regardless of how a kit is built.

Workflow

  1. List the moments the player must hear from the game design.
  2. Classify each moment as SE / jingle / none.
  3. Write a one-line sound target for each chosen sound.
  4. Choose event names: reuse shared cabinet vocabulary when it fits (coin/start/hit/warning/jingle:bonus); use game-specific names (gun:fire, window:clean) when they make the code clearer, and map them to local programs via aliases.
  5. Author each program from the primitive set; set a clamped master tone for the kit.
  6. Validate against the budget and loudness checks below before finishing.

Validation (required)

A sound kit is not done until these pass:

  • Budget, enforced by an automated test. Cap SFX and jingle length and step count so SEs cannot drift into background music. Starting caps: SFX <= ~0.6s, jingles <= ~1.6s, <= ~24 steps per program. Wire this into the test suite, not just a manual check.
  • Relative loudness. Tune each SE against its sibling events in the same kit, not in isolation. Foreground actions (shots, hits, warnings) must stay readable during play; cabinet chimes (coin/start/game-over) sit slightly behind foreground play. The most frequent feedback sound (a pickup, a step, a shot) is the one most often buried: compare it directly against the music or engine bed it plays over, and give it its own register if it cannot clear the bed on level alone.
  • Demo/attract muting. Attract-mode sounds pass a demo flag (or equivalent) so they can be suppressed by a demo-sound setting.
  • Output level, measured. Render or capture each sound through the real output chain and check its peak; a kit whose ordinary sounds peak at a few percent of full scale is inaudible, and a conservative master gain is the usual cause. Aim the loudest event near, but below, the clipping ceiling and let the others take their places under it. A dynamics compressor used as a limiter ducks short sounds far more than long ones; measure through it, or use a clipper that only rounds peaks.
  • Pitch set. When the game also has music, decide per event whether it is meant to sit in the music's key. Mark those that are (typically frequent feedback and reward sounds) and assert that their pitches, including chain or level variants, belong to the scale; a step that rises by a fixed interval drifts out of key unintentionally, so step such sounds along the scale. Dissonance, chromatic rises, and alarms are legitimate choices: declare them as intended exceptions with a one-line reason instead of forcing them into the scale. The test catches undeclared clashes, not deliberate ones.
  • Safety. With aggressive distortion/noise programs, audition at low speaker/headphone volume. Safety governs how you listen, not how quiet the kit is.

References

  • references/sound-kit-reference.md — SE-vs-jingle table, starting loudness ranges, budget caps, and a generalized worked kit example. Read when authoring a kit.
  • references/reference-implementation.md — one concrete realization of the event-boundary runtime (the four layers, program-as-data, fixed clamped master chain, bus-level guards, mock-adapter testing, data-driven validation). Read when building or evaluating the system that plays the kits, not when authoring a single kit.