NB: I did say in my previous post that I was covering soundcues, kismet, matinee and more here, but on reflect, it seems that all of those together would be FAR too much for a single post. I'm therefore splitting them down, starting here. Oh to be naive!
Importing Audio into the Content browser: Before I can detail Soundcues, we'll need some audio to use in them. To do so, we simply need to import some audio files. However, this might not seem so straight forward at first glance; it's actually easier than you think.
A small note: If you're interested in best practices for audio editing sounds for games, see my previous post here.
To import audio, you'll need to be in the content browser.
From here, click on the 'Import' button in the bottom left of the window (shown right). A windows explorer dialogue will come up, for which you'll need to navigate to your audio file. Don't worry: once you've found the location once, it opens up in that same spot the next time. It's important to note here that only certain file types will be accepted. The easiest and most widely used format is the '.wav' format. As anyone in sound will know, this is the definitive uncompressed file type that's size reflects the quality - especially in game audio, you need to keep on top of this. However, I'm digressing into memory constraints; on with the plot!The next screen you'll see on choosing an audio file is the import window: this is where you'll choose the package in which the file will be saved, create an optional group and finally name your sound file. The package in this instance is a physical file that will be saved on the disk. The group is a folder inside this package, used for better organizing your files.
Naming Schemes: A very important rule to work by is a set naming scheme for your files, not just audio. The purpose is to help keep everything in the editor organised and give an at-a-glance view of file types (purpose of use that is, such as footsteps, brick wall textures etc). If you have an inconsistent naming scheme, files can get lost and (more importantly) work flow can be broken.
Personally, I favor the single letter groups and underscoring scheme. For example, if I had a sound file for a single footstep in snow, I would start with 'A', as it's an audio file, then 'F' for footsteps, then 'snow' and optionally a number if there were variants. this would therefore read 'A_F_snow1'. Another example would be for a light brown brick wall texture; this would read 'T_B_LightBrown'. Others may not use this scheme, but it's my personal preference.
After you've filled everything in and clicked OK, your audio file should show up in the content browser - success!
You'll notice that, once imported successfully, there are a few '*' characters dotted about the place. This means that a package has been edited in some form and requires saving. By looking at the bottom-left of the content browser (shown left), you'll see your new package, also with an asterisks. To save this, simply right-click and save, bringing up another windows exlorer dialogue.Naming and location of this file is as important as your internal naming scheme. What I like to do is create a new folder inside the one used for your level. This way, you'll have all your assets together. For naming the package, I used the same scheme as before; 'A_Footsteps' in this case. However, you can choose to save all audio in one package, or split it down even further - which ever you're more comfortable working with.
The Soundcue: One of the beautiful things about UDK is it's level of detail for audio implementation, while also keeping things simple and easy to use. One such element of this is the Soundcue.
What is a Soundcue? - Simply put, a Soundcue is a file that refers to soundwave files in order to implement them in the engine. Moreover, it's able to manipulate the audio files, creating small systems in themselves to achieve a much broader complex system as a whole.
Why do we need a Soundcue? - There are 2 main reasons to have these Soundcue files. First of all, they can help shorten the programming time drastically - using object based design, you can quickly add modules and link them together, giving realtime feedback. Secondly, Soundcues will no doubt be referred to throughout the level, especially for SFX such as doors opening or elevators. If the sound for these objects were design and implemented individually for each individual occurance and you change your mind on how the sound works, it would potentially take hours to go round fixing them all, let alone keeping track. However, with a soundcue, you can change it once in the content browser and all references will be changed as well, saving valuable time.
What can a Soundcue achieve? - There are a surprising amount of systems you can create with what seems to be such a simple tool. there are quite a selection of modules to choose from, which leaves a lot of room for creativity. At the end of the day though, it's up to you: you can use them simply for triggering a sound, all the way up to concatenating random dialogue to create a unique randomized sequence every play (more on this system later though...).
Creating the sound cue: this is a very similar process to importing audio into the content browser. However, rather than using the 'Import' button, we're simply going to right-click in the empty content browser space (next to where your audio file is) and select Soundcue from the menu. This brings up the same prompt for importing files, asking for a package name, group and file name. I like to use the same package as the audio, but I choose to put cue's in the parent directory (not grouped). This way, I can see all of them at a glance, rather than searching through each group in each package. Again, this is a personal preference; you may want to do otherwise.
Naming is of course important here as well. The simplest way I find for naming is adding 'Cue' to the end of the audio file name. For example if the audio file was 'A_S_BombExplosion', I would name the cue 'A_S_BombExplosionCue'. Similarly, if you have multiple audio files for the same cue, such as 'A_F_Snow[n]', I would replace the number [n] with 'Cue'.
Now your soundcue is named, placed and saved, you can go ahead and open it up. What you'll find is actually a blank canvas (shown below). The 'speaker' on the left is the eventual output of the soundcue. Everything leading up to it is what makes up the system.
To add your audio file into the sound cue, first open up the content browser and make sure your sound file is selected (yellow outline). Then go to the soundcue, right-click anywhere inside it and select the sound file at the top of the list. You'll be left with the file as a module, shown below:
However, we can't just leave it here, as the soundcue still doesn't have an output. We'll need to 'connect' the modules so that a flow of data occurs. Don't worry though, it's very easy: just drag from one of the small black blocks to another and there you have it! A functional soundcue. To make sure it works, press the right play button (shown right), which will play exactly what would occur if triggered in the game. The other play button plays the soundcue at whatever module you've selected.
The Functions of a Soundcue: This is where it gets interesting. Not only is there the fact that you can achieve quite a lot with a soundcue, but because it works in a flow-chart-like manner, modules can be combined, giving us a huge potential for creative use.
I've used 90% of the available modules in my work, so they're all very useful. Best of all, they're so easy to use! Like I showed you: it's a case of connecting modules together and listening to the outcome. Of course, you can go into more detail with their properties. For example, the 'attenuation' module has editable parameters for min and mix distances of attenuation.
The following provides a more detailed explanation of each module in the soundcue editor. However, as I mentioned, I haven't used them all so I'm going to detail the ones that I know well. If you do want to find out about the other 4 modules, feel free to go to the UDK website.
Attentuation: Apart from any sounds that need to be locked in pan and volume (such as first-person SFX or dialogue), most sounds will require attenuation. What this achieves is a basic distance-volume relationship - the further away you are from the source, the quieter the sound. Another tool within this modules is spatialisation - also key for most sounds, but not the ones listed before. This is the act of sound panning based on perspective, which means that if the source is to your left, it will be panned left. Finally, we have the facility to apply a LPF (low pass filter). If enabled, this will both attenuate volume and gently roll off the higher frequencies with distance.
Attenuation and Gain: Almost identical to the Attenuation module, this simply adds the ability to control more the gain of the source with regards to distance.
Concatenator: Very useful for dialogue, the concatenator is used to 'stitch' audio together to create the illusion of seamless audio playback. When combined with multiple randomised files, you can very quickly create unique SFX with very little memory usage.
Delay: This is as simple as it sounds - it adds a predetermined (or randomised depending on a min and max time) delay before the next module.
Distance Crossfade: Particularly for static ambience soundcues, the distance crossfade allows you to have a 'distant' sound looping, until you get to a predetermined distance where by the sound fades into the 'close' version of the sound. Obviously, you would need to create these near and far version of the audio, but it's a great time saver for a much more realistic outcome.
Doppler: More for when a sound passes the player rather than the other way around, the doppler module adds the pitch-bend effect that occurs similarly to when a car drives by. This must be a recent addition because in all my previous work, I'd never seen it!
Looping: Exactly what it says on the tin - this module loops a sound. You must be cautious with this one though, as you have very basic control for stopping and starting the loop. This is best for a sound that will always loop, such as an ambience.
Mixer: Much like a mixing desk, the mixer allows you to change the volume of multiple sounds irrespective of the overall soundcue volume (controlled in the properties window). A very useful tool when creating SFX or loops with multiple layers.
Modulator: The key to creating repetitive sounds seem non-repetitive is modulation. This is the act of randomly altering the volume and pitch is small variants to give the illusion that one sound file seems like multiple. Great for foley such as footsteps, as well as gun shots, explosions, doors opening and closing etc.
Continuous Modulator: This works in a similar fashion to the attenuation module, which is technically also a continuous modulator, only that attenuation uses the distance and displacement as parameters. An example of continuous modulation is a car engine. When the speed gets higher, the pitch goes up, and when the speed goes down, the pitch goes down. This happens continuously, as there is no need to 'trigger' the car going up or down in speed. Similarly, with speed changes, the volume might increase slightly when in first gear, then will jump back down when up to gear 2.
Oscillator: Oscillation is the constant alteration of values between and a min and a max, usually in a predetermined fashion such as a 'sine' wave or 'saw tooth'. In this case, we can use the oscillator to alter the volume or pitch of a sound. An example might be a siren going up and down in pitch, or the waves at a beach going up and down in volume as they swell and subside.
Random: The mother of all modules: random is the most useful tool in my opinion. It's function is to randomly select from a group of sounds connected to it, either with or without repeating itself. Especially in game audio, you want to prevent repetition accordingly, and randomising files is the first step in doing this. Coupled with modulation, you can very quickly have professional sounding results.
Example Soundcues: the best way to show these modules in use is through example. Below, I've put together a list of systems that I've used, how I built them and why I've made them as such.
Randomizing footsteps - This is a staple system for any game that involves a character that walks. What you want to achieve is as little repetition as possible, unless designed otherwise (the japanese tend to have repetitive footstep sounds for style). The reason we want to prevent it is that you'll be hearing them a lot. No one wants to hear the same sound over and over for hours on end, so we do everything in our power to prevent them breaking immersion.
Above, you'll see a system that I've mentioned a few times. Here, you'll see 4 sounds being referenced on the right which are individual footstep sounds; that is, a single foot. These are then fed into a random module, which both plays them out of any repeated order and makes sure a single sound isn't played twice successively. Finally, the output goes through a modulator which alters the pitch and volume to further prevent repetition.
We could take this one step further by including a scuff sound when you catch your shoe on the floor rather than a full step sound. We could also split the footstep sounds into 2 (the back of the shoe and the front of the shoe hitting the floor), which would create an almost lack of repetition.
Cross-fading a Waterfall - It's very easy to create a waterfall loop out of a single sound file and have it attenuate with distance. As anyone knows, a sound almost develops the closer you get to it and certain features (such as splashing on rocks) fade in that weren't apparent at a distance. To solve this, we can have 2 separate sound files looping, which are faded between the closer or farther you get.
What we have here are the two sound files (right), named accordingly for the 'far' sound and 'near' sound. These are first fed into the loop modules, making sure the files aren't interrupted. Finally, we have the Distance Crossfade module. Within the properties (right), we can adjust the distances intricately, so that the fade is to your preference.You're also able to add more inputs to the module, meaning you could have 5 or 6 different sounds crossfading all within this soundcue. One use for this could be a weapon firing, which has several layers of the same sound that performs differently depending on the distance. Close up, you would get a very bright and low-end burst, with another layer that has less lower frequencies at a further distance, a third layer which brings the top end off and a slight delay further again, and finally a layer which is particularly dull for a great distance.
Dialogue Randomisation and Concatenation - In preventing repetition, there are issues in all aspects of audio, including dialogue. When you have a lot of NPC's, the volume (pun not intended) of dialogue can balloon and before you know it, almost half the games memory can be taken up with it (just take a look at any Bethesda game post-morrowind). The system below is a way of resolving part of this issue.
What we have are 3 instances of dialogue, with 2 of these instances randomised each time the soundcue is activated. First, we have a single line of dialogue, which feeds directly in to the concatenator. the second section uses a few different modules: there are 3 variations of the line to be used, of which one is picked at random. This is then fed into a delay, which is used to give a natural pause between this and the first line. Finally, we have the same setup for the third line, only with 2 variations rather than 3. To those who wouldn't know, the outcome would sound like a single audio file.
More Next Time...: So those were 3 examples of the kinds of systems you can achieve with a soundcue. I hope it gave you an insight into what is only a small part of what makes up audio implementation in UDK. However, I'm not really finished yet. Next time, I'll be covering Kismet, which is a whole different world in itself. With it, I'll be showing how we'll be able to trigger and manipulate these soundcues. A very satisfying part of the process I can tell you!
Conclusions: As I've just said, this is only a small part of the audio implementation that's available. I could go a lot further and certainly a lot deeper, but I could go on for far too long. If you're planning to get into this, have a good play with all the modules; some you won't be able to use properly until they're in-game, but implementing a rain sound from single raindrop sounds that are chosen randomly, concatenated and looped is a good challenge.
At any rate, enjoy having fun with this and I'll be back shortly with the fun of Kismet!
Alex.
No comments:
Post a Comment