Using Unity and Wwise
Rather than starting and stopping multiple different Wwise events for different music tracks. I wanted to create a modular system that would allow for one event to be called at the beginning of the game, and have a custom C# script in Unity that would control a Switch Container in Wwise.
Switch Containers allow us the ability to change which sounds will be played depending on the input passed from the game.
The Wwise Unity Integration Package already has a tool to change a Switch Value, with a variety of triggers, but it doesn’t contain the functionality I wanted.
For this project, I only actually need the Switch to be changed on a Game Objects Enable and Disable. But this could very easily be expanded to handle other triggers. I touch on this within my Ducking System Article. (Link coming later this week)
Firstly, a quick overview of how the Switch Container is set up in Wwise.
On the left, our Project Explorer contains a Music Switch Container. This is a short demo-like game, so we don’t have many tracks. But we could very easily have a different switch container for each level of a larger game. Below this, we can see the Contents Editor containing the various playlists we want to switch between, each with full control of their own volumes and such.
In the center of the screen, we have our Association Editor, which allows us to correlate our different playlists with different Switch Game Syncs. To make use of this, we need to have created a Switch Group within our Game Syncs tab, containing a Switch for each element of our Switch Container we want to connect. From here, we can add a path to the Group, then drag and drop each playlist into it’s respectful Switch.
To interact with Unity, we simply use an Event to Play the Music Switch Container.
Over in Unity, we now need a Script to discern when we want to change Switch values. In my project, all Wwise interactions are done through a Singleton pattern, Audio Manager Script so I can track down bugs easier. Throughout my Project Hierarchy, I can call upon the Instance of this Script and access different public methods to interact with Wwise.
This method looks like so, with the Music Play Event simply being called upon Start.
Using AkSoundEngine, we can access the SetSwitch call, and pass in either string or int ID parameters for the Switch Group we want to access, followed by the Switch itself, and which game object this should be posted on. I want the next Switch to be defined depending on who is calling this method as opposed to a linear step through different tracks. Therefore, I created a MusicSwitch script that can be placed throughout the Project Hierarchy, and pass on different Switches.
For each instance of this Script, we need to be able to define which Switch will be called, this can then be selected through the Inspector. We also want to define when to call the AudioManager’s method. Using bools, allows for simple checkboxes in the Inspector, so as to easily visualize when this tool will function.
To make use of these bools, we can check for isTrue, in their respective methods, before then simply calling the AudioManager method, passing in the Switch we defined at the top.
Most music changes in this game are based around different cutscenes, so largely, I am just calling the Switch in the Start Method of the cutscene objects that become active when triggered in game. For the ambient music, I needed to make use of OnDisable with the Opening Cutscene, as this moment is what triggers the start of the game itself.
To keep things entirely separate from the cutscenes, we could very easily make use of OnTrigger methods and attach the scripts to our trigger objects used to enable the cutscenes. Either way, with expansion as needed, this switch system can cover numerous workflows.
Ultimately, having a Switchable music system, saves us from calling multiple events on top of one another, and allows for ease of use when it comes to extending our games.