You are responsible for a comprehensive **game-audio, sound-design, soundscape, mixing, timing, and audio-presentation polish pass**.

Your job is to make the existing game sound:

- intentional;
- cohesive;
- responsive;
- atmospheric;
- readable;
- appropriately varied;
- well balanced;
- professionally finished rather than placeholder-like.

The primary question throughout this task is:

> **What currently makes the game sound empty, repetitive, weak, mistimed, inconsistent, cheap, noisy, unbalanced, or unfinished?**

Then fix those problems.

This is an **implementation task**, not merely an audio critique.

Do not stop after:

- identifying missing sounds;
- reporting poor timing;
- listing repetitive effects;
- recommending mix changes;
- describing ambience opportunities;
- producing an audio-polish backlog.

Inspect actual gameplay audio where practical.

Identify concrete weaknesses.

Trace each problem to its trigger, state, asset, routing, lifecycle, or mix relationship.

Implement worthwhile corrections.

Validate them in context.

Listen again.

Continue while meaningful, safely actionable audio-quality improvements remain.

Use continuously:

> **listen → identify weakness → trace trigger/state → implement → validate → listen again**

The goal is:

> **Leave behind the same game, but make it sound substantially more cohesive, responsive, atmospheric, readable, varied, balanced, and professionally produced.**

---

# Audio Supports the Game

Sound should communicate:

- action;
- impact;
- state;
- feedback;
- space;
- atmosphere;
- importance.

Do not add sound merely because an event exists.

Do not assume:

> **more sounds = better audio**

Professional game audio depends on:

- hierarchy;
- timing;
- contrast;
- restraint;
- repetition management;
- spatial logic;
- clear relationships between gameplay and sound.

Silence is valid.

Quiet moments are valid.

Not every interface event needs a click.

Not every combat action needs five layers.

---

# Preserve the Existing Audio Identity

Do not treat this task as permission to replace the game's sonic identity.

Preserve where intentional:

- soundtrack;
- sound-design style;
- tonal character;
- ambience philosophy;
- UI language;
- combat intensity;
- dynamic range;
- spatial model;
- middleware/audio architecture;
- gameplay timing.

Do not:

- replace the soundtrack;
- redesign the audio engine;
- migrate middleware without necessity;
- create huge amounts of unrelated new audio;
- change gameplay merely to make sound easier;
- turn a restrained game into an excessively noisy one.

Small additions or asset substitutions are allowed when they clearly fix a real presentation gap and fit the established style.

---

# Core Scope

Inspect only systems that actually exist.

Relevant areas may include:

## Movement

- footsteps;
- movement starts/stops;
- jumps;
- landings;
- climbing;
- traversal;
- mounts where present.

## Combat

- attacks;
- swings;
- releases;
- impacts;
- misses;
- blocks;
- parries;
- projectiles;
- abilities;
- spells;
- status effects;
- hit reactions;
- death.

## Gathering / Production

- mining;
- woodcutting;
- fishing;
- harvesting;
- crafting;
- smithing;
- cooking;
- production stations;
- completion feedback.

## World Interaction

- doors;
- chests;
- switches;
- pickups;
- containers;
- equipment;
- consumables;
- object activation.

## UI

- buttons;
- tabs;
- inventory actions;
- equip/use;
- confirmations;
- errors;
- notifications;
- menus;
- modal actions.

## Rewards / Progression

- XP;
- level-ups;
- rare loot;
- quest completion;
- achievements;
- unlocks;
- milestones.

## Characters

- NPCs;
- creatures;
- enemies;
- vocalizations where present;
- ambient character sounds.

## Environment

- towns;
- forests;
- caves;
- water;
- wind;
- weather;
- fire;
- machinery;
- wildlife;
- interiors;
- dungeons;
- environmental objects.

## Music

Where existing systems support it:

- exploration/combat transitions;
- region transitions;
- menus;
- state changes;
- fades;
- crossfades;
- loop handling.

## Technical Audio

- spatialization;
- attenuation;
- mixer/bus routing;
- volume relationships;
- concurrency;
- voice limits;
- lifecycle;
- loop cleanup;
- repeated playback;
- networking where relevant.

Only improve systems that exist.

---

# Explicitly Out of Scope

This is **not primarily**:

- a gameplay redesign;
- combat redesign;
- movement redesign;
- soundtrack replacement;
- full audio-engine rewrite;
- middleware migration;
- giant asset-production sprint;
- visual polish;
- UI redesign;
- broad game-feel redesign;
- technical-debt cleanup;
- repository cleanup.

Small adjacent changes are allowed when directly necessary to correct an audio defect.

Do not let them become unrelated workstreams.

---

# Preserve Gameplay Authority

Gameplay truth should remain authoritative.

Audio presents:

- attacks;
- impacts;
- rewards;
- interactions;
- state transitions.

Audio should not accidentally become a second gameplay-rules system unless the project deliberately uses audio events that way.

Be cautious when sound triggers are tied to:

- animation events;
- replicated messages;
- timers;
- state callbacks.

Do not move authoritative gameplay timing merely to make audio timing convenient.

Align presentation to gameplay truth.

---

# Preserve Existing Work

Before substantive modifications, inspect version-control state where available.

Do not:

- overwrite unrelated changes;
- revert unfamiliar work;
- delete ambiguous audio assets;
- replace mixer work without understanding it;
- remove disabled sounds without determining why they are disabled.

If existing modifications overlap this pass:

1. inspect them;
2. determine apparent purpose;
3. preserve that intent;
4. integrate carefully;
5. avoid broad replacement where a narrow correction is sufficient.

---

# Runtime Listening First

Audio quality must be judged in context.

Where practical, listen during actual gameplay.

Use:

- runtime play;
- editor preview;
- recorded gameplay;
- audio debugger/profiler;
- mixer/bus meters;
- logs;
- event tracing;
- spatial-audio debugging;
- multiplayer clients where applicable.

Do not judge the soundscape solely from:

- asset filenames;
- event names;
- code;
- mixer configuration.

Code alone cannot reliably reveal:

- annoying repetition;
- poor weight;
- timing mismatch;
- frequency masking;
- abrupt transitions;
- weak ambience;
- sounds dominating the mix.

If runtime playback is unavailable:

- state that limitation;
- use the strongest available evidence;
- do not claim a mix or timing issue was directly heard if it was only inferred.

---

# Investigate Before Asking Questions

Use the project as evidence.

Inspect relevant:

- audio assets;
- triggers;
- events;
- buses;
- mixers;
- audio sources/emitters;
- attenuation;
- concurrency;
- state logic;
- animation events;
- gameplay events;
- ambience zones;
- music state;
- prefabs/scenes;
- networking;
- settings;
- volume controls;
- sibling implementations.

Ask for clarification only when:

- intended sound identity cannot be established;
- several materially different audio directions are equally plausible;
- major new assets are required;
- gameplay timing would need to change;
- shared/networked audio authority is unclear;
- external middleware access is unavailable.

Do not ask questions merely because audio investigation takes effort.

---

# Implementation Over Critique

The review exists to produce an **implementation queue**.

Do not spend most of the task:

- cataloguing every sound;
- writing long subjective critiques;
- producing theoretical sound-design documents;
- listing every potentially silent event.

Once a meaningful weakness is sufficiently understood:

> **fix it.**

Then validate:

1. timing;
2. repetition;
3. volume relationship;
4. lifecycle;
5. relevant sibling events;
6. normal gameplay context.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports independent agents, workers, subprocesses, or fresh contexts, use them where they materially improve coverage.

Do not require delegation.

A single capable session must still be able to execute this task sequentially.

Good independent work areas may include:

- combat audio;
- movement;
- gathering/crafting;
- UI;
- rewards;
- ambience;
- spatial audio;
- music transitions;
- repetition audit.

Serialize changes involving shared:

- mixer buses;
- master volume hierarchy;
- global concurrency;
- audio manager;
- music state;
- shared middleware routing.

Do not let independent workstreams create incompatible mix philosophies.

Use additional fresh-context review for substantial shared audio changes.

---

# Audio Priority Queue

## P0 — Broken Audio

Examples:

- playback error;
- audio-trigger crash;
- runaway loop;
- uncontrolled repeated playback;
- severe audio spam;
- corrupted or invalid reference preventing functionality.

Fix immediately.

## P1 — Major Presentation Failure

Examples:

- common high-value action completely silent;
- major event badly mistimed;
- combat feedback missing;
- overwhelming mix;
- placeholder/default sound clearly exposed;
- critical loop never stops;
- major duplicated event.

Prioritize heavily.

## P2 — Significant Audio Polish

Examples:

- repetitive common sounds;
- weak impact;
- inconsistent levels;
- sparse ambience;
- awkward transitions;
- poor spatial attenuation;
- generic location soundscape.

Spend substantial effort here.

## P3 — Finishing Details

Examples:

- subtle variation;
- minor layering;
- small spatial detail;
- fine timing;
- final mix relationships.

Address after major issues.

---

# High-Frequency Audio First

Prioritize what players hear constantly.

Usually this includes some combination of:

- footsteps;
- common attacks;
- hits;
- gathering;
- inventory interactions;
- UI;
- ambience.

Use:

> **frequency × importance × severity**

as a rough priority model.

A rare cinematic event should not receive more attention than an irritating sound heard hundreds of times per hour.

---

# Event Coverage Pass

Identify high-frequency and high-importance gameplay events.

For each ask:

> **Should the player hear this?**

Sound is particularly useful when it improves:

- acknowledgement;
- impact;
- state understanding;
- spatial awareness;
- atmosphere;
- importance hierarchy.

Do not add audio merely because an event currently lacks it.

A silent event may be correct.

---

# Missing-Sound Hunt

Look for events that feel conspicuously incomplete because:

- equivalent actions have sound;
- animation clearly implies an impact;
- important state changes have no acknowledgement;
- location lacks expected environmental presence;
- player receives major reward with no feedback.

Before adding sound establish:

1. why it needs sound;
2. whether a suitable existing asset exists;
3. whether the project's sound language supports it.

Prefer existing assets where appropriate.

---

# Trigger Audit

For important sounds trace:

> **gameplay event → trigger → audio source/event → mixer/bus → playback → lifecycle**

Look for:

- trigger never called;
- trigger called twice;
- stale trigger;
- wrong event;
- wrong asset;
- source disabled;
- volume zero;
- parent bus muted;
- object destroyed before playback;
- trigger dependent on wrong state.

Fix the root trigger problem.

---

# Timing Pass

Audio should align with the event it represents.

Check:

- attack impact;
- weapon swing/release;
- projectile release;
- hit;
- gathering contact;
- crafting completion;
- loot pickup;
- level-up;
- button activation;
- door opening;
- world interactions.

Look for sound occurring:

- noticeably before the event;
- noticeably after the event;
- after the action has already transitioned;
- on animation start when impact happens later.

Fix visible/audible mismatch.

---

# Gameplay Event Versus Animation Event

Determine whether audio is best triggered by:

- gameplay event;
- animation event;
- replicated state;
- presentation state.

Examples:

A footstep may appropriately follow animation timing.

A server-authoritative reward sound may be safer when triggered by confirmed reward state.

Do not move everything to one trigger model.

Use the event source that best represents the intended sound.

---

# Combat Audio Pass

Inspect:

> **attack → impact → result**

Differentiate where appropriate:

- swing/release;
- hit;
- miss;
- block;
- parry;
- critical impact;
- projectile;
- death;
- ability activation.

Do not require every combat action to use all of these.

Use only what the game's combat language supports.

---

# Attack / Swing Audio

Inspect whether weapon action sounds:

- align with motion;
- match weapon weight/style;
- occur only when intended;
- become repetitive;
- compete with impact sound.

Do not make the swing louder than the actual impact without clear stylistic reason.

---

# Impact Audio

Impacts should communicate:

- contact;
- weight;
- material;
- importance.

Look for impacts that:

- sound weak relative to visuals;
- trigger late;
- trigger twice;
- use identical sound for every result;
- overwhelm everything else.

Use layering carefully.

More layers do not automatically create stronger impact.

---

# Hit / Miss Differentiation

Where gameplay benefits from it, distinguish:

- hit;
- miss;
- block;
- immune/invalid result.

Do not create unnecessary variation if visual feedback already carries the distinction and audio would become cluttered.

Important informational sounds should remain recognizable.

---

# Death Audio

Inspect:

- death trigger;
- timing;
- repeated playback;
- overlap with hit sound;
- corpse/despawn lifecycle.

Avoid:

- death sound firing twice;
- death audio after entity disappears;
- routine hit sounds masking lethal moment.

Use weight appropriate to event importance.

---

# Ability / Spell Audio

For abilities inspect:

- activation;
- windup;
- release;
- projectile;
- impact;
- persistent effect;
- completion.

Ensure sounds align with actual action lifecycle.

Look for:

- looping cast never stopping;
- impact before projectile arrives;
- effect continuing after cancellation;
- every ability occupying the same sonic range.

Preserve existing identity.

---

# Movement & Footstep Pass

If footsteps exist, inspect:

- cadence;
- animation synchronization;
- start/stop;
- movement speed;
- repeated identical samples;
- volume;
- distance attenuation.

Look for:

- footsteps while stationary;
- missing footsteps while moving;
- double footsteps from overlapping systems;
- cadence drifting from animation;
- remote players producing excessive footstep noise.

---

# Surface Variation

If the project already supports surface-aware footsteps, validate:

- correct surface detection;
- sensible variation;
- transitions;
- fallback behavior.

Do not build a complex terrain-material system solely for footsteps unless current implementation clearly requires it.

If no surface system exists, subtle sample variation may provide more value than large new infrastructure.

---

# Footstep Repetition

Footsteps are extremely repetitive.

Use appropriate existing mechanisms such as:

- sample pools;
- subtle pitch variation;
- subtle volume variation;
- controlled randomness.

Avoid extreme randomization.

The player should hear variation, not chaos.

---

# Gathering Audio Pass

Repeated gathering actions may occur for long periods.

Inspect relevant:

- mining;
- woodcutting;
- fishing;
- harvesting;
- gathering.

Check:

- action initiation;
- tool swing;
- contact;
- result;
- depletion;
- completion;
- repetition.

Look for:

- missing impact;
- mistimed impact;
- repetitive sample fatigue;
- overlapping sounds from repeated action;
- sound continuing after resource disappears.

---

# Production / Crafting Audio

Inspect:

- station ambience;
- action loop;
- completion;
- failure;
- cancellation;
- repeated production.

Avoid:

- constant high-volume looping;
- completion sound on every tiny sub-action;
- loops surviving after crafting ends.

---

# Repetition Hunt

Repeated identical samples reveal low production quality quickly.

Identify high-frequency sounds.

Possible techniques include:

- existing alternate samples;
- small pitch variation;
- small volume variation;
- playback cooldown;
- randomized selection pools;
- context-sensitive selection.

Use variation subtly.

Do not randomize important informational sounds until they become unrecognizable.

---

# Repetition Fatigue Test

For common actions, deliberately repeat them many times.

Ask:

> **Does this become irritating after 10 repetitions?**

Then:

> **What about 100?**

High-frequency audio should survive long play sessions.

Fix:

- sharp frequencies;
- excessive loudness;
- identical repeated transients;
- unnecessary layering;
- overly long tails.

---

# UI Audio Pass

Inspect important:

- button activation;
- tabs;
- inventory movement;
- equip/use;
- purchase;
- confirmation;
- cancellation;
- error;
- notification.

Equivalent controls should use a coherent audio language.

A UI should sound like one interface rather than unrelated sound packs.

---

# UI Hierarchy

Not every UI action deserves equal sonic weight.

Possible hierarchy:

## Routine

- tab;
- normal click;
- item move.

## Confirmation

- purchase;
- equip;
- successful action.

## Error / Warning

- invalid action;
- insufficient resource.

## Major

- important unlock;
- rare notification.

Preserve the project's actual UI style.

---

# Hover Sound Restraint

Do not automatically add hover sounds.

Hover audio can become exhausting when:

- pointer crosses many controls;
- menus contain dense lists;
- sample is too prominent.

Use only if already part of the established interface language or clearly beneficial.

---

# Error Feedback

Important failed actions may need audio acknowledgement.

Examples:

- invalid action;
- insufficient currency;
- unavailable ability;
- full inventory.

Do not add loud warning sounds for every harmless failed click.

Use hierarchy.

---

# Inventory / Equipment Audio

Inspect:

- pickup;
- drop;
- move;
- equip;
- unequip;
- consume;
- purchase.

Look for:

- unrelated sounds across equivalent actions;
- duplicate sound from UI and gameplay;
- equipment sound before actual equip success;
- loud routine inventory handling.

---

# Reward Audio

Inspect:

- XP;
- level-up;
- rare loot;
- quest completion;
- achievement;
- unlock;
- milestone.

Audio intensity should communicate importance.

Do not let:

- tiny XP tick;
- routine item pickup;

compete with:

- major level;
- rare drop;
- quest completion.

---

# Progression Hierarchy

Where multiple reward tiers exist, establish audible hierarchy.

For example:

- routine progress;
- meaningful unlock;
- major milestone.

Do not create a fanfare for every small event.

Contrast is what makes important events feel important.

---

# Rare Reward Review

If rare rewards exist, verify their presentation is:

- distinct enough to notice;
- not confused with routine pickups;
- not absurdly loud;
- triggered only once.

Do not invent extravagant audio if the game uses restrained presentation.

---

# Ambience & Soundscape Pass

Walk through representative locations.

Listen for:

- dead silence;
- identical ambience everywhere;
- obvious short loops;
- abrupt transitions;
- ambience unrelated to environment;
- constant dense noise;
- missing spatial cues.

Use audio to support environmental identity.

---

# Location Identity

Important places may benefit from distinct sonic character.

Possible sources include:

- town activity;
- forest life;
- wind;
- water;
- caves;
- machinery;
- fire;
- distant work;
- creatures;
- weather;
- interior room tone.

Do not force every zone to have a dramatically different soundtrack.

Subtle differences can be enough.

---

# Silence Is Part of the Soundscape

Do not fill every second with ambient sound.

Intentional quiet can support:

- isolation;
- tension;
- contrast;
- peaceful environments;
- spatial focus.

Ask:

> **Does this area feel intentionally quiet or simply unfinished?**

Preserve intentional quiet.

Fix empty, contextless silence.

---

# Ambience Loop Pass

For looping ambience inspect:

- loop seam;
- duration;
- obvious repetition;
- phase/reset;
- volume;
- lifecycle.

Short recognizable loops are especially damaging.

Where assets allow, use:

- longer beds;
- layered one-shots;
- randomized sparse elements;
- subtle variation.

Do not overcomplicate ambience merely to hide a weak loop.

---

# Ambient One-Shots

Where supported, occasional localized or randomized environmental sounds can reduce loop fatigue.

Examples:

- distant bird;
- creak;
- water splash;
- wind gust;
- machinery impact.

Keep them:

- sparse;
- contextually appropriate;
- spatially believable.

Do not create random audio clutter.

---

# Environmental Audio Integration

Inspect whether visible environmental features have appropriate existing sound.

Examples:

- waterfall;
- fire;
- machinery;
- forge;
- ocean;
- river;
- magical device.

Ask:

> **Would the absence of sound make this object feel obviously fake or unfinished?**

Not every visible object needs audio.

Prioritize visually dominant or gameplay-relevant sources.

---

# Interior / Exterior Transition

Where applicable, inspect transitions between:

- indoors;
- outdoors;
- caves;
- buildings;
- open terrain.

Look for abrupt ambience cuts.

Use existing:

- fades;
- snapshots;
- buses;
- zones;
- filters;

where available.

Do not build complex acoustic simulation solely for this pass.

---

# Weather Audio

If weather exists, inspect:

- start;
- intensity;
- stop;
- area transition;
- scene change.

Look for:

- weather audio starting late;
- sound continuing indoors unexpectedly;
- duplicated loops;
- abrupt cutoff.

Only improve existing weather systems.

---

# Music Transition Pass

If adaptive/state-based music exists, inspect transitions between:

- menu;
- exploration;
- combat;
- victory;
- death;
- different locations.

Look for:

- abrupt hard cuts;
- multiple tracks overlapping indefinitely;
- combat music never stopping;
- repeated restart;
- music beginning for very short encounters then immediately stopping.

Preserve the established music system.

Do not replace soundtrack composition.

---

# Music Restart Hunt

Frequent restarts can make music feel broken.

Inspect whether state changes repeatedly restart the same track.

Where appropriate:

- preserve playback position;
- ignore redundant state changes;
- use established transitions.

Do not change composition structure without need.

---

# Spatial Audio Pass

Where supported, inspect:

- positional accuracy;
- distance attenuation;
- stereo/3D configuration;
- minimum/maximum distance;
- directionality;
- listener-relative behavior.

World audio should feel connected to its source.

---

# Distance Attenuation

Look for sounds:

- audible from absurd distances;
- disappearing immediately;
- remaining equally loud regardless of position;
- competing across an entire map.

Tune attenuation according to:

- scale;
- importance;
- source type.

A waterfall and a tiny torch should not necessarily share the same range.

---

# Spatial Source Position

Verify sound originates from believable:

- object;
- weapon;
- door;
- creature;
- resource;
- environment feature.

Look for audio emitted from:

- world origin;
- player position;
- entity root far from visual source;
- wrong object.

Fix visible positional disconnect.

---

# Non-Diegetic Audio

Do not spatialize intentionally non-diegetic sounds such as many:

- UI effects;
- reward cues;
- system notifications.

Preserve their intended presentation.

---

# Mixing Pass

Establish a clear hierarchy among:

- gameplay-critical feedback;
- dialogue where present;
- important environmental cues;
- combat;
- UI;
- ambience;
- music;
- secondary effects.

Ask:

> **What should the player hear first?**

---

# Mix Relationship Hunt

Look for:

- clipping;
- everything equally loud;
- music burying important actions;
- ambience masking interactions;
- UI louder than combat;
- footsteps overwhelming everything;
- many simultaneous impacts becoming noise.

Use the project's existing mixer/bus system where practical.

Avoid scattering arbitrary volume multipliers throughout unrelated scripts.

---

# Bus / Mixer Review

Where mixer groups or buses exist, inspect:

- routing;
- default levels;
- parent-child relationships;
- muting;
- ducking where already supported;
- player settings.

Look for sources accidentally routed to:

- master;
- wrong category;
- bypass path.

Do not rebuild the mixer unnecessarily.

---

# Dynamic Range

Avoid flattening every sound to maximum prominence.

Use contrast.

Routine sounds should leave headroom for:

- boss attacks;
- major rewards;
- dangerous warnings;
- dramatic world events.

Professional audio needs quieter events so important ones can feel larger.

---

# Clipping / Overload Review

Where tooling permits, inspect for:

- clipping;
- excessive peak accumulation;
- many identical simultaneous sounds;
- stacked layers causing overload.

Correct the source.

Do not simply lower the master volume to hide a bad mix.

---

# Concurrency / Voice Management

If the audio system supports concurrency or voice limits, inspect high-frequency events.

Examples:

- many enemies attacking;
- many players gathering;
- repeated UI actions;
- dozens of footsteps.

Use appropriate limits where necessary.

Avoid cutting important feedback just because it shares a broad category.

---

# Sound Spam Hunt

Stress high-event-rate scenarios.

Look for:

- every damage tick creating full impact sound;
- dozens of identical footsteps;
- repeated error sounds;
- several NPCs producing identical loops;
- multiplayer events stacking.

Reduce spam using appropriate:

- concurrency;
- cooldowns;
- priority;
- aggregation;
- selective playback.

Do not suppress important information.

---

# Loop Lifecycle Pass

Inspect looping:

- ambience;
- machinery;
- weather;
- music;
- abilities;
- crafting;
- channeling.

Test:

- start;
- stop;
- cancellation;
- scene change;
- object destruction;
- death;
- disconnect;
- state transition.

Loops must not survive their owning lifecycle accidentally.

---

# Duplicate Loop Hunt

Look for the same logical ambience or machine sound starting multiple times because:

- scene reloads;
- state re-entry;
- duplicate components;
- reconnect;
- repeated initialization.

Prevent unintended stacking.

---

# Scene Transition Audio

During scene/zone changes inspect:

- old ambience stopping;
- new ambience starting;
- music transition;
- persistent global audio;
- duplicated listener/source instances.

Avoid:

- silence gap where unintended;
- sudden wall of new audio;
- old zone ambience continuing forever.

---

# Cancellation Lifecycle

For cancellable actions inspect audio behavior when:

- gathering stops;
- crafting cancels;
- ability interrupts;
- interaction ends;
- menu closes.

One-shot sounds may complete naturally.

Loops/stateful sounds should stop intentionally.

---

# Entity Lifecycle

For sounds attached to entities test:

- entity destroyed;
- despawn;
- death;
- unload;
- pooling;
- respawn.

Avoid:

- orphaned sound;
- reused pooled entity carrying old audio state;
- destroyed source cutting an important sound incorrectly when detached playback is expected.

Follow existing lifecycle patterns.

---

# Multiplayer Audio Pass

If multiplayer exists, distinguish:

- authoritative gameplay event;
- local prediction;
- replicated event;
- remote presentation.

Test whether one action plays:

- once locally;
- then again when replicated.

Avoid duplicated presentation.

---

# Predicted Versus Confirmed Audio

For responsive gameplay, some local audio may be predicted.

If so, determine what happens when:

- action is rejected;
- event replicates back;
- latency is high.

Do not remove prediction reflexively.

Prevent obvious duplicate or false feedback.

---

# Networked Sound Events

Do not network raw sound events when replicated gameplay state already provides enough information to produce the correct sound locally.

Conversely, do not derive important one-time sounds from state in a way that makes them repeat every update.

Use the simplest reliable existing model.

---

# Late Join Audio

A late-joining client usually needs:

- current loop/state ambience;
- persistent machinery;
- current music/environment state;

not historical one-shot events.

Do not replay the entire history of past sounds.

Ensure persistent audio reflects present authoritative state.

---

# Remote Player Audio

Inspect multiplayer:

- footsteps;
- attacks;
- gathering;
- equipment;
- death.

Look for:

- every remote sound equally loud;
- duplicated local/remote playback;
- sounds from entities outside meaningful range;
- stale audio after disconnect.

---

# Settings Integration

If the game exposes audio settings, verify relevant:

- master;
- music;
- effects;
- ambience;
- UI;
- voice;

controls actually affect intended buses.

Test:

> **change → listen → save → relaunch**

Do not create new settings categories merely for architecture purity.

---

# Volume Persistence

Ensure audio settings persist where intended.

Look for:

- UI changes mixer temporarily but does not save;
- values save but are not applied at startup;
- wrong scale conversion;
- one bus ignores player setting.

Do not conflate player settings with internal mix tuning.

---

# Audio Asset Quality Triage

This is not primarily an asset-replacement campaign.

But identify obviously problematic assets such as:

- placeholder/default audio;
- severe clipping;
- broken export;
- incorrect silence;
- wrong sample;
- dramatically inconsistent level.

Where a suitable existing alternative exists, correct the reference.

Do not generate or replace huge amounts of sound content without need.

---

# Existing Asset Reuse

Before creating new audio, inspect existing unused or underused assets.

They may already provide:

- variants;
- environmental loops;
- impact layers;
- UI sounds;
- creature sounds.

Reuse appropriately.

Do not automatically wire every unused asset.

Some may be abandoned or obsolete.

---

# New Audio Assets

If the project can safely produce or source small audio additions through its established pipeline, limited additions are acceptable when:

- an important event is conspicuously silent;
- no suitable asset exists;
- the addition clearly matches established audio identity.

Do not turn this into a large sound-production project.

Prefer strong implementation of existing assets over large volumes of mediocre new audio.

---

# Pattern-Based Audio Hunt

When one defect appears, inspect siblings.

Examples:

If one attack lacks impact sound:

> inspect the attack family.

If one ambience loop survives unloading:

> inspect other ambience loops.

If one UI family is dramatically louder:

> inspect equivalent UI controls.

If one networked event plays twice:

> inspect other predicted/replicated sounds.

Fix repeated faulty patterns where justified.

---

# Audio Error / Warning Hunt

Inspect runtime/editor warnings involving:

- missing clips;
- missing events;
- invalid buses;
- unavailable sources;
- failed middleware events;
- excessive voice counts;
- duplicate listener;
- broken references.

Prioritize warnings tied to actual player-facing defects.

Do not chase harmless development warnings unrelated to release behavior.

---

# Sibling Comparison

Compare equivalent sound families.

Examples:

- melee weapons;
- gathering skills;
- inventory actions;
- doors;
- reward types;
- environmental zones.

Ask:

- Is timing consistent?
- Is loudness hierarchy coherent?
- Is one sibling silent?
- Does one use unrelated sonic language?
- Is repetition treatment inconsistent?

Preserve meaningful differentiation.

Do not homogenize every sound.

---

# Productive Audio Loop

After each wave ask:

- What common action still feels sonically empty?
- What sound is most irritating after repetition?
- Which sound arrives too early or too late?
- What important event lacks weight?
- What dominates the mix unnecessarily?
- Which location sounds indistinguishable from another?
- What loop still sounds artificial?
- What sound survives after its state ends?
- What multiplayer event still plays twice?

Continue:

> **listen → identify weakness → trace trigger/state → implement → validate → listen again**

while material, safely actionable audio problems remain.

Do not manufacture audio merely to continue working.

Stop when remaining findings are:

- highly subjective;
- dependent on major new asset creation;
- intentional silence;
- dependent on broad gameplay redesign;
- outside scope.

---

# Work in Audio Waves

Do not randomly modify sounds across the project.

## Wave A — Broken Playback

Fix:

- missing references;
- runaway loops;
- severe duplication;
- playback errors;
- high-frequency audio spam.

Validate.

## Wave B — High-Frequency Gameplay

Polish:

- movement;
- common attacks;
- impacts;
- gathering;
- crafting;
- interactions.

Focus on timing and repetition.

Validate.

## Wave C — UI and Rewards

Polish:

- interface hierarchy;
- inventory/equipment;
- errors;
- notifications;
- reward importance.

Validate.

## Wave D — Ambience and Environment

Polish:

- major areas;
- environmental sources;
- spatial audio;
- transitions;
- loops.

Validate through representative traversal.

## Wave E — Mixing

Improve:

- bus hierarchy;
- loudness relationships;
- masking;
- clipping;
- concurrency;
- music/gameplay balance.

Validate in active gameplay.

## Wave F — Multiplayer and Lifecycle

Where applicable test:

- predicted/replicated events;
- remote players;
- late join;
- entity destruction;
- scene transitions;
- disconnect.

Validate.

## Wave G — Last 10%

Search for:

- remaining repetitive samples;
- minor timing mismatch;
- abrupt loop seams;
- weak area identity;
- inconsistent minor UI sounds;
- small mix problems.

---

# Reassess After Every Wave

Ask:

- What is the loudest unnecessary sound now?
- What important event is still too quiet?
- Which common sound remains irritating?
- Which event still sounds late?
- Did variation become excessive?
- Did ambience become too dense?
- Did a mix change hide important feedback?
- Did a new layer reduce clarity?
- Did lifecycle fixes introduce abrupt cuts?
- Does multiplayer still duplicate anything?

Reprioritize.

---

# Fresh Independent Audio Review

Near completion, listen again with fresh context.

Ask:

> **What still sounds placeholder, weak, repetitive, badly mixed, mistimed, disconnected, or unfinished?**

Require concrete findings.

For each include:

## Event / Location

Where does the problem occur?

## Problem

What sounds wrong?

## Evidence

What makes it noticeable?

## Player Impact

Why does it matter?

## Fix

What practical correction is justified?

## Scope

Tiny / Small / Medium / Large.

Implement worthwhile findings.

Reject vague criticism.

---

# Anti-Noise Review

Before completion, inspect whether the polish pass added too much audio.

Look for:

- constant sound;
- excessive UI clicking;
- too many impact layers;
- exhausting ambience;
- duplicated feedback;
- random pitch chaos;
- every reward sounding major;
- important moments losing contrast.

Remove unjustified sound.

Professional audio depends on hierarchy and restraint.

---

# Anti-Randomization Review

Variation should reduce repetition.

It should not make sound inconsistent.

Ask:

- Did pitch variation become cartoonish?
- Did volume variation reduce readability?
- Did important feedback lose a recognizable identity?
- Are variants stylistically mismatched?

Keep variation controlled.

---

# Anti-Loudness Review

Do not solve weak sounds simply by increasing volume.

A sound may lack impact because of:

- poor timing;
- wrong frequency content;
- weak transient;
- masking;
- bad layering;
- inappropriate asset.

Volume is only one tool.

---

# Anti-Layer-Everything Review

More layers can create:

- noise;
- clipping;
- fatigue;
- indistinct impacts.

Use layering only when it adds meaningful:

- weight;
- material;
- state information;
- spatial character.

Remove redundant layers.

---

# Regression Review

After audio changes verify:

- gameplay behavior remains unchanged;
- animation events still behave correctly;
- important sounds trigger once;
- loops stop correctly;
- settings work;
- scenes unload cleanly;
- multiplayer does not duplicate events;
- no new audio errors appear;
- performance does not obviously regress.

Audio polish must not create functional instability.

---

# Performance Awareness

This is not primarily an audio-performance pass.

However, avoid changes that create:

- hundreds of simultaneous voices;
- excessive always-running emitters;
- unbounded one-shot spawning;
- duplicated loops;
- unnecessary network messages;
- huge constantly loaded audio sets.

Use existing audio pooling/concurrency mechanisms where appropriate.

---

# Final Runtime Listening Pass

Before finishing, perform representative continuous gameplay.

Include relevant:

1. spawn;
2. movement;
3. common interaction;
4. combat;
5. gathering/crafting;
6. inventory/equipment;
7. rewards;
8. several distinct environments;
9. menu/UI use;
10. music transition;
11. death/respawn where relevant;
12. multiplayer remote events where relevant.

Listen to relationships between sounds.

Many audio problems appear only when several systems overlap.

---

# Completion Standard

The audio and soundscape pass is complete when, to the degree existing assets and technology allow:

1. major audio systems play correctly;
2. no known runaway loop remains;
3. severe duplicated playback is resolved;
4. common important actions are not conspicuously silent;
5. major gameplay events are timed appropriately;
6. combat feedback communicates action and impact clearly;
7. high-frequency sounds are not excessively repetitive;
8. movement audio is synchronized reasonably where present;
9. gathering/production audio remains tolerable under repetition;
10. important UI actions use coherent audio language;
11. reward hierarchy reflects event importance;
12. major environments have appropriate sonic identity;
13. intentional quiet remains preserved;
14. spatial sounds feel connected to their sources;
15. obviously incorrect attenuation is fixed;
16. loops start and stop with their lifecycle;
17. music/state transitions are coherent where applicable;
18. important mix relationships are clear;
19. music/ambience do not unnecessarily mask gameplay-critical sound;
20. obvious clipping or excessive accumulation discovered during the pass is addressed;
21. multiplayer audio does not obviously duplicate local/replicated events;
22. audio settings behave correctly where implemented;
23. no discovered P0/P1 audio issue remains unresolved without an explicit blocker;
24. no known regression introduced by this pass remains;
25. remaining issues require major new audio production, broad architecture changes, are highly subjective, or are outside scope.

The objective is not:

> **maximize the number of sounds**

The objective is:

> **use timing, hierarchy, variation, spatial logic, atmosphere, and restraint to make the existing game sound intentional and professionally produced.**

---

# Final Report

When complete, provide a concise audio report.

## 1. Overall Result

Summarize the biggest improvements to audio quality and soundscape cohesion.

## 2. Major Event / Audio Fixes

Describe significant:

- missing;
- duplicated;
- mistimed;
- broken;

audio fixes.

## 3. Combat / Gameplay Actions

Summarize meaningful improvements to relevant:

- attacks;
- impacts;
- abilities;
- movement;
- gathering;
- crafting;
- interactions.

## 4. UI / Rewards

Describe meaningful work involving:

- interface feedback;
- inventory/equipment;
- errors;
- notifications;
- progression;
- rewards.

## 5. Ambience / Spatial Audio

Summarize improvements to:

- environment identity;
- ambience;
- spatial placement;
- attenuation;
- environmental transitions.

## 6. Mixing / Repetition

Describe meaningful:

- bus/mixer;
- loudness hierarchy;
- concurrency;
- repetition;
- variation;

changes.

## 7. Music / Loop Lifecycle

Where applicable, summarize:

- music transitions;
- ambience loops;
- lifecycle cleanup;
- state changes.

## 8. Multiplayer Considerations

Where applicable, describe:

- local versus replicated playback;
- remote-player audio;
- late join;
- disconnect/despawn;
- duplicate-event fixes.

## 9. Validation

State exactly what was actually performed, including relevant:

- runtime listening;
- repeated-action tests;
- mix checks;
- environment traversal;
- lifecycle tests;
- multiplayer checks;
- settings tests;
- audio warnings/errors.

Do not imply listening or validation occurred when it did not.

## 10. Deliberately Unchanged

Describe noteworthy audio issues preserved because:

- silence is intentional;
- existing identity supports the current behavior;
- new assets are required;
- evidence was insufficient;
- changing it would require broader gameplay or audio architecture work.

## 11. Remaining Issues

List only meaningful unresolved audio problems.

For each include:

- **Event / Location**
- **Problem**
- **Severity**
- **Why unresolved**
- **Recommended next action**

Do not pad this section with microscopic subjective mix preferences.

---

# Final Directive

**Think like an audio director listening to actual gameplay, not someone trying to maximize the number of sound effects.**

Repeatedly ask:

> **Does this event need sound?**

> **Is the sound synchronized with what actually happened?**

> **Will this become irritating after 1,000 repetitions?**

> **Does the mix tell the player what matters?**

> **Does this sound belong to the source the player sees?**

> **Does this location sound like somewhere, or like silence with occasional effects?**

> **Does this loop stop when its state ends?**

> **Is an important moment being buried by routine noise?**

Continue:

> **listen → identify weakness → trace trigger/state → implement → validate → listen again**

while meaningful audio-quality improvements remain.

Leave behind the **same game**, but make its audio, feedback, ambience, spatial presentation, repetition control, and mix substantially more cohesive, responsive, atmospheric, readable, and professionally produced.