Although Wwise official learning resources are actually very good, after some years teaching Wwise I've noticed that some students often find difficult to understand some terms and flows used in Wwise. This page aims to help students have a more visual understanding of all the basic Wwise concepts.
Maybe you've heard that Wwise is an audio middleware for videogames and interactive applications. This definition is not really accurate. We need to better understand what a middleware really is before moving forward.
Middleware are software components that can be embedded into other software products to provide specific functionality. Nowadays, videogames are usually built on top of software layers that provide the most commonly needed functions like 3D or 2D image rendering, physics calculations, user input handling, cinematic playing, AI processing and also sound output generation. That's what we call the videogame engine.
However, videogame engines are not just middleware. They also feature specialized tools to help in the development process. All those tools are usually gathered together in specialized editors the allow the user to integrate all kind of assets like raw data, 3D models, animations, video, sound and code. Following this lines you can see screenshots of the Unity and Unreal editors, which are nowadays mainstream videogame engines.
Like all other types of middleware, Wwise is also a component that can be added to the videogame engine to provided specialized audio functionality. It can deal with 3D interactive audio and music and allows a very accurate control to fine-tune sound behavior. Adding it to our videogame engine, we'll have now the following layers:
Wwise lies in-between the videogame engine and the sound output. Now the videogame's sound engine is inhibited and the videogame engine will sends to Wwise all the context data it needs to generate the sound output.
In the same way videogame engines aren't just middleware, Wwise isn't just middleware either. It also provides a specialized tool to manage all the audio assets and define the way audio must react to game events and state/context changes: the Wwise Authoring Tool. This tool is designed to be used by sound designers. According to the Wwise workflow, the sound designer must define the audio behavior according to the game events and states, and also manage the assets (audio files). With this tool, the sound designer can generate specialized asset files called soundbanks that can be read and used by the Wwise middleware to play the sound for the game according to the designed behavior.
Other audio middlewares like FMOD work in the same way and provide similar tools to achieve the same goals, each one with its own special features.
The Wwise Authoring Tool is used to define how will sound behave according to the game events and state. The simplest interaction for understanding how everything works is intercepting an event and playing a sound whenever it happens. This is what is done in Wwise 101 first lesson.
In this lesson, we want our sample game, Cube, to play the sound IceGem_Blast.wav whenever the player fires the IceGem weapon. To achieve this, we'll use the Wwise Authoring Tool to intercept the Fire_IceGem_Player event in the game, associate the action of playing the IceGem_Blast.wav sound with it and generate a Soundbank that will contain both the sound and the behavior. The steps are simple:
Now we can play the game (we must restart it, as soundbanks are read when the game starts) and listen how Cube is playing the sound we've set up whenever the event is posted. This is a diagram for the flow (the left side is performed in real-time):
A step-by-step explanation about the real-time flow: