To drive the sound, music, and motion in your game, Wwise uses “action” Events. These Events apply actions to the different structures within your project hierarchy. Each of these Events can contain one action or a series of actions. The actions you select will specify whether the Wwise objects will play, pause, stop, and so on.

Example 1. Using Action Events - Example

Let's say the character in your game must enter a cave to retrieve some hidden documents. When the character enters the cave from the woods, the ambient sounds in the game should change. To trigger this change, you must create an Event that will contain a series of actions that will stop the ambient “Woods” sounds and play the ambient “Cave” sounds. This Event will be integrated into the game engine and at the moment the character enters the cave, the game engine calls the specific Event that you created in Wwise.

The following illustration demonstrates how the game engine triggers an Event to change the ambient sounds playing in a game:

To deal with the transitions that occur between sound, music, or motion objects, each Event action also has a set of parameters that you can use to delay, or fade in and fade out incoming and outgoing objects.

To drive the dynamic dialogue in your game, Wwise uses the Dialogue Event, which is basically a set of rules or conditions that determines which piece of dialogue to play. The Dialogue Event allows you to re-create a variety of different scenarios, conditions or outcomes that exist in your game. To ensure that you cover every situation, Wwise also allows you to create default or fallback conditions.

All these conditions are defined using a series of State and Switch values. These State and Switch values are combined to create paths which define the particular conditions or outcomes in the game. Each path is then associated with a specific sound object in Wwise. As the game is played and Dialogue Events are called, the game verifies the existing conditions against those defined in the Dialogue Event. The condition or State/Switch path that matches the current situation in game determines which piece of dialogue is played.

	Note
	Although Dialogue Events were initially created to handle game dialogue, they are not reserved explicitly for dialogue and can be used for a variety of other purposes in your game.

Example 2. Using Dialogue Events - Example

Let's say that you are creating a hockey game with a play-by-play commentary. When a player shoots and scores, you want the play-by-play commentary to correspond to the action in game. To set up the different possibilities and outcomes in Wwise, you will need to create Dialogue Events for Players, Actions, Transitions, and so on. Each of these Events will contain a set of corresponding State and Switch values that you have created for your game. You must create a State/Switch path that defines each condition or outcome and then assign an appropriate voice object to each State/Switch path. During gameplay, the game will match the current State/Switch values against the paths you defined in Wwise to determine which voice object to play.

The following illustration demonstrates how Dialogue Events created in Wwise can generate a play-by-play commentary that says “Cross shoots and scores!”:

Every action within an Event has a corresponding scope setting. The scope determines whether the Event action is applied globally to all game objects or to the specific game object that triggered the Event. For some actions, the sound designer can choose the scope, and for other actions, the scope is predetermined.

If we look again at EventB, for example, the scope of each Event action would be as follows:

The following illustration demonstrates how this Event would look in Wwise.

	Note
	Scope is an important concept that applies to many elements in Wwise. Understanding the scope of each element will help you decide when to use each element in different situations.

After creating the Events for your game, the sound designer can package them into SoundBanks. These SoundBanks are then loaded into your game, where the Events can be triggered by your game's code. For example, when the player is killed, you would play the special “Die” sound and stop the “EnergyShield” sound by triggering the corresponding event.

To integrate these Events into your game, the programmer must specify onto which game object the Event Actions will be performed. This is done by posting each Event. An Event should be posted by your game's code whenever you want the audio to change. You can post events using strings or IDs.

One main advantage to this method for triggering sound in your game is that it gives the sound designer additional control and flexibility without requiring any additional programming. All Events are created in Wwise by the sound designer and they are then integrated into the game by the programmer. Once Events are integrated in the game, the sound designer can continue working on them, changing or modifying the actions they contain, or the objects to which they refer. Since your game is still triggering the same Event, the changes made by the sound designer will take effect in the game without requiring extra work from the developer, and without recompiling the code.

The following table shows you which tasks related to Events are the responsibility of the sound designer and which ones are the responsibility of the programmer: