Summary
I had a deep dive into Wwise's pipeline and learned more about it being one of the leading middlewares in the industry. I explored Wwise integration by building a 3D audio system in a custom engine to better understand middleware implementation, low-level control, and audio system design.
The Process
Inspiration
Inspired by a GDC talk on audio programming in Zelda: Tears of the Kingdom, it sparked an interest in dynamic audio systems and how sound shapes player experience.
I find the whole idea of dynamic audio really fascinating, and hearing the techniques behind one of my favorite games was really cool.
Learning Wwise
I had to learn Wwise's interface itself from the ground up using their resources as FMOD looks slightly (quite a lot) different from it. While learning and getting used to the interface, I was also reading their documentation for Wwise SDK.
I made sure to document all the important things on my own for future reference such as the libraries needed, settings, SDK functions and more.
The Integration
Linking and Testing
Integrated Wwise into my own custom framework to validate core functionality.
The challenges I went through with this process were the following:
• Make sure I have the correct installation properties for Wwise
• Customizing my premake so i'm linking the libraries correctly
• Make sure I have all the include files from correct directory in the SDK folder
• Customizing my premake so i'm linking the libraries correctly
• Make sure I have all the include files from correct directory in the SDK folder
The workflow I went with was to read and learn about a certain section like say, Initializing the Memory Manager, thereafter implementing it and verifying that it works.
Making the Wrapper
Developed a lightweight wrapper that handled initialization, bank management, event playback, and resource cleanup.
I decided to make the wrapper early on to make the integration to our team's custom engine later on seamless.
Custom Engine integration
Integrated the audio system into our team's custom engine called bean. The challenge I faced was regarding the engine's differing settings as well as that our premake is handled differently compared to mine.
Refactored the pipeline and validated functionality through clean re-integration with our existing Sound Component, Audio Manager and Sound Engine ecosystem.
The Features
3D Spatialization
Implemented and scaled the distance attenutation from Wwise to our own unit scale based on our custom engine. Distance scale in Wwise is still 100 and can be adjusted if a certain object needs to be heard much further.
An example situation where distance scaling would help, is from our game Finders Keepers. We had a gigantic gate in the distance which you needed to trigger from a distance to progress. Opening the gate would trigger a sound 'GateOpeningLoop', that needed to be heard from a distance for readability.
Depth Based Occlusion
Implemented occlusion by sending raycasts from the GameObject that consists of the AudioSourceComponent and checking for collisions using the engine's existing collision system.
Enabled dynamic sound obstruction using a cheap hack by sending another ray from the listener to get the thickness of the collider in between. My team will use my system for the last project we will have in TGA and I want to have the raycast support a more accurate depth check by checking multiple colliders intersected and by using buffers.
Trigger-based Acoustic Zones
Implemented trigger boxes handling auxillary sends as a cheap but effective simulation of room reverbations. The trigger boxes only need a tag referring to the reverbation type it should switch to (Hall, Room, Cave etc.)
I sent out a parameter change to mute and unmute specific auxiliary busses depending on which box is triggered.
The Other Fun Stuff
Optimization
Reduced raycast frequency from per-frame to ~10/sec to improve performance.
Added distance-based culling and conditional transform updates for efficiency.
Added distance-based culling and conditional transform updates for efficiency.
Debug Tools
Implemented visualization tools for attenuation ranges and audio behavior for improved debugging, tuning, and system validation.
What's next
It's been a really fun learning experience and Wwise definitely lives up to its name. I would love to apply and expand this system in our final game project in The Game Assembly so that I can focus on deeper integration, improved tooling, and more advanced audio behaviors. Some features I would love to dive deeper to are music sequences, fancier (but also more expensive) ways to calculate audio behaviours within different sound spaces as well as other tricks you can do with sound attenuation.