Part Three: Implementation!
This is the third installment of the development blog of my UDK Demo, you can check out the beginning, part one, by clicking the link below!
Or maybe you've already read part one! You can read part two here:
One of the best things that has been happening in the last few years is the advancement of game engines. Engines like UDK, Unity and Cryotech have been not only advancing in technology and capability but also in availability and accessibility. My favorite thing about UDK is not just because the engine is free but really because it has a built in audio system that is so intuitive but yet not too simple that you can't do complex things if you have the know how. These built in audio systems allow the sound designers, sound effects editors and composers on games to get more creative control over how their sounds interact with the players in the game and with how they are heard. It allows us as audio creators to see our work through the entire process and become more involved with the creation of the game. Soon the days of creating your sounds and music and handing them to a programmer will be completely gone(if they aren't mostly already) with the development of comprehensive built in engine audio systems and audio middleware.
The implementation in this project can be divided into three main categories;
(These are in no way official or completely accurate names, so don't quote me on them!)
Player Character Objects
Environmental Placement
Environmental Triggers
Player Character Objects
The first category is all the player character related objects such as weapons, vehicles and pick ups that the player interacts with. The implementation for these kind of things is handled entirely in the content browser inside of UDK and is very straightforward, provided that the programming end is already done. The programming end being that the sound cue names are already being referenced by the game.
Now what is a sound cue?
A sound cue is a file that plays a sound when it is triggered. It is not the sound itself, but rather something that references a sound node wave, which is what UDK calls the raw audio file. Inside of UDK this is how all triggered sounds are triggered, through sound cues. You might wonder, well why can't we just reference the sound node wave directly. But the benefit of a sound cue is that it allows us to set up a signal flow for the sound to pass through before the player hears it. We can add modifiers, layers, delays, etc into the chain to create many different effects or to serve many purposes. For example, The shock rifle has two sound node waves referenced inside of its sound cue. The first sound node wave is the fire layer of the weapon, this is the sound that mechanical parts of the gun makes. The second sound node wave is the actual shot of the gun. Now by using a sound cue we can layer these two together into one trigger instead of having to reference them twice inside of the code. This also gives the sound designer the option to add as many layers and active effects as they want to something without having to consult a programmer to add the changes in.
Now the reason why you would want multiple layers divided into separate sound node waves instead of bouncing it all into one sound node wave is so that you can actively effect each layer. What if you want the gun to sound random each shot, but you only have one version of each of the layers? You can add a randomizing modifier into the signal flow of each of the sound node wave so that each layer randomizes separately in a different way each time you fire the gun! Of course all of this only touches the tip of the ice berg of possibilities!
Now if you were to be actively working on a game project, you would create your sound cues based on either the names the programmer had given them when writing up the code or if something hasn't been programmed yet you would create your sound cues and give the list of names to the programmer to use. Given that I was working straight with the stock Unreal weapons, pick ups and vehicles that come with UDK, all of the sound cues were already created and programmed to work with the game. My end of implementation was to either match the sound cue's original names when I created new sound cues so that the code would find them or to just edit the original sound cues by removing the old sounds and placing my sounds inside of them . I used a mix of this depending on each item in specific.
How do you create or modify a sound cue? Well I wish I had time to explain but I've already delved into this topic enough for one blog post. I suggest you download UDK and find an online tutorial. There are plenty and I'm sure they would explain it much better than me!
Environmental Placement
This category of implementation is by the far the simplest but is still incredibly important. Whats great about UDK's audio system is that it allows you to fly around the map and place sounds where ever you want through the use of sound actors. Sound actors are like little speakers that you can place all over the map that play sound. They activate whenever a player steps into the radius of the sound actor, you can however have a sound actor player indefinitely regardless of player position but I don't recommend this (unless you want to use up limited channels in the audio system and processing, your call). The great thing about sound actors is that they allow you to literally build your ambiance. All you have to do is load the audio file into the content browser for the sound actor to reference. There are a bunch of different types of sound actors but the ones I am going to cover, as they pertain to my project, are Ambient Sound and Ambient Sound Nonloop.
 |
| Sound Actor radius |
The ambient sound sound actor is the one of the most basic of all the sound actors. Place the sound actor and the sound plays. The complexity and usefulness comes in the details you can edit such as volume radiuses, which control how big the area is in which the sound is heard , filters and modulation of the sound, such as pitch and volume. (Like the sound cue, I won't go into the details of each section) I mainly used these to create the ambient tones of the cave but they can also be used for static objects such as the hum of the generator for the lights or the hum and whisper layer of the crystals in the level.
 |
| Ambient Sound and Ambient Sound Nonloop actors |
|
The ambient sound nonloop is very similar to the ambient sound, but allows you to load multiple sounds into it that can be randomly triggered. This is most usual for creating a group of randomly triggered stingers to add to the ambiance. I used these in my map for the rumbles and rock slides of the cave and also for the ambient whispers of the crystals. Just like the ambient sound sound actor, you can modify volume radius, filter radius, and modulation. You can also modify the time between triggers.
Environmental Triggers
The third category of implementation that I used in my project were environmental triggers. This basically encompasses reverb volumes, trigger volumes, sound classes and some Kismet.
Reverb Volumes
I'll start with reverb volumes. I wont delve too much into volumes, but using the brush tool, in UDK you can create something which is called a volume. A volume is a 3d box palette of sorts with which you can achieve many purposes. In this case, I used reverb volumes in specific. using the brush you can create zones in which sound will reverberate. Its very basic, take a room, create a reverb volume around that room with the brush tool, and any sound you place inside of that room with have the reverb set to the volume.
 |
| Reverb Volumes! and much more! |
Now this being a small map, there were only three reverbs that I set up. First I created a large reverb volume that I placed over the entire level to set a general cave reverb. Next, using reverb volume priorities (which allows me to set which reverb will be heard when multiple are over lapping), I set up a bunch of smaller reverb volumes inside of the larger volume for all of the tunnels throughout the map so that they would have a different echo than the main rooms of the cave. Finally, jus for the area of the cave with water, a set a third reverb using one small reverb volume just over the passage with water, I wanted this area to have a large high end sewer like reflection because of the water and the metal pathway that hangs over it. These are just the basic features of a reverb volume, you can use them for isolation, occlusion and much more!
Trigger Volumes
In this particular map I set up two trigger volumes. These are the same concept as a reverb volume, except the volume you create acts a detector and triggers an event when the trigger condition is met. These are usually tied to events that are created in Kismet, the audio scripting section inside of UDK. A simple example of how this works is that you could set a trigger volume to detect when a player steps into it, upon the player entering the trigger volume, it will then be triggered this causing the event tied to the trigger volume to activate( like a sound or a cinema)
Both of the trigger volumes I used involved the water section of the level. The first thing I wanted to do was create an underwater sound and atmosphere when the player went under the water. To do this I set a trigger volume over the water that would change the sound class whenever a player entered the water. I created a custom sound class that would turn on a low pass filter and tied this to an event in Kismet. I then tied that event to the trigger volume. To finish up the underwater sound, I placed ambient sound sound actors in the water that played a water sound and then placed a reverb volume around them. Using the isolation features of a reverb volume, I limited the sound to just the area of the reverb volume so you would only hear it underwater. This is a great example of using everything I have talked about in conjunction!
 | |
| A view from outside the map of the volumes. |
The second place that I used the trigger volume was to create a gasp from the player whenever they exited the water. To do this I used two trigger volumes in front of each other before the player enters the water and created an event in Kismet. I won't go into ay of the Kismet scripting details as its a bit of an explanation on how its achieved.
Conclusion
Well that about wraps it up! At this point I've covered the highlights of my UDK sound design demo. Going forward I hope to expand my knowledge of UDK and keep learning! Who knows, maybe I'll write more UDK blogs in the future. If you stuck with me through this whole thing, then Thank You very much for reading! If your just joining me, well I still appreciate it!
As always, Thanks for reading!
-Matthew Hagberg
