How to Design Dynamic Weather Audio That Responds to Game State

The player is walking through a forest when the weather starts to change. Within thirty seconds the sky darkens, the wind picks up, and rain begins. The audio has to change with it, but not in a way that makes the transition audible as a transition. The forest ambience does not stop and a rain loop does not start. Instead the mix shifts: the wind layer grows, the insect and bird activity drops, and a rain bed fades up underneath. When the rain reaches full intensity, the player still hears the forest — the leaves and the distant wind — because the rain has been added to the scene rather than replacing it.

A weather audio system that works this way is a continuous parameter system, not a set of discrete states. The weather state in the game engine might change from "clear" to "storm" in a single logical step, but the audio never receives a state change. It receives a continuously updating set of numbers that represent wind speed, precipitation intensity, humidity, and temperature, and it mixes the layers according to those numbers.

The general ambience guide covers how to build the individual layers. This article is about the system that drives them: the parameter model, the transition timing, and the specific layering structure that keeps rain, wind, thunder and surface effects synchronized without any of them fighting for the same frequency space.

What parameters does the audio system actually need?

Most games have a weather simulation that produces many values, but the audio system only needs a small subset. The rule is to pass the parameters that change the sound, not the parameters that change the visuals.

The four parameters below cover almost every weather audio scenario. They are independent — changing one does not automatically change the others — and each one drives a specific set of layers in the mix.

Parameter	Range	Drives	Update rate
Wind speed	0 to 1	Wind layers, foliage rustle, whoosh on exposed surfaces	4 Hz
Precipitation	0 to 1	Rain or snow bed, surface impacts, roof impacts	4 Hz
Storm intensity	0 to 1	Thunder frequency, low-frequency rumble, pressure drop	1 Hz
Exposure	0 to 1	Shelter filtering, reverberation, occlusion	10 Hz

The exposure parameter is the one most teams miss. It represents how exposed the player's current position is to the weather — are they in the open, under a tree, inside a building? The exposure value drives the filtering on the weather layers, so the same rain sound is bright and loud when the player is exposed and dull and quiet when they are sheltered. Without this parameter, a player who walks into a building during a storm hears the outdoor rain at full volume through the walls.

The update rates are chosen based on how fast each parameter is expected to change during gameplay. Wind speed and precipitation can shift meaningfully within a second during a storm transition, so they update at 4 Hz. Storm intensity changes more slowly, so 1 Hz is enough. Exposure can change on a single frame — a player who steps through a doorway moves from fully exposed to fully sheltered in one step — so it updates at 10 Hz to keep the filter response tight.

These update rates assume the engine sends parameters every frame anyway; the audio system simply reads the current value at its own rate rather than reacting to every change. This decouples the audio from the game's update loop, which prevents audio glitches when the game hitches.

How do the parameters map to the mix?

The mapping from parameters to layer volumes is not linear. A wind speed of 0.5 does not produce half the wind volume of a wind speed of 1.0, because the perceived loudness of wind does not track linearly with wind speed. The mapping needs a curve that compresses the low end and expands the middle, so that small changes at low wind speeds produce audible differences and large changes at high wind speeds do not overwhelm the mix.

A curve that works for most weather layers is volume = parameter ^ 0.5, an inverse square root. This produces a mix where the layer is audible even at low parameter values, rises quickly through the middle range, and saturates gently as the parameter approaches 1. The exact exponent is tunable, but 0.5 is a reasonable default for wind, precipitation, and storm intensity.

The exposure parameter uses a different mapping. It controls a low-pass filter on the weather bed, and the filter frequency should be near 20 kHz when the player is fully exposed and near 500 Hz when they are fully sheltered. This is a linear interpolation on a logarithmic frequency scale, which produces the natural-sounding progression from open-air to indoors. The same filtering approach used for the occlusion and obstruction system applies here, with the difference that exposure is a property of the player's location rather than a property of each individual sound source.

The wind layer is further modulated by a slow LFO with a period between 8 and 15 seconds. Real wind does not sustain at a constant level; it gusts and drops. The LFO adds this behavior on top of the parameter-driven volume, so that a wind speed of 0.7 produces a layer that swells and recedes rather than sitting at a constant level. The LFO depth increases with wind speed — a light breeze gusts by about 10 percent, a strong wind gusts by about 30 percent — which is the same behavior that makes the wind feel natural in the first place.

What is the layering structure for a full weather system?

The layer structure is the part that determines whether the system sounds coherent or cluttered. Each weather element gets its own frequency band and its own role, so that no two layers compete for the same space in the mix.

Layer	Frequency range	Source type	Role
Base wind bed	200 Hz to 3 kHz	Looping filtered noise	Continuous background
Wind gusts	400 Hz to 5 kHz	Short noise bursts	Dynamic variation
Rain bed	2 kHz to 12 kHz	Looping filtered noise	Continuous precipitation
Rain impacts	1 kHz to 8 kHz	Short one-shots	Surface contact detail
Thunder	20 Hz to 500 Hz	Event-driven rumble	Storm punctuation
Pressure drone	30 Hz to 100 Hz	Looping low tone	Subconscious tension

The base wind bed is the layer that runs continuously whenever the wind parameter is above a small threshold. It uses filtered noise as its source, with the filter frequency tracking the wind speed so that stronger winds sound brighter as well as louder. The gusts layer is separate because gusts need a different envelope — a short attack and a longer decay — that cannot be produced by modulating the sustained bed.

The rain bed and rain impacts are separate for the same reason. The bed is a continuous filtered noise that establishes the presence of rain; the impacts are individual one-shots that provide texture and surface information. When the player is under a roof, the impacts are filtered heavily while the bed is only slightly attenuated, which is what produces the difference between being inside and outside a building during a storm.

The thunder layer is event-driven rather than continuous. The storm intensity parameter controls the event rate — a light storm has thunder every 30 to 60 seconds, a heavy storm every 10 to 20 — and the delay between the flash and the sound depends on the distance of the strike. A near strike is loud and high-frequency; a distant strike is a low rumble. The horror sound design approach uses the same distance-based filtering for its threat cues, and the technique translates directly to thunder.

The pressure drone is the layer that most weather systems skip, and it is the one that makes a storm feel threatening rather than just loud. A low-frequency tone below 100 Hz that rises in volume with storm intensity communicates the change in atmospheric pressure that precedes a severe storm. It is felt more than heard, and it is the layer that makes the transition from "heavy rain" to "storm" feel qualitatively different.

How do you handle the transition without it feeling abrupt?

The transition timing is the part of weather audio that separates a system that works from one that sounds mechanical. If the parameters change instantly, the mix changes instantly, and the player hears the audio system responding to a state change rather than the weather itself changing.

The solution is to apply a smoothing filter to every parameter before it reaches the mixer. A one-pole low-pass filter with a time constant of 3 to 5 seconds is enough to smooth out the transitions without introducing noticeable lag.

class SmoothedParameter {
    constructor(initialValue, timeConstant = 3.0) {
        this.current = initialValue;
        this.target = initialValue;
        this.timeConstant = timeConstant;
    }

    setTarget(value) {
        this.target = value;
    }

    update(deltaTime) {
        const alpha = 1 - Math.exp(-deltaTime / this.timeConstant);
        this.current += (this.target - this.current) * alpha;
        return this.current;
    }
}

The smoothing filter is applied per parameter, not per layer. This means that all the layers driven by wind speed receive the same smoothed wind value, which keeps the layers coherent. If each layer smoothed independently, a sudden wind change would cause the layers to arrive at their new values at different times, and the mix would shift through a series of intermediate states that do not correspond to any real weather condition.

The time constant matters more than it seems. A 1-second time constant produces transitions that feel responsive but can still reveal the underlying step change if the weather shifts abruptly. A 10-second time constant produces transitions that are too slow for the player to notice the weather changing at all. The 3 to 5 second range is the sweet spot for most games: the player notices that the weather is changing, but they do not notice the moment it changed.

The exposure parameter is the exception to the smoothing rule. Exposure changes should be relatively fast — a 0.5 second time constant — because the player expects the audio to change immediately when they step through a doorway. The shelter is an instantaneous change in the acoustic environment, not a gradual weather transition, and the smoothing should reflect that difference.

How do you keep the layers synchronized during gameplay?

The synchronization problem is specific to weather audio because weather has so many interconnected parts. When the wind picks up, the rain should also be intensifying, and the thunder should become more frequent. If the layers are driven by independent parameters that the game updates independently, they can drift out of sync and produce weather that feels wrong — heavy rain with no wind, or thunder with no storm.

The standard solution is a weather state machine in the game that produces the parameters as a coherent set. The state machine has a small number of discrete states — clear, cloudy, light rain, heavy rain, storm, and the transitions between them — and each state defines the target values for all four parameters. The audio system receives the parameters that the state machine outputs, and it does not need to know what state the game is in.

The advantage of this approach is that it keeps the weather simulation and the audio system separated. The weather simulation decides that it is raining; the audio system receives a precipitation value of 0.7 and mixes accordingly. The audio designer can tune the mapping without changing the weather simulation, and the weather programmer can add new weather states without the audio system needing any changes.

The disadvantage is that the audio system cannot create weather that the game is not simulating. If the game's weather system does not track humidity, the audio system cannot modulate the rain bed based on humidity. The practical solution is to identify the small set of parameters that matter for audio and add them to the weather simulation's output if they are not already there. Four parameters cover most weather audio needs, and adding them to an existing weather system is usually a one-day change.

What are the specific implementation details in Wwise and FMOD?

The implementation in either middleware follows the same pattern: a set of RTPCs or Parameters that receive the weather values, and a set of layer volumes and filter frequencies that are driven by those values through mapping curves.

In Wwise, the weather system is typically implemented as a single Actor-Mixer with sub-layers for each weather element. The four weather parameters are created as Game Parameters in the Game Syncs tab, and each layer's volume is bound to one or more of them through RTPC curves. The exposure parameter is bound to a Low Pass Filter on the parent Actor-Mixer, so that the entire weather system is filtered by the same value. The vertical layering approach used for adaptive music uses the same RTPC-driven volume technique, with the difference that weather layers are noise-based rather than musical.

In FMOD, the same system is implemented as a single Event with multiple tracks, each track's volume controlled by a Parameter. FMOD's Parameter system is simpler than Wwise's RTPC system for this use case because the weather parameters are all continuous and the mapping curves are straightforward. The FMOD Unity integration guide covers the basic setup, and the weather system is a direct extension of the parameter-driven Event pattern described there.

The thunder events are handled differently in each tool. In Wwise, thunder is posted as a standard Event triggered by the game's storm logic, with the distance parameter passed through an RTPC that controls the thunder's filter frequency and volume. In FMOD, the same thing is done with an EventInstance and a set of Parameters. Neither tool has a built-in scheduling system for the thunder rate, so the game code is responsible for deciding when to fire the next strike based on the storm intensity.

The performance budget for a full weather system is higher than for a single ambience layer but lower than for a combat-heavy scene. The base wind bed, the rain bed, and the pressure drone are three continuous voices. The gusts, rain impacts, and thunder add another five to ten voices depending on the current intensity. Total weather voices at peak storm intensity sit between eight and fifteen, which is well within the budget for a scene that is not already using all available voices for combat or dialogue. The file size reduction techniques apply to the weather layers as well, though ambient loops tolerate more aggressive compression than short effects because there is no transient to protect.