In this multi-part series I want to share experiences I made with the UDK along with some personal thoughts. This will be no thorough test of this environment but rather a look at how I felt during development, what I liked and disliked. In the case of UDK, it was about 1 week. OK, let’s dive into UDK!
Please read part 1 to get an idea of what I’m looking for in a game development environment.
About The UDK License
I find the Unreal Development Kit to be very attractive for developers. First of all, it’s free. You don’t get stripped down versions of the software, you get the full thing. The UDK license text is very comprehensible. The license model says (paraphrased) you can use it free for the development (including team features such as SVN integration) until you put out a commercial product. Then you’re subject to a one time fee of $99. That’s it until your game hits $50’000 in revenues. It’s 25% royalties for all revenues above $50’000 from that point on.
Obviously, many very high profile games were developed using this piece of software. But what does it offer a sound designer?
The UDK has an integrated and comfortable sound environment. Audio guys are able to develop sounds in a fairly easy to use node editor called the SoundCue Editor. Sound objects are therefore called SoundCues and can be composed of several sounds that get played back following sophisticated rules. But fear not, no programming required! The SoundCue Editor features a few logical building blocks that put you in charge. It’s like playing lego and really easy to learn. For example, you can have a number of different sounds for one event. Think of several single footstep sounds you recorded. Put them all into a SoundCue object. Now you need to tell the UDK to randomly pick one and play it back each time the footstep event gets called. Just put a random node and connect all the individual sounds to it. Now, every time you trigger the event, the random node picks one of the attached sounds. Voilà! It’s as easy as that. Click to enlarge.
For ambiences, you can define sounds that loop within a cue, and additional random sounds that get triggered every once in a while. For this, you would place the random sound node in front of the individual sounds and add a random time node. Tell this node to trigger the random node every 5 to 10 seconds. Connect the sound this setup produces with a mixer node where our looping sound comes in, too. Voilà! You have made a more complex, almost sophistically sequenced sound environment.
There are maaany other node types for you. You have access to modulators that randomise / modulate sound parameters such as volume or pitch. Each time an event is triggered the node will modulate the pitch a little bit and a single sound will never sound quite the same. This gives a much more natural feel and saves you the work of creating dozens of different sounds at different pitches.
Every audio event you put together this way is saved to the central Content Browser, where models and textures reside, too. From there, developers can attach these audio objects to events like footsteps, gun shots, collapsing buildings, etc. Ambiences can be placed in 3D space directly by sound designers with no help of developers. That’s cool.
Working On Sound
The SoundCue Editor is also a sound player. You can immediately test what you’re putting together. All the logical components work in the player and you can debug sounds and tweak settings very quickly. Everything I used in this week of testing UDK were available from within the SoundCue Editor with no programming required. I could also define attenuation settings of sounds and create audio zones, or reverb zones. That means areas that have a special reverb filter applied to them such as hangars or storage halls so you don’t need to develop the same sounds for these different environments. UDK does that for you.
From the little time I spent in UDK (about 1 week) I can say I liked it. I could develop sounds very quickly and immediately verify what I was doing from within the SoundCue Editor. No need to compile or run the game. And all without involving other developers too much (apart from implementing the audio events).
For people still wanting more, there is a plugin that enables full FMOD integration. It should allow importing FMOD Designer packages.
Read part 3 (Unity 3D) of this series.