Dynamic Music Creation Using Wwise Part 4

Article by Louis-Xavier Buffoni

This Is The Fourth Part In The Series. If You Have Not Read The First Part Start Here.

Example: Controlling Drums in the Idle State

The Idle state spans from 0 to 29. At 0, we assume that the player is very far from the action, but at 29, the player has pretty much one foot into Mid already. We can smooth out morphing into Mid by adding some filter-controlled drums into Idle. To do so, add a drum track on every segment of playlist Idle, except "IdleSilence", and route them all to a separate bus, "Drum Idle".

On that drum, place an EQ effect configured as a high-pass filter, and map it to the "Intensity" variable with the curve shown below (see image below). Change the transition rule from Idle to Mid in the switch container so that the transition segment (Intro) will only play when Idle is playing "IdleSilence". While playing the switch container, try sliding the variable slowly between 0 and 30, as a game would do: the drums gradually become more present. At 30, a transition is scheduled towards Mid, and the "real" drum of the Mid's segments kicks in.

Finalizing: Designing Other Transitions

There are two things regarding transitions that we haven't discussed yet:

1) What happens when the intensity drops, forcing a transition from High to Mid for example?

2) What happens if the intensity changes faster than the time it takes for our transitions to complete?

Backward Transitions

A premise of the game design was that once Climax was reached, it would get stuck there and the game would end. For the rest, we need to handle transitions in the reverse order. Let's copy our music switch container structure, call it "04_Final", and define transitions for Mid to Idle and High to Mid. Generally, the same simple rules used for normal transitions work fairly well with backwards transitions.

Jump Transitions

Now, what if the intensity changes faster than the time it takes for our transitions to complete? It is best if we understand how the engine reacts in this situation. A music transition resolves when the synchronization point is reached. For example, if the transition rule says "exit at next bar to destination's Entry cue", then the transition resolves when the current segment's next bar coincides with the destination segment's Entry cue. However, when a second state change occurs before the synchronization point has been reached, the engine reverts the transition if it is not too late, that is, if the destination segment has not started playing, and then schedules a new transition between the current segment and the new state it has to transition to.

Here's what happens if the intensity is 0 (Idle) and changes very quickly to 80 (High):

- When it reaches 30, a transition is scheduled to the Mid state, with the first rule that matches the current segment of Idle and playlist Mid;

- When it reaches 70, the transition that has been scheduled and did not have time to complete is reverted, and a new transition is scheduled to High, with the first rule that matches the current segment of Idle and playlist High.

Try this and see for yourself. Set the intensity to 0, press play, press Start Capture in the top of the window, and use the slider to set the intensity to 80. Press F6 to view the capture log. Notice the messages "Scheduled transition [...]", "Music transition [...] was reverted", and "Music transition resolved to [...]" (see image below).

Knowing this, we need to ensure that our design works well with quick state changes by designing transitions from Idle to High, High to Idle, Idle to Climax, and Mid to Climax.

Surprisingly, it was fairly easy to make them sound adequate. Often, a custom cue in the middle of 16-bar segments with "Next Cue" transition rules results in faster transitions. Other times, splitting segments in two is needed, in order to define different rules for each half.

Also, notice the use of another zero-sized transition segment ("Trans_idle_to_high") with the crazy drum part of Drop01, placed just before the cue, in the Idle to High rule.

What's Next?

This is where I have decided to stop. Notice that I have not tried to integrate any stingers. I could have also exploited more the availability of the continuous variable for more RTPC-driven variations: volume, low-pass filtering or other effect properties.

I could also have added a second game-driven variable to the design. There are several ways to this, and the best is often not achieved by stacking several switch containers. The best solution always depends on the relationship between both variables. But I will leave this all for another article. Stay tuned.

Bio

Louis-Xavier Buffoni is a software developer at Audiokinetic and part-time musician. The author would like to thank Judy Lapalme, George Spanos and his colleagues at Audiokinetic.

blog comments powered by Disqus