Rodney Gates Special: Early Challenges – Authoring Sound for “Darkwatch” on Two Very Different Platforms

[Written by Rodney Gates for Designing Sound]

All SKUs are created equal…right?

It is a common question every time a new game is released on the console platforms: “I have both systems. Which version should I buy?”

In a perfect world, any game created for the consoles would run just perfectly on them, without any performance edge leaning towards one machine or the other. Perfect frame rate, glitch free in every way and beautiful experiences for all!

But of course we do not live in that world. Though things have improved with the current generation of consoles overall, it is still often said that the smart choice is to find out which console the game was developed for first and you’ll most likely have your answer.

Darkwatch: Curse of the…middleware?

“Darkwatch” was a great game to work on. Blending the Wild West with vampires seemed like a perfect fit for an FPS back when the PlayStation 2 and original Xbox ruled the living room. Both machines were great in their own rite, but were quite different in their design. So naturally, they had very different requirements for getting sound into the game.

Unlike today’s market where the Xbox 360 has had a significant head start on the PlayStation 3, the inverse was true for the previous console generation. With this being the case, when Sammy Studios began development with “Darkwatch”, their initial eye was on the PS2. For authoring sound in the game, we were using Sony’s proprietary audio tool called SCREAM.

The PS2 had a whopping 2 megabytes of memory for sound – a ridiculous limitation even for the time, especially when we had allotted 8MB on the Xbox (and that felt like a luxury). We also had streaming-from-disc support to play larger files like music and ambience that simply couldn’t fit otherwise. If memory serves, we had a total of 4-6 streams to cover music, dialog, ambient beds and other 3D flyby and player-positional sounds. All of the rest of the game’s sound had to fit in that crazy 2MB.

Every sound we created for the game was ultimately divided up into the smallest possible slivers of sounds, often at wildly varying sample rates. Nothing other than music was 44.1 or 48kHz. Ambient beds were 24kHz (better than that raspy 22.050). The initial blast of a gunshot might have been 28 or 32kHz to maintain it’s bright attack, while the canyon echo tails at the end of the sound could be reasonably knocked down to 12kHz before they started sounding too nasty.

The weapons were dynamically loaded, and we could only have 2 loaded at any time – usually the pistol and whatever other larger weapon you had on you. By doing this, we had to block out a chunk of memory that the heaviest gun, memory footprint-wise, defined. When that particular weapon wasn’t loaded, there was always a bit of precious space floating around in there that we knew we’d never get back.

One benefit of using such tiny sounds was the ability to re-use them for the creation of other sounds. Some new sounds weren’t created in Pro Tools at all, especially towards the end of the project when we had a lot of material already. We’d just piece together something out of the palette, using SCREAM’s ADSR envelope, and save some memory while we were at it.

The Other Shoe

About mid-way through the project’s development, we needed to start getting our assets ready for the Xbox. We were going to use Microsoft’s tool XACT, so after getting it all set up, away we went.

Initially, I thought I’d just begin re-creating the sounds in the same manner as we did with SCREAM, since we already had all of our little sound slivers exported from Pro Tools that way. XACT was pretty different from SCREAM, but I was sure it would work.

Boy was I wrong.

SCREAM had a cool feature called “child sounds” that we used quite bit in our design. Since building a sound out in SCREAM with tiny slivers of audio was tedious, this was one way an already-designed sound could be played along with a different sound. This way we wouldn’t need to keep re-creating that sound over and over again. For example, the spurs we had on Jericho’s footsteps were child sounds. The footsteps would play their random variants for heel and toe, and the spur sounds would also play.

XACT did not have this feature, which made the process of re-creating the work very tedious. This, in turn, added a lot more “events” to every sound that was created.

XACT’s events were how every sound or parameter change for a sound were used in the tool. As I began stringing things together to regenerate what we had created for the PS2, most of these XACT sounds ended up using many, many events.

We quickly realized this was going to be impossible. XACT only had a bandwidth of 50 or so events that could play during any given frame of gameplay, and once we started playing the game, whole sounds or parts of sounds were dropping out all OVER the place. Quite the disaster!

Back to the Drawing Board

In the long run, we had to fire up the months-old Pro Tools sessions to re-export as much of the audio as we could in larger or whole files to lessen our event overhead with XACT. That is, the ones we could locate if the sounds were old enough to have been worked on by people that were no longer at the studio.

The sounds that were assembled solely within SCREAM were the trickiest, as we couldn’t always locate the original sliver exports. This was a real pain in some instances; the only way we got around it on rare occasions was to literally re-record the sound out of SCREAM itself. Not ideal by any measure, but a necessity due to time.

Despite the challenges, and the fact that the PS2 was the first console “Darkwatch” was developed for, I still feel the overall better-sounding version of the game is on the Xbox. We didn’t have to crush the sample rates nearly as much and the whole system seemed to “breathe” easier as a whole.

In short, it’s the copy on my shelf.

Twice is Not Always “Nice”

Nowadays, I would hope to think that we are mostly past this issue of having to use totally-different tools for each SKU for a game that is released. Much of the audio middleware out there seems universally compatible with all of the hardware, and programmers have kept an eye on this when designing proprietary engines, requiring minimal fuss on our end in working with them.

It’s enough work to create a game; no one should have to do it twice!