Implementing Your First Sound in Wwise: From Event Creation to In-Game Playback (Wwise + CUBE – Episode 2)

CUBE_EVENTS_LIST.pdf

Download PDF • 240KB

In the first episode of this series, the focus was entirely on preparation: installing Wwise, downloading the CUBE demo game, removing the default sound banks, and creating a clean project that was correctly linked to the game.

This second episode marks the point where audio actually enters the pipeline.

The goal here is not polish, realism, or creative sound design. It is to understand how a sound travels from Wwise into the game, how events are triggered, and how to verify that an implementation is working correctly. Everything else builds on this foundation.

Why the First Sound Matters

When learning middleware, it’s tempting to jump straight into complex systems: switches, RTPCs, surface types, or large hierarchies. In practice, most problems people encounter with Wwise are not caused by complexity, but by misunderstanding the basic event pipeline.

If you can’t reliably get a single sound to trigger in-game, adding complexity only makes debugging harder.

For that reason, this episode focuses on a single, clearly defined action: firing the Ice Gem in CUBE.

Understanding What the Game Is Asking For

Before importing any audio, it’s important to understand that CUBE already expects specific event names. These are not arbitrary. They are hardcoded into the game.

In this case, the event we need is:

Fire_IceGem_Player

This information comes from the event reference spreadsheet provided with CUBE, which lists all available events and explains when they are triggered. This document is essential, because naming an event incorrectly—even by a single character—will result in silence.

Wwise will not warn you. The game will not warn you. Nothing will happen.

This is why event naming discipline matters from the very beginning.

Creating the Event First (Not the Sound)

A common beginner mistake is importing audio and worrying about events later. In middleware workflows, it often makes more sense to do the opposite.

The event defines the contract between the game and Wwise.

In the Designer layout, under the default work unit, a new event is created and named exactly as the game expects:

Fire_IceGem_Player

At this stage, the event does nothing. That’s fine. The important part is that the event exists and is correctly named.

Creating the Audio Object

With the event in place, attention shifts to the Actor-Mixer Hierarchy.

A new Sound SFX object is created and named in a way that clearly reflects its function. Initially, this object appears red, indicating that it contains no audio. This visual feedback is useful and intentional.

The Ice Gem blast sound provided in the Wwise Fundamentals materials is then imported into this object. At this point, we have:

• A correctly named event

• A sound object with audio content

• No connection between them yet

That connection is what makes the system work.

Connecting the Event to the Sound

Back in the Events tab, a Play action is added to the Fire_IceGem_Player event. The target of that action is set to the Ice Gem sound object created earlier.

This step is critical. Without an action, an event does nothing. Without a correct target, it does the wrong thing.

Once this connection is in place, the logical pipeline is complete:

Game → Event → Play Action → Audio Object

But this still isn’t enough for the sound to play in-game.

Why SoundBanks Are Non-Optional

Wwise does not stream content dynamically by default. Audio must be explicitly built into SoundBanks, which are then loaded by the game.

For CUBE, gameplay events are expected to live in a SoundBank called Main. If the event exists but is not included in this SoundBank, it will never trigger.

In the SoundBank layout:

• A new SoundBank named Main is created

• The event is added to it

• The SoundBank is generated

Only after this step does the sound actually exist in a form the game can use.

Verifying the Implementation in Game

When launching CUBE after generating the SoundBank, the game remains silent until the Ice Gem is fired. At that moment, the newly implemented sound plays.

This confirms several things at once:

• The event name matches the game’s call

• The SoundBank is correctly generated

• The SoundBank path is correct

• The event is wired properly

At this point, the system works—but the sound itself is extremely simple.

That’s intentional.

Introducing Layering Without Complexity

To move beyond a single, flat sound, additional audio is introduced from the second module of the provided materials. This includes elements like a whoosh and a recharge tail.

Rather than replacing the original sound, these elements are layered on top of it. This demonstrates how more complex behaviours can be built from simple components.

One of the provided sounds is duplicated and split into two conceptual layers:

• A forward motion (whoosh)

• A recharge tail

This isn’t about realism yet. It’s about control.

Timing and Avoiding Phase Clashes

When multiple layers are triggered simultaneously, they compete for attention and can sound messy. To address this, simple delays are introduced at the event level.

By offsetting the start times slightly—fractions of a second—the layers become more readable and intentional.

This is a powerful technique, and it doesn’t require complex systems or scripting. Small timing decisions often do more for clarity than heavy processing.

Grouping and Panning Related Sounds

To manage multiple layers together, the related sounds are grouped under a new Actor-Mixer parent. This allows shared properties—such as positioning—to be applied to all child sounds at once.

In this case, the grouped recharge sounds are panned to the right, matching the on-screen action. This reinforces the relationship between audio and visuals without requiring true 3D spatialisation.

The goal here is not realism, but coherence.

Adding Variation With Pitch Randomisation

Finally, basic variation is introduced using pitch randomisation.

Rather than applying identical values everywhere, different ranges are used depending on how noticeable the variation should be. Subtle randomisation avoids repetition without drawing attention to itself.

This step demonstrates an important principle: variation should support believability, not become the focus.

What This Episode Actually Teaches

By the end of this episode, the important outcomes are not the sound itself, but the understanding of the process:

• How events are named and why that matters

• How events connect to audio objects

• How SoundBanks control what exists in-game

• How layering, timing, panning, and variation work together

This is the foundation for everything that follows.

What Comes Next

The next episode moves away from single, isolated sounds and into systems that respond to context. We’ll start working with footsteps and variation in a way that reflects actual gameplay conditions.

At that point, the techniques introduced here stop being exercises and start becoming tools.