UDK Audio Implementation - A Lot From A Little
Continuing my work on The Game Audio Tutorial, I’ve started lessons on memory management and how to get the maximum creative content out of a small number of samples. Based on some feedback on my last post, instead of just rehashing the tutorials I’m working on, I’m going to try and relay what I’ve learned independent from the stuff in the book. I’ll still be working in UDK, but I’m going to leave off posting video or interactive stuff until I’ve got some of my own levels illustrating interactive audio concepts.
So, onwards!
If you were following me on Twitter today you probably saw me posting excitedly about SoundCues. The reason I was so emphatic about these is because they start to move away from the association sound has with image in linear media and do things only capable in interactive media.
Example: In a movie, at a single point along the timeline, an explicit combination of sound and image will show. This could be the footstep of a character.
Simply attaching a sound file to a characters foot could recreate this in an interactive environment, with the player controller when that explicit moment happened (and maybe changing the exact image with the camera). I would liken moving the character around and triggering this sound to scrubbing along the timeline of a film over the same spot again and again.
SoundCues allow the developer or sound designer to start creating systems of audio for events as opposed to single files. If we use the example above, I learned today how I could make it that a footstep could have a huge number of permutations from something like only 4 different sounds.
So what are SoundCues? SoundCues are essentially a collection of sounds and a system of triggering them which can be attached to Sound Actors in UDK. Examples will do a better job of explaining this than I can.
Example 1 - Random Sounds
The above image is a SoundCue that triggers a random sound from a selection of the 6 sounds on the right. The “Random” node chooses from the sounds coming into it at random (unsurprisingly). The “Delay” node creates a delay between each sound playing, in this case I think it was set to 3 seconds. The “Looping” node keeps the process looping. Without it, whatever the SoundCue was attached to in UDK would only emit one (randomly chosen) sound and then stop. The “Attenuation” node is similar to the properties of a SoundSimple Actor and defines how loud the sound is in the game at what distance from the player.
The approach shown above can be used to create ambiences to great effect. Let’s say for example the developer wanted to create an ambience for a jungle. They could record a 45-second clip from an actual jungle and loop this in game. However…
- 45 seconds of audio is a lot, and takes up a lot of memory that needs to be shared with art and programming assets.
- Even a clip as long as 45 seconds will be noticed for repeating if the player spends long enough listening to it.
If we substitute the sounds on the right for 6 jungle noises (e.g. monkey1, monkey2, parrot1, insects1, etc), the “Random” node plus the “Modulator” node will vary the loop in a near-infinite number of ways, giving a more convincing ambience the player won’t notice with a much smaller memory footprint. The “Random” node even has an option where it will cycle through all its inputs before repeating any of them, removing the possibility of the same sound repeating 3 times in a row and sounding unrealistic. It’s clear to see how this is a superior approach.
The second example I want to look at used footsteps to illustrate its point, but I can think of other situations where the following approach would be incredibly helpful (shotgun blast + reload sounds spring to mind…)
The “Concatenator” node plays through its inputs one after another. This enables you to sequence sounds comprised of multiple parts (see how the shotgun fire + reload would work now?). In the case of footsteps, this is a fantastic approach. Footsteps are something a player of a game will hear for hours on end, therefore avoiding using exactly the same sound is key to keeping the player immersed in the game and not drawing them out by having them notice repeating sounds.
Instead of having, for example, multiple different footstep sounds, the “Concatenator” node allows the developer to choose randomly from a selection of sounds for the “heel” part of the footstep, then choose randomly from a selection of sounds for the “ball” part of the foot. Straight away, this gives us 4 x 4 = 16 different sounds from 8 small samples. Add in the “Modulator” node again, and it’s easy to see how we could further the variation. You could even put a modulator after each “Random” node to vary the sound even more.
These last few chapters and exercises in the book have been even more exciting because I’m starting to get into the aspects of sound that are exclusive to games. I’ve learnt a lot (and still have a lot to learn) from film, but it’s fantastic to move towards interactive audio and the things specific to that medium.
Day 16 of #30daysofcreativity.
