Hello everyone!
We’re proud to present our first iteration of Wwise audio for Star Citizen. Moving over to Wwise sets us up well to support the expansive scope and scale of our game.

We’ve spent some months first migrating our content from our previous middleware solution, then refactoring and reengineering how audio is implemented within CryEngine. We’ve mentioned in previous updates what features it lists, but I’ll go over some of the key points here as to what it brings us. (Warning, the list it isn’t all exclusively glamorous features, and there may be use of terms such as ‘pipeline’, ‘workflow’ and ‘iteration’ coming!)

Reduced dependency between sound designers and audio programmers is probably our first big win. We still need audio programming resources to integrate our sound in the game, for sure. But there’s a lot you can do within Wwise that previously we’d have to define in relatively hard-to-get-to code.

Within Wwise we can:

Author sound structures, and re-sequence and re-layer sounds to give infinite variability.

Then use simulation tools to prototype how they’ll behave in a game context.

Integrate those sounds into game-friendly bank structures, set them to stream from disc/disk or stay resident in main RAM etc.

Set up the event hooks that get converted to CryEngine triggers and parameters.

Once implemented, we can then connect to and profile the game itself, and monitor how the game audio is behaving, check for bugs or resource spikes. And mix, change properties of the sounds, all in real time.

That all seems a little dry perhaps, but the more we have this basic pipeline in place and solid, the more time we have to do the something more exciting; like making awesome sounds in the first place, iterating on them, and putting more effort and consideration into how the whole soundscape comes together.

For a game of the scale of Star Citizen, especially as we move into having the Large World online, this is particularly important. Our base tech is the foundation for everything else we do and we can’t begin to look at the funkier features until we’re 100% happy with this integration.

A lot of this though is standard Wwise goodness. With a toolset like this, as well as migrating our previous audio, we’ve already been prepping hosts of new sounds for modules such as FPS, for the PU, all within Wwise already. Many of these will in turn feed into Squadron 42 as well as the larger universe.

With an ongoing release cycle, we need to be able to have confidence in our mix as we progress. To this end, Stefan set up what’s called a Soundcaster session – essentially a pallet of events that one can trigger – that acts as a reference point for setting relative loudness for all types of sounds in the game.

From here we can determine just how loud guns should be, and just how quiet, say, ambience could be in relation to them. Having this to refer to seems trivial, but simply having this to hand, having a ‘whole project’ perspective at any one time, outside of running the game itself, makes it much more possible to ensure we’re working to similar loudness standards; one fewer thing to worry about and another step towards a higher quality experience.

Here are some words from other members of the team on what the Wwise move brings and some samples of Wwise in action!

Graham Phillipson, Audio Programmer
From a code perspective Wwise allows us to trigger events that are more powerful than just “play sound” and “stop sound”. This means that in many cases we can add simple audio hooks into the game and the sound designers can use them to trigger complex audio events that play/stop sounds, affect mix changes and change switch and parameter states. It’s also been really good for profiling and debugging; when we connect to the game we can see graphs of instance counts, CPU usage, stream counts and bandwidth and memory usage, and mix trees. Solo and mute functions are also useful debugging tools. The 3d object viewer gives us a good illustration of what sounds are playing in the game world without all those pesky game graphics getting in the way.

Luke Hatton, Senior Sound Designer
Having joined the team last July when we were using our previous audio middleware solution through to this release, it’s great to finally be settled in Wwise with our audio content migrated over. Just recently, hearing Betty again in the cockpit and ship enter/exit mechanical parts working again in the new sound engine has been very rewarding. For us, working internally, the start of the Wwise conversion process meant that many months ago we started again with no sound at all in our internal build, and it has slowly been sonically restored. How great it is to be at this new starting point where I’m certain the sound will go in that much slicker than ever before!

The major win for me personally is that we now have a clean, tidy and easy to maintain tool for all of our sound assets and all of our real-time processes. What I mean is, any sound can be renamed, re-bussed, categorised in a different way and this will not affect the in-game hook we have. It means we can try structuring our data one way, change our minds for whatever reason and it won’t cause a lot of re-working. Because of this, we’re now producing audio content in a much more systemic way than before; we are creating robust systems that cater for general scenarios, rather than crafting specific one-off sounds which are dependent on specific animations/scripting.

The Wwise release is also representative of a larger and more streamlined audio team in comparison to a year ago. With so many sound designers and assets being added on a daily basis, our new naming conventions and workflows allow for an easier time making decisions, which can filter through on a game-wide level. If something is put into our Wwise project which doesn’t make sense, or isn’t clear, it’s a matter of having a quick group chat and changing it. In this way, it’s easier for work to be peer-reviewed now so we can sanity check each other’s content or audition new sounds very easily.

(All this recapping reminds me, I really need to change our thruster ‘RPM’ parameter to just ‘Thrust’. We currently use a parameter named ‘RPM’ in Wwise (the same name as it was in FMOD) to drive thruster sounds, so it needs changing to something that makes more sense. Our thrusters don’t actually ‘revolve per minute’. Now easily done!)

Matteo Cerquone, Junior Sound Designer
I was lucky enough to join the CIG Audio team after the transition from FMOD to Wwise, I skipped the first part of the process of converting assets to the new audio engine and that gave me more freedom in terms of audio implementation.

Working with Wwise is a great experience as it allows us to manipulate, re-shape and mix audio in real time according to what is happening in game.

I found myself working on the sound design for the missiles, and implementing those assets in game using Wwise allowed me to add variations depending on the distance and speed: each missile, once launched, has three different loops that describes how far this object is from the listener perspective, the first loop is composed of a rocket layer and different characteristics sounds that describe the brand and type of missile (in most cases this would be a specific beeping sound), the second loop is a more distant perspective of the rocket itself and the third loop is a far off, distant perspective rocket sound.

With Wwise we can blend between these three layers and add real time parameters such as volume or Doppler effects according to how far the object is from the player. When being chased by a missile you can now definitely hear how distant it is (blend between different loops, volume, low pass filter etc..) and how fast is approaching you (thanks to the Doppler effect), also if a missile is close enough you can recognize the brand and type of missile before getting hit (or escape if you are lucky).

Similar approach was used for the explosions of such missiles, we have created different explosion sounds according to the brand and type of missile, if the missile has hit or miss and if it’s happened far away from the player or close. Again Wwise gives us the tools for not just triggering the correct sound but to blend them together and create variations (if you are close enough you will also be able to hear the debris sound of the ship being hit).

Another great help is the possibility to have a cleaner mix, when working with the primary thrusters for some of the ships I wanted to duck down the sound of the main engine whenever the overdrive was engaged, with Wwise I could use a meter that controls the volume of the main engine according to how loud the overdrive is (side-chaining), so now every time the overdrive is engaged, the primary engine sound will automatically duck down.

Darren Lambourne, Senior Sound Designer
Wwise is a very freeing and creative tool. Being able to move quickly from a concept, a high level idea, to something functional in the game engine is so crucial to bottling that initial inspiration.

The diagnostics are second to none, letting us get to the heart of a problem quickly and solve it rather than just applying a patch to mask the issue. That’s important on a project of this size, there are already a bewildering number of audio systems in our game universe and that number is growing every day. We’re trying to create something truly special for the audio in Star Citizen. Getting eyes on the project as a whole and drilling down into problem areas that can impact both the fidelity and the smoothness of our audio systems is absolutely essential to ensure that we keep out the bad stuff and emphasise the good stuff.

Jason Cobb, Senior Sound Designer:
From my perspective the conversion of audio middleware from Fmod to Wwise has been a year’s long process that began with early naive aspirations for a quick change-over and only concluded after a drawn-out haul of many incremental yet monumental changes.

From an audio content standpoint, the earlier and faster we converted over, the least amount of Fmod content and implementation would be have to be re-done. Seems like a no-brainer but unfortunately the situation would not allow for such a fast change-over with everyone focusing on each next release or demo version that year.

In May 2014 we examined an integration of Wwise in CryEngine which had been done by an outside company. This was at a time before Crytek had released an official Wwise integration and we did not yet have any details about it or an eta when it would be available which was compounded by the uncertainty of their financial situation at the time. For a short while it looked like we had a path to a fast, straight-forward Wwise integration and minimal data changeover job.

One factor at that time was not enough engineers available to dedicate one or more to integrate Wwise using the example we had been provided, yet alone our own take on it. Even still if we had used a third-party or in-house Wwise integration, it would have made future CryEngine SDK integrations that much harder to do.

By choosing the yet-to-be-delivered Crytek Wwise integration we minimized the amount of divergence between the Star Citizen game engine and the base SDK CryEngine. Still from an audio standpoint this guaranteed a lot more audio content would be created and implemented with Fmod, which made the task of converting this Fmod audio content and implementation into a much larger and more difficult job.

It was not until the end of September 2014 until we kicked off an integration of CryEngine that included a Wwise integration. Instead of directly replacing Fmod calls with Wwise calls in their game code like the other example integration we looked at, their version instead converted game audio calls to the newly conceived Audio Translation Layer, as an abstraction to allow for different audio middleware to be swapped out underneath – a great feature if you are selling a game engine that needs lots of options for a variety of customers but maybe a little more than we needed on Star Citizen at the time. Still, always good to have future options and we have since made greater use of this audio translation/abstraction layer to store event metadata.

Unfortunately by the existence of this abstraction layer and its associated data files, it created a new step in the audio content workflow which required the sound designers to take the work they had just made in Wwise designer tool and manually create new objects referencing these same events, parameters, switches, states and sound-banks, saved into ATL files and managed in the audio controls browser. The early days of this workflow were somewhat primitive and slow and very much unlike the smooth experience of using Wwise in any other game engine I have shipped before. For this reason I decided to script a workflow solution that would simply automatically create the necessary ATL files for us when we build sound-banks in the Wwise designer tool. Then the sound designers will have no extra steps to manually create and manage these ATL files in CryEngine other than making sure they are checked in when updated. We can just immediately use our sounds in the game engine as soon as we build them into a sound-bank.

Meanwhile the audio team was still working in Fmod for the series of game releases and demos, with lots of new and exciting game content and sounds going in over the rest of that year. The Wwise integration branch kept making progress but the challenges of completing all the code side work in conjunction with dependencies from other development integrations and game releases meant that it was a few months before the window appeared where Wwise could be safely made “live” in the main game development stream.

Along the line dedicated audio engineers and additional sound designers were brought on board and the task of converting the audio content and implementation was able to begin in earnest. Across all the game files we data-mined for Fmod event strings and setup a conversion table to enter the new Wwise event / ATL trigger strings, which were then converted by scripting automation of search and replace across batches of hundreds of data files at a time.

To cut a long story short, by the time we wrapped up all the audio code and data implementation conversions, to date we have touched untold thousands of game data files and created close to 10000 new Wwise events and well over 1000 sound banks. It feels so good to finally be done with this task and now get on to the actual fun parts of making new content once again, not to mention now having the tools needed to better refine, modulate, mix and optimize, the game sounds with the features provided by Wwise and the ATL.

Ultimately, we’re not finished yet, by quite some way – but we feel we’re in a much better place to keep improving and keep building. While we’re proud of what we’re getting together, we’re not 100% happy by some way, we realize still have a lot of work to do and now we have more of the tools in hand to do it.

As always we’d appreciate your feedback and reports of any issues with the sound of our game. The ‘Ask A Developer’ section of the forums, there’s an audio topic which is where we hang out and respond to sound queries. Thanks for listening!

--- Fri Jul 24 2015 00:00:00 GMT+0200	
+++ Fri Jul 24 2015 00:00:00 GMT+0200	
@@ -10 +10,11 @@
-Author sound structures, and re-sequence and re-layer sounds to give infinite variability. Then use simulation tools to prototype how they’ll behave in a game context. Integrate those sounds into game-friendly bank structures, set them to stream from disc/disk or stay resident in main RAM etc. Set up the event hooks that get converted to CryEngine triggers and parameters. Once implemented, we can then connect to and profile the game itself, and monitor how the game audio is behaving, check for bugs or resource spikes. And mix, change properties of the sounds, all in real time. That all seems a little dry perhaps, but the more we have this basic pipeline in place and solid, the more time we have to do the something more exciting; like making awesome sounds in the first place, iterating on them, and putting more effort and consideration into how the whole soundscape comes together.
+Author sound structures, and re-sequence and re-layer sounds to give infinite variability.
+
+Then use simulation tools to prototype how they’ll behave in a game context.
+
+Integrate those sounds into game-friendly bank structures, set them to stream from disc/disk or stay resident in main RAM etc.
+
+Set up the event hooks that get converted to CryEngine triggers and parameters.
+
+Once implemented, we can then connect to and profile the game itself, and monitor how the game audio is behaving, check for bugs or resource spikes. And mix, change properties of the sounds, all in real time.
+
+That all seems a little dry perhaps, but the more we have this basic pipeline in place and solid, the more time we have to do the something more exciting; like making awesome sounds in the first place, iterating on them, and putting more effort and consideration into how the whole soundscape comes together.

--- Fri Jul 24 2015 00:00:00 GMT+0200	
+++ Fri Jul 24 2015 00:00:00 GMT+0200	
@@ -6 +6 @@
-Reduced dependency between sound designers and audio programmers is probably our first big win. We still need audio programming resources to integrate our sound in the game, for sure. But there’s a lot you can do within Wwise that previously we’d have to define in relatively hard-to-get-to code. 
+Reduced dependency between sound designers and audio programmers is probably our first big win. We still need audio programming resources to integrate our sound in the game, for sure. But there’s a lot you can do within Wwise that previously we’d have to define in relatively hard-to-get-to code.
@@ -10 +10 @@
-Author sound structures, and re-sequence and re-layer sounds to give infinite variability. Then use simulation tools to prototype how they’ll behave in a game context. Integrate those sounds into game-friendly bank structures, set them to stream from disc/disk or stay resident in main RAM etc. Set up the event hooks that get converted to CryEngine triggers and parameters. Once implemented, we can then connect to and profile the game itself, and monitor how the game audio is behaving, check for bugs or resource spikes. And mix, change properties of the sounds, all in real time. That all seems a little dry perhaps, but the more we have this basic pipeline in place and solid, the more time we have to do the something more exciting; like making awesome sounds in the first place, iterating on them, and putting more effort and consideration into how the whole soundscape comes together. 
+Author sound structures, and re-sequence and re-layer sounds to give infinite variability. Then use simulation tools to prototype how they’ll behave in a game context. Integrate those sounds into game-friendly bank structures, set them to stream from disc/disk or stay resident in main RAM etc. Set up the event hooks that get converted to CryEngine triggers and parameters. Once implemented, we can then connect to and profile the game itself, and monitor how the game audio is behaving, check for bugs or resource spikes. And mix, change properties of the sounds, all in real time. That all seems a little dry perhaps, but the more we have this basic pipeline in place and solid, the more time we have to do the something more exciting; like making awesome sounds in the first place, iterating on them, and putting more effort and consideration into how the whole soundscape comes together.
@@ -14 +14 @@
-A lot of this though is standard Wwise goodness. With a toolset like this, as well as migrating our previous audio, we’ve already been prepping hosts of new sounds for modules such as FPS, for the PU, all within Wwise already. Many of these will in turn feed into Squadron 42 as well as the larger universe. 
+A lot of this though is standard Wwise goodness. With a toolset like this, as well as migrating our previous audio, we’ve already been prepping hosts of new sounds for modules such as FPS, for the PU, all within Wwise already. Many of these will in turn feed into Squadron 42 as well as the larger universe.
@@ -18 +18 @@
-From here we can determine just how loud guns should be, and just how quiet, say, ambience could be in relation to them. Having this to refer to seems trivial, but simply having this to hand, having a ‘whole project’ perspective at any one time, outside of running the game itself, makes it much more possible to ensure we’re working to similar loudness standards; one fewer thing to worry about and another step towards a higher quality experience. 
+From here we can determine just how loud guns should be, and just how quiet, say, ambience could be in relation to them. Having this to refer to seems trivial, but simply having this to hand, having a ‘whole project’ perspective at any one time, outside of running the game itself, makes it much more possible to ensure we’re working to similar loudness standards; one fewer thing to worry about and another step towards a higher quality experience.
@@ -57 +57 @@
-In May 2014 we examined an integration of Wwise in CryEngine which had been done by an outside company. This was at a time before Crytek had released an official Wwise integration and we did not yet have any details about it or an eta when it would be available which was compounded by the uncertainty of their financial situation at the time. For a short while it looked like we had a path to a fast, straight-forward Wwise integration and minimal data changeover job. 
+In May 2014 we examined an integration of Wwise in CryEngine which had been done by an outside company. This was at a time before Crytek had released an official Wwise integration and we did not yet have any details about it or an eta when it would be available which was compounded by the uncertainty of their financial situation at the time. For a short while it looked like we had a path to a fast, straight-forward Wwise integration and minimal data changeover job.
@@ -73 +73 @@
-Ultimately, we’re not finished yet, by quite some way – but we feel we’re in a much better place to keep improving and keep building. While we’re proud of what we’re getting together, we’re not 100% happy by some way, we realize still have a lot of work to do and now we have more of the tools in hand to do it. 
+Ultimately, we’re not finished yet, by quite some way – but we feel we’re in a much better place to keep improving and keep building. While we’re proud of what we’re getting together, we’re not 100% happy by some way, we realize still have a lot of work to do and now we have more of the tools in hand to do it.