XNA: Why use Xact when I can use Content.Load?

Question

I have to add sound to a game and I found that you can use xact. That's fine, however why not just use Content.Load?

Besides the tweaking of the sound, are there any other advantages to using Xact?

Answer 1

There's a little more to game audio than just playing back and fading in/out sound files.

XACT is primarily useful when you're working with a sound designer who either has no coding experience, or no desire to work in code.

Omnion's answer covers the essentials:

• Grouping sounds for selecting a sound to randomly play back

• Grouping sounds for organizational purposes (maybe have multiple sounds with the same name but in different groups, so you just need to keep track of which group you're in

• Easier control of realtime effects

Among the few (all small or indie) developers I've worked with, there's a bad habit when thinking about game audio to describe your audio needs exclusively in terms of asset lists. While you do need to eventually keep track of all the different sound files you need for a game, it's not useful at all in describing how multiple sound assets work together to create an overall sound event.

XACT and other tools like FMOD and Wwise create an interface between sound designer and programmer. The sound designer creates a Sound Cue, Event, or Sync (terminology depends on the tool being used) that can be referred to either by name (const *char or string) or by a GUI in a header or config file. This sound event contains multiple sound files that play back in a specific way that are controlled by parameters, which are usually variables associated with a sound event that control playback.

Here's Microsoft's article about parameters in XACT: http://msdn.microsoft.com/en-us/library/ee416028(v=vs.85).aspx

So the breakdown is this:

Sound Designer:

• Creates sound files using whatever their workflow is
• Creates an XACT project that includes all these files
• Creates SoundCues and Real-time parameter controls that affect sound playback, and communicates to the programmer what each real-time parameter represents (could be

Programmer

• Takes the built XACT project, loads it into the game
• Plays the appropriate SoundCues at the appropriate times
• Modifies the real-time parameters as he and the sound designer have agreed upon

The classic example is a car engine. Here's a video someone made of their car engine model in FMOD. In this example the programmer would need to do the following:

1. Grab an instance of the CarEngine SoundCue
2. Optionally adjust the RPM Smooth, Load Smooth, and Scale Smooth parameters (sound designer can specify defaults).
3. Trigger the SoundCue
4. Update the RPM parameter as the player accelerates.

More than Cars

I'm using FMOD on a project to control the movement of robots.

• If the programmer wants the robot to start moving: they play the RobotStartMove event, which triggers an initial start-from-idle sound, while fading in a looping whirring sound. The whirring sound starts at a slightly lower pitch than the loop and gradually pitches up.
• If the programmer wants the robot to suddenly change directions, they set a parameter called "time" to 0.05 (it's a generic parameter that interpolates between values at 1 unit per second, so this name made the most sense).
• If the programmer wants the robot to stop moving, they "keyoff" the time parameter (timeParam->keyOff();). Which basically just advances the time parameter to its end, as it does so, the whirring loop pitches down slightly while fading out to give the impression of the robot's motors slowing down.

XACT, FMOD, and Wwise are also really useful for footsteps, you can create a "Footstep" sound cue, which has a bank of different footsteps. It will select one at random, adjust its pitch randomly (within a limit).

The bottom line with these tools, is that your sound designer probably knows what sounds better than you do, so let them define the behavior in an abstract way, so then you only have to adjust some predefined parameters to get the desired effect.

Answer 2

Xact is a bit harder to use than the Content Pipeline method. It was originally the only way to play sounds, but the team added the Content Pipeline method for an easier way.

Xact lets you do stuff like:

1. Group sounds so you could mute or do something to a select group of sounds (like mute menu sounds)
2. You can have Xact change or choose from multiple sounds to play one sound (so your game engine doesn't play the same repetitive shooting sound over and over)
3. You can apply effects and other stuff and it really gives you some cool features and abilities. It's also pretty nice for working with sound editors because they don't have to work with code, just the Xact editor (which isn't easy, but it's more direct in purpose).
4. I'm not an expert, so there are probably other features that I haven't named, but I think this gives the gist of it at least.

Anyway, learning Xact can be a pain. Only do it if you really think your going to need it. Perhaps you could set up an abstraction in your game so you could switch to Xact a bit easier? If your going to have a lot of sounds and your going to want some of the above features, Xact might be the way to go. Personally, since your kind of new, I would just use the Content Pipeline method and switch to Xact if you really found the need for it later.