Skip to content

Sound Attenuation and spatialized audio

At a glance

Type: audio concept - Main asset: Sound Attenuation - Affects: distance volume, spatialization, focus, occlusion, priority, and related listener/source behavior - Does not: make the sound play, replicate the sound, or decide who should hear the gameplay event - Official docs: Sound Attenuation, Audio Engine Overview, and Play Sound at Location

The one-minute version

  • Attenuation is the rule set that makes a world sound change with listener distance and direction.
  • A sound can be played at a world location and still feel flat if it has no distance falloff or spatialization settings.
  • The listener is usually the local player's camera/view, not the actor that caused the sound.
  • Attenuation can control volume falloff, spatialization, focus, occlusion, priority, and reverb/send behavior.
  • It is local presentation. In multiplayer, replicate the gameplay event or state, then let each machine play the sound with its own listener.
  • Attenuation does not replace concurrency, Audio Components, or a sound asset choice. It shapes how a playing sound is heard.

What it actually does

A world sound has at least three pieces:

flowchart LR
    Event[Gameplay event] --> Play[Play sound / Audio Component]
    Play --> Source[Sound source location]
    Listener[Local listener / camera] --> Mix[Audio engine mix]
    Source --> Mix
    Att[Attenuation settings] --> Mix

When a sound plays with attenuation, the audio engine compares the source to the listener and applies the configured rules. A simple volume rule looks like:

pseudocode of the audio behavior - not engine source

distance = Distance(SourceLocation, ListenerLocation)

if distance <= inner radius:
    volume = full volume
else if distance >= max radius:
    volume = minimum or silent
else:
    volume = falloff curve between full and minimum

if spatialization is enabled:
    pan/filter the sound based on direction from listener to source

if occlusion is enabled:
    test whether geometry blocks source-to-listener
    apply occlusion volume/filter if blocked

The exact shape depends on the attenuation asset. A first project usually only needs distance falloff and spatialization. Add occlusion/focus only when you can hear the problem they solve.

When it fails (and what failure looks like)

Common symptoms:

  1. The sound is full volume everywhere. Volume attenuation is disabled or the sound is effectively 2D.
  2. The sound does not pan left/right. Spatialization is disabled, the asset is treated as UI/2D, or the output channel/source setup does not support the result you expect.
  3. The falloff radius is too large or too small. The sound works, but the numbers do not match the scale of the level.
  4. The source is at the wrong location. Play Sound at Location used an actor origin, not the muzzle, impact point, foot socket, or moving emitter.
  5. Attached loops do not follow correctly. A fire-and-forget sound at a fixed location will not move with the actor. Use an Audio Component or attached playback for moving loops.
  6. Occlusion feels inconsistent. Collision channels, trace complexity, and room geometry can make obstruction tests surprising.
  7. Multiplayer plays too many or too few sounds. Each machine has its own listener. Do not replicate "audio"; replicate the event/state and play local audio where appropriate.

Failure usually sounds wrong; it does not throw a Blueprint error. Use audio debug commands, attenuation visualizers, and a known test map before rewriting the gameplay event.

The pattern everyone actually uses

For an impact sound:

Projectile hit result
-> Impact Point
-> choose sound by Physical Material or surface type
-> Play Sound at Location(Sound, Impact Point, Attenuation = ImpactAttenuation)

For footsteps:

Animation Notify Footstep
-> trace down from foot socket
-> choose surface sound
-> Play Sound at Location(FootstepSound, FootLocation, FootstepAttenuation)

For a moving loop:

Spawn Sound Attached / Audio Component on machine that should hear it
-> attach to engine/fire/portal component
-> attenuation asset handles distance and spatialization
-> Stop or Fade Out when state ends

Do not build a whole audio manager just to make footsteps fade with distance. Use a Sound Attenuation asset first.

Attenuation is not concurrency

Attenuation answers "how loud/spatial should this active sound be for this listener?" Concurrency answers "should this sound be allowed to play another instance at all?"

For example:

Explosion sound
-> Attenuation: large radius, spatialized
-> Concurrency: limit duplicate explosion voices if many happen at once

Both matter, but they solve different problems.

Lookalikes - which one do I want?

Feature / node Controls Use when
Sound Attenuation asset Distance, spatialization, focus, occlusion, priority A world sound should change based on listener/source relationship.
Play Sound 2D Local non-spatial playback UI clicks, menu sounds, local success/fail cues.
Play Sound at Location Fire-and-forget world sound at a fixed point Impacts, one-shot explosions, footstep points.
Spawn Sound Attached Returns an Audio Component attached to something Loops or controllable sounds that move with an actor.
Audio Component Play/stop/fade/set sound/volume on a live component You need ongoing control over a sound instance.
Sound Concurrency Voice limits and duplicate rules Too many copies of a sound play at once.
Sound Cue / MetaSound Source asset behavior Randomization, procedural sound, parameters, or reusable sound logic.

Rule of thumb: Use attenuation to make a world sound feel like it has a place. Use an Audio Component when you need to keep controlling it after it starts.

Going deeper