Wwise Mms and the incredible System Shock music pack

For my next project after the Blood Music Pack for XCOM 2, I wanted to create a music pack based on the original System Shock. The Blood music pack really pushed the Unreal Engine 3 (UE3) sound cue editor beyond its capabilities, and System Shock was going to demand a lot more than either it or the original Music Modding System (MMS) could provide. In order to do what I wanted, I concluded I would need to fork MMS and create a new system that used the Wwise middleware instead of the UE3 sound cue editor.

The problem

The original System Shock had one of the first, if not the first, interactive music systems. A single music track was actually a sequence of multi-layered MIDI music segments which could be enabled or disabled depending on the situation the player was in. If the player was under more threat, heavier parts of the music would be layered in. In some cases, special themes would play when specific enemies were nearby.

I wanted to recreate this idea in XCOM 2, something that was way beyond the capabilities of existing tools. Neither MMS nor the UE3 sound cue system had any capability to modify a track while it was playing. Even if they did, the lack of accurate timing in the sound cue system meant that layering tracks correctly would be impossible. This is part of the reason that the XCOM 2 developers use WWise instead the sound cue system.

Thus, I began working on the Wwise Mms system simultaneously with the System Shock Music Pack.

Key goals and challenges

Adding Wwise soundbanks to XCOM 2

No XCOM 2 modder had yet figured out how to add new sounds with Wwise. New methods had to be devised for adding these sounds.

Backwards compatibility

There are nearly 200 music packs for MMS. The new system had to be able to play those packs as well as music packs that used Wwise.

Inheriting and overriding classes

In order to achieve backwards compatibility, I chose to both require MMS to be installed AND override its classes. Experienced modders believed this to be impossible.

Flexibility and documentation

The system needed to be flexible enough that mod makers could do more or less anything they could think of. It also needed thorough documentation so that they would be able to access that flexibility.

Working from a legacy, minimally documented codebase

The main source of "documentation" when modding XCOM 2 is the portion of the source that is written in UnrealScript. This often makes calls into undocumented C++ code that is not provided. Wwise Mms would also need to maintain compatibility with MMS, which itself has minimal internal documentation.

Limited debugging facilities

In essence, the only form of debugging available to modders at the time was printing to the logs.

The result

The following video demonstrates the end product. The key features shown are the way the same track morphs during different phases of the game, and the seamless transitions between each phase.

I also fully documented Wwise Mms so that other modders could create their own music packs (which a few people have done).

You can find Wwise Mms here and the System Shock music pack here.

Post mortem

Wwise Mms is an incredibly powerful system, and it was perfectly suited for what I needed it to do. However, while a few people have made their own Wwise Mms packs, uptake hasn’t been nearly as good as it was for the original MMS. I think there are three main reasons for this, two of which are beyond my control and one of which would likely require a breaking redesign.

Beyond my control

The biggest problem for Wwise Mms is that (unlike every other XCOM 2 mod) it requires the user to perform a manual installation step. Users are accustomed to mod installation being as simple as clicking the Subscribe button in Steam workshop.

Despite many hours and discussions with other modders, we have been unable to find a way to load Wwise soundbanks from anywhere other than one specific folder. Unfortunately this is not the folder where Steam installs mods, which means the user has to move or link the files to the correct location. I believe this small amount of friction is the biggest factor limiting uptake.

A more minor issue is that at least one user has reported very slow loading performance off a hard drive (not something I ever experienced). Since I’ve already shrunk the files as much as possible, I’m not aware of anything I can do about this.

What I wish I’d done better

I tried to keep the interface for modders as simple as possible, while still being powerful enough to do everything I needed. While I did introduce an "E-Z mode" to support a modder later on, and I think that is what most modders should use, I now feel that I split the difference incorrectly.

In retrospect, a system wherein there was a very simple interface for doing simple things and an advanced mode for complex things would have been better. In particular, I chose a system that didn’t require or allow modders to add any custom code to their mod. In retrospect, certain things would have been easier if the user could easily add programmatic behaviour to compensate for things they could not do directly in Wwise.