• Combo System & Attack Chains
• Instance Limiting Overhaul
• Active Controller Detection

Combo System & Attack Chains

Previously, combat basically consisted of hitting the punch button over and over to kill monsters. This sucked.

I took a few major steps to address this:

First, I added a second attack type bound to the button I was previously going to use for the grappling hook. This attack is slower and hits heavier, with a wider attack arc, and gives you a nice alternative to the fast, lighter-hitting punch attack.

After the addition of the second attack type, I built on that to add ‘combo’ variations of each attack (punch combo, slash combo). The player can combo these attacks onto a previous attack by properly timing another button press near the end of the previous attack animation. Missing the timing (either by pressing too early or too late) ‘botches’ the combo and causes the delay before they can perform another attack to be longer than it would be otherwise. The size of the time window in which you can successfully combo an attack decreases every time you combo, so over time it gets harder. This means that simply attacking once will be slow and inefficient, but you are also prevented from comboing attacks indefinitely, which strikes a good balance. The fact that a failed combo has a longer delay than a normal attack means that a player won’t be punished for choosing to simply combo once or twice and then attack again, since the effectiveness ends up being nearly the same.

Finally, I added a ‘attack chain’ system that tracks the number of hits you land on a foe in rapid succession. This allows me to delay the ‘flinching’ animation normally played when a creature recieves damage, so that the creature stays within reach of your attacks, allowing you to combo. Each successive hit extends the chain for a short period of time, allowing you to continue landing blows, and when the chain ‘breaks’, all the hits you landed deal their damage to the creature at once, knocking it back and possibly killing it. Chains can span across multiple creatures as well, allowing you to keep multiple enemies ‘locked’ by your chain at once. Right now it’s a bit overpowered, but I think some careful tuning will maintain most of the positive aspects without making the game too easy.

Instance Limiting Overhaul

Recently, while working on audio improvements, Troupe ran across a bug in XACT. PC builds of the game ran perfectly without any significant CPU usage problems, and the audio sounded great – but on the 360, as soon as enough channels of audio started playing, the game’s framerate tanked to around 15FPS and stayed there indefinitely. This was despite the fact that the game already issues most of its audio calls on a background thread to work around the prohibitively high cost of XACT’s API calls.

The problem turned out to be that despite the fact I was using XACT’s built in instance limiting support to control the number of instances playing at once, XACT was struggling to handle the number of cues I was asking it to start at once. Essentially, I was starting all the ambient loop cues for my level at once – around 30 – and expecting it to pick the 8 loudest ones to play at any given time based on the instance limit. On PC this worked perfectly without any performance issues, but for whatever reason, not so on the 360.

As a result I basically tore out all the existing code that relied on XACT instance limiting, and reimplemented limiting inside my engine. Luckily this only required changes to about 500 lines of code, but it was still rather frustrating to have to reimplement it when it worked perfectly on PC. On the bright side, now I have more control over how instance limiting behaves, so I at least got something out of it.

Active Controller Detection

While doing some testing on my 360 I realized that my approach to handling the 360 controller was incorrect. While I assumed that the player might want to play with any of their four connected controllers, I neglected to notice that most of the XNA Guide APIs (storage device selection, etc) are designed to only respond to input from a single controller. This meant that I needed to detect which controller the player was currently using and make sure to only show XNA dialog boxes using that controller, and that I also needed to detect if that controller became unplugged so that I wouldn’t attempt to show a dialog box the player was unable to close.

I ended up spending a while changing my input framework so that it would automatically detect disconnected controllers, and inform the game code when a controller had been reconnected. I also did some work to automatically track the active controller, while still handling keyboard input correctly on the PC.

Below, you can see a short annotated video walkthrough where I demonstrate the technique and show how it integrates with XACT.

There are a few key pieces necessary for this to work.

First, I need a way to get updated audio into the game. It turns out this is pretty simple – if you change the settings in your XACT project, you can get it to build output files into a folder of your choice. At that point, all you need to do is change your game’s XACT code to be able to load from that location.

Second, I need a way to pull information out of the XACT datafiles that I can use to attach cues to events. Since the XACT API provided by the XNA Framework is basically useless for this purpose, I ended up solving this problem by loading up the raw datafiles and pulling the names of my cues out of the datafiles. Yes, it’s disgusting. But it works! Luckily, the cue names are right at the end of the data files, and they’re null-terminated, so it’s not difficult to read them. It’s beyond my understanding why the framework developers opted not to provide the information.

Third, I needed a way to broadcast events from objects in my game world. The solution I ended up building for this was essentially an improved version of the event framework that I previously used for handling input events, like button presses. The framework allows me to ‘subscribe’ to various types of events, either for a specific object, or for all objects that can broadcast that event. The ability to subscribe to all objects inexpensively gives me a straightforward way to say things like ‘whenever any creature gets hit by a rocket, play an explosion sound’, which is important.

Fourth, I needed a way to expose event information in an understandable manner, so that it would be easy to figure out what events are occurring in-game and how to attach sounds to them. I solved this by creating a simple ‘event overlay’ that shows a list of the most recently fired events, and highlights objects when they broadcast events. This allows you to simply play the game with the overlay open and look for things that are missing sound effects – once you find something, just look at the log to find out the name of the event.

If you’re interested, you can check out the source code and automated tests for the event system here, on Google Code. In the future I will be releasing the rest of my audio framework as open-source for people to use. Please don’t hesitate to leave a comment if you have any questions; I’d be glad to help explain more about how this technique works.

There are various approaches for building dynamic music – some games go so far as to create hundreds of short music ‘snippets’ and string them together to create longer, more dynamic songs that never sound the same to the player once. Unfortunately, this is pretty complicated to do, especially if you’re just working with XNA and XACT. Luckily, there are some simpler techniques you can use to build dynamic music.

Below, you can see a short video clip showing one of my experiments with dynamic music. I’ll explain how it works in this post, so you can apply the technique to your games. In this video clip, I have two music tracks playing, and control the volume of one of them depending on whether or not the player character is within the blue rectangle. You can hear the track fading in and out as he moves.

The approach I’m using works like this: You take a song that you intend to use in your game, and in an audio tool, split it out into multiple wave files, one for each ‘track’ that you want to have control over. Depending on the complexity of your song, you might just want to split it out into a pair of tracks, and fade one of them in when you want the music to get more intense. If your music is more sophisticated and your gameplay has lots of variation, you may want lots of tracks that you can control individually based on what’s happening – fade in some anxious-sounding strings when powerful monsters are on screen, and temporarily fade in some ominous-sounding bass notes when the player is injured, for example.

In this article I’m going to be using two simple tracks I exported from a song using ModPlug tracker. This is about as simple as you can get, since I just wanted to grab a song I had lying around that I knew I could use without violating any copyright laws. To create the tracks, I went into MPT and loaded up the song. Then, I went into the pattern editor and muted part of the channels, and exported the song to a WAV. After that, I unmuted those channels and muted the remaining channels, and exported them to a second WAV file. This gives me two WAV files of equal length, each of which composes a portion of the song.

Now, to actually wire it up, you have to go into XACT and load up your audio project. You’re going to want to find the wave bank you keep your music in, and open it up. Once it’s open, select the tracks for your song and drag-drop them into the wave bank. Afterwards, you should have one entry in the wave bank for each track, as you see below.

Next, open up the sound bank that contains your music cues. This probably has the same name as your wave bank for music, but if it doesn’t, no big deal.

Now, drag one of your tracks out of your music wave bank, and drop it into the bottom portion of your sound bank, where the cues are listed. This will create a cue and associated sound for that track.

The cue and sound are automatically named after the track, which probably isn’t ideal, so you can rename both of them to something easier to remember – this will make it easier to work with them in your game code. After you’ve done that, select the sound for your music up in the top section of the sound bank. You should see your track on the right side of the window, listed as ‘Track 1′.

Next, you want to drag your remaining tracks out of your wave bank, and drop them directly onto the empty space below your track, in the top right portion of the sound bank window. This will create additional tracks for them, as a part of the sound.

You’re all done here, so go ahead and close your wave and sound banks. Next, you need to create a variable to control the volume of your tracks. Go to the treeview on the left side of the XACT window, and right click the ‘Global’ section under ‘Variables’. Select ‘New Global Variable’.

In the window that opens, choose a name for your variable – I chose ‘MusicTrackVolume’ – and then change its ‘Control’ to ‘Monitored’. Go ahead and close the variable settings window after this.

Next, right click the ‘RPC Presets’ section in the left side of the window, and select ‘New RPC Preset’.

A rather intimidating window will open up. The first few things you want to do in this window are:

• Select your variable in the ‘Variable’ dropdown at the top.
• Then, in the same row, change the ‘Object’ dropdown to point at the track for which you wish to control volume.
• Finally, change the ‘Parameter’ dropdown to ‘Volume’.

Once this is done, you need to set up the volume ramp, so that XACT knows how to adjust the volume of your track based on the value of the variable. To keep things simple, go ahead and set two points for the ramp:

• MusicTrackVolume = 0.00, Volume = -96.00 (dB)
• MusicTrackVolume = 1.00, Volume = 0.00 (dB)

This specifies that when your variable is set to 0.0, the volume will be set to -96.0 dB, basically silent, and when it is set to 1.0, the volume will be set to 0 dB – full volume.

Once this is done, you can close the RPC Preset window, and rename your new preset to something easier to identify, like ‘Music Volume Preset’. After that, open your sound bank back up. Drag your RPC preset out of the left side of the XACT window, and drop it directly onto the entry for your music in the top left portion of the sound bank window (the sounds portion, not the cues portion).

After you do this, your sound should be highlighted, and the bottom left portion of the XACT window (the properties viewer) should show your preset under ‘Attached Objects’. We’re done in XACT now, so you can save everything and close it if you like.

Once you have everything set up in XACT, you can use your cue as you normally would in-game. By default, you will only hear one of your tracks, because your variable’s value defaults to zero.

To make it so the player can hear the track, all you have to do is provide a value for your variable. You do this by using the SetGlobalVariable method of the XACT AudioEngine class, like so:

AudioEngine.SetGlobalVariable("MusicIntensity", 0.8f);

Given this, it’s straightforward to set up your game code so that XACT variables change in response to in-game events. Note that variables change immediately after you set them, so your volume changes will be abrupt and somewhat disconcerting. The best way to solve this is to interpolate your variable changes, something like this:

float fadeElapsedTime = (gameTime.TotalGameTime.TotalSeconds - FadeStartedWhen);
float musicIntensity = MathHelper.Clamp(fadeElapsedTime / FadeDuration, 0.0f, 1.0f);
AudioEngine.SetGlobalVariable("MusicIntensity", musicIntensity);

Doing that every frame will give you smooth transitions between values, so that the player hears tracks fade in and out instead of immediately stopping and starting.

It’s also important to note that since the relationship between volume and decibels (dB) is logarithmic, your tracks will sound like they are fading in very quickly. The best way to solve this is by creating a more advanced curve for your RPC Preset, so that the fading sounds smoother. Here’s the one I used in my example video clip above:

As you can see, I partially counteract the logarithmic nature of the dB scale by making the volume ramp up rapidly from -96dB to -32dB in the first quarter of the scale, and then ramp up more slowly from there to 0dB. For your needs, a more complex curve might be appropriate.

I hope this post has given you some ideas about how to integrate dynamic music into your own XNA games. Please don’t hesitate to comment if you have any questions!