Table of Contents
A switch is a change in the game action or environment that requires a completely new sound. The switch system has one purpose: driving switch containers on a game object basis.
For example, if ground texture is set as a switch, the ground texture decides which sound will be played when a footstep occurs:
The switch group could be:
And the different switches of this group could be:
At a given time, if two different characters are on two different ground textures, the switch-states of each character will be different.
If there is no current switch for a switch group, the switch group uses the default switch. This situation may occur at the beginning of a game, or during development. A switch container will also use the default switch if the game code refers to a switch that does not exist. For example, if the sound designer changes a container to remove a switch, but does not inform the audio developer, that switch remains in the code. When that code is executed in the game, the switch to which it refers no longer exists, so the default switch is used.
You have three options to drive switches: the SDK AK::SoundEngine::SetSwitch() method, the "SetSwitch" action generated in Wwise events, or RTPCs. However, combining these options can be problematic. For example, if sound designers introduce SetSwitch actions inside the events they create while audio developers drive switches using the SDK AK::SoundEngine::SetSwitch() command, the switches may become difficult to control. We strongly recommend that sound designers and audio developers decide how the actual switches will be driven, either for each switch group or for the entire project. All three ways can be used together, if there is agreement on how switches will change. For example, the audio developers can initialize switches using the SDK AK::SoundEngine::SetSwitch() command, but leave the switch to be driven by events for the rest of the game.
There are two ways to set a switch from the SDK: using strings(unicode or ansi) or using IDs.
Using strings makes code more readable and is suitable during development time, or when working in an environment that normally uses strings. Using IDs avoids string look-up time and saves memory that would be used for storing string mapping.
Setting a switch from the SDK is as simple as calling:
AK::SoundEngine::SetSwitch( L"Ground", L"Gravel", myGameObject1 );
AK::SoundEngine::SetSwitch ( AK::SWITCHES::GROUND::GROUP, AK::SWITCHES::GROUND::SWITCH::GRAVEL, myGameObject1 );
The third parameter of the SetSwitch() function is the game object to which the switch should be applied. When an event containing a play action is triggered using this game object, it will use the specified switch to select what to play in the switch container. If a switch has not been set for a game object, the object will use the default switch specified in the switch container options.
Note that when a game object is unregistered, its current switch is also erased. If the game object is used again later, this switch will have to be reset.
For more information, refer to Integration Details - Game Objects.
To work with IDs, the banks must be generated with the "Generate header file" option in the Generate SoundBanks dialog box in Wwise. The definition file, named Wwise_IDs.h, contains all the required IDs. It is updated at each bank generation.
The main difference between a state group and a switch group is that the switch will be different for every game object in the game. Another difference between states and switches is that when a switch changes, only switch containers will be affected. When a state changes, it may affect switch containers but may also change the parameters of various other objects (sounds, actor-mixers, busses, and so on).
||Tip: If a switch is global in the game, and applies to all game objects, use a state (which is already global) instead of setting a switch to every game object. This will save you work and save the platform memory and processing time.|
For an example of integrating switches, refer to Switch Example.