Star Citizen Audio Update

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!

Hallo zusammen!
Wir sind stolz darauf, unsere erste Iteration von Wwise Audio für Star Citizen präsentieren zu können. Wenn wir zu Wwise übergehen, sind wir gut aufgestellt, um den großen Umfang und die Größe unseres Spiels zu unterstützen.

Wir haben einige Monate damit verbracht, zuerst unsere Inhalte von unserer vorherigen Middleware-Lösung zu migrieren, dann das Refactoring durchzuführen und die Implementierung von Audio in der CryEngine zu überarbeiten. Wir haben in früheren Updates erwähnt, welche Funktionen es auflistet, aber ich werde hier einige der wichtigsten Punkte besprechen, was es uns bringt. (Achtung, die Liste ist nicht ausschließlich glamourös, und es kann die Verwendung von Begriffen wie "Pipeline", "Workflow" und "Iteration" kommen!

Die geringere Abhängigkeit zwischen Sound-Designern und Audioprogrammierern ist wahrscheinlich unser erster großer Gewinn. Wir brauchen immer noch Audioprogrammierressourcen, um unseren Sound in das Spiel zu integrieren, ganz sicher. Aber es gibt viel, was Sie in Wwise tun können, was wir früher in relativ schwer zu bekommendem Code definieren mussten.

Im Inneren von Wwise können wir es:

Erstellen Sie Soundstrukturen, Re-Sequenz- und Re-Layer-Sounds, um unendliche Variabilität zu erreichen. Verwenden Sie dann Simulationswerkzeuge, um einen Prototyp zu erstellen, wie sie sich in einem Spielkontext verhalten werden. Integrieren Sie diese Sounds in spielerfreundliche Bankstrukturen, stellen Sie sie so ein, dass sie von der Disc/Disk streamen oder im Hauptspeicher verbleiben usw. Richten Sie die Eventhooks ein, die in CryEngine Trigger und Parameter umgewandelt werden. Nach der Implementierung können wir uns dann mit dem Spiel selbst verbinden und es profilieren, das Verhalten des Spiels überwachen, nach Fehlern oder Ressourcenspitzen suchen. Und mischen, ändern Sie die Eigenschaften der Sounds, alles in Echtzeit. Das alles erscheint vielleicht etwas trocken, aber je mehr wir diese grundlegende Pipeline an Ort und Stelle und solide haben, desto mehr Zeit haben wir, um etwas Spannenderes zu tun; wie zum Beispiel großartige Sounds zu machen, sie von vornherein zu wiederholen und mehr Mühe und Aufmerksamkeit darauf zu verwenden, wie die ganze Klanglandschaft zusammenkommt.

Für ein Spiel von der Größenordnung von Star Citizen, insbesondere da wir die Große Welt online haben, ist dies besonders wichtig. Unsere Basistechnologie ist die Grundlage für alles andere, was wir tun, und wir können nicht anfangen, uns die funkiereren Features anzusehen, bis wir mit dieser Integration zu 100% zufrieden sind.

Vieles davon ist jedoch eine standardmäßige Wise Güte. Mit einem solchen Toolset haben wir nicht nur unser bisheriges Audio migriert, sondern auch bereits viele neue Sounds für Module wie FPS, für die PU, alle in Wwise vorbereitet. Viele von ihnen werden wiederum in die Staffel 42 sowie in das größere Universum einfließen.

Bei einem laufenden Release-Zyklus müssen wir Vertrauen in unseren Mix haben, wenn wir Fortschritte machen. Zu diesem Zweck richtete Stefan eine sogenannte Soundcaster-Session ein - im Wesentlichen eine Palette von Ereignissen, die man auslösen kann - die als Bezugspunkt für die Einstellung der relativen Lautstärke für alle Arten von Sounds im Spiel dient.

Von hier aus können wir bestimmen, wie laut die Waffen sein sollen und wie ruhig, sagen wir, das Ambiente im Verhältnis zu ihnen sein könnte. Dies zu erwähnen, scheint trivial zu sein, aber einfach dies zur Hand zu haben, eine Perspektive des "ganzen Projekts" zu haben, die zu irgendeinem Zeitpunkt, außerhalb des Betriebs des Spiels selbst, macht es viel einfacher sicherzustellen, dass wir nach ähnlichen Lautheitsstandards arbeiten; eine weniger Sorge und ein weiterer Schritt zu einem qualitativ hochwertigeren Erlebnis.

Hier sind einige Worte von anderen Mitgliedern des Teams darüber, was der Zug der Weisheit bringt und einige Beispiele von Weisheit in Aktion!

Graham Phillipson, Audio-Programmierer
Aus Codeperspektive erlaubt uns Wwise, Ereignisse auszulösen, die mächtiger sind als nur "Play Sound" und "Stop Sound". Das bedeutet, dass wir in vielen Fällen einfache Audio-Hooks in das Spiel integrieren können und die Sound-Designer sie verwenden können, um komplexe Audio-Ereignisse auszulösen, die Sounds abspielen/stoppen, Mixänderungen beeinflussen und Schalt- und Parameterzustände ändern. Es war auch wirklich gut für das Profiling und Debugging; wenn wir uns mit dem Spiel verbinden, können wir Diagramme mit Instanzanzahl, CPU-Auslastung, Streamanzahl, Bandbreiten- und Speicherauslastung und Mischbäumen sehen. Solo und Mute-Funktionen sind ebenfalls nützliche Debugging-Tools. Der 3D-Objekt-Viewer gibt uns eine gute Illustration davon, welche Sounds in der Spielwelt spielen, ohne dass all die lästigen Spielgrafiken im Weg stehen.

Luke Hatton, Senior Sound Designer (Senior Sound Designer)
Nachdem wir im Juli letzten Jahres dem Team beigetreten sind, als wir unsere vorherige Audio-Middleware-Lösung bis zu diesem Release verwendet haben, ist es großartig, endlich in Wise angesiedelt zu sein, da unsere Audioinhalte übernommen wurden. Erst kürzlich war es sehr lohnend, Betty wieder im Cockpit und im Schiff zu hören, wie mechanische Teile in der neuen Sound-Engine wieder arbeiten. Für uns, die wir intern arbeiten, bedeutete der Beginn des Wwise Konvertierungsprozesses, dass wir vor vielen Monaten wieder ohne Sound in unserem internen Aufbau begonnen haben, und er wurde langsam klanglich wiederhergestellt. Wie großartig ist es, an diesem neuen Ausgangspunkt zu sein, an dem ich sicher bin, dass der Sound so viel glatter sein wird als je zuvor!

Der wichtigste Gewinn für mich persönlich ist, dass wir jetzt ein sauberes, ordentliches und einfach zu wartendes Werkzeug für alle unsere Tonanlagen und alle unsere Echtzeitprozesse haben. Was ich meine, ist, dass jeder Sound umbenannt, umgebildet, kategorisiert und auf eine andere Weise kategorisiert werden kann, und das hat keinen Einfluss auf den Haken im Spiel, den wir haben. Es bedeutet, dass wir versuchen können, unsere Daten auf eine Weise zu strukturieren, unsere Meinung aus irgendeinem Grund zu ändern, und es wird nicht viel Nacharbeit verursachen. Aus diesem Grund produzieren wir Audioinhalte jetzt viel systemischer als bisher; wir schaffen robuste Systeme, die allgemeine Szenarien abdecken, anstatt spezifische Einzelsounds zu erstellen, die von bestimmten Animationen/Skripten abhängig sind.

Die Wwise Version ist auch repräsentativ für ein größeres und schlankeres Audio-Team im Vergleich zu vor einem Jahr. Da täglich so viele Sound-Designer und Assets hinzugefügt werden, ermöglichen unsere neuen Namenskonventionen und Workflows eine einfachere Entscheidungsfindung, die sich auf spielweiter Ebene durchsetzen kann. Wenn etwas in unser Wwise Projekt eingefügt wird, das keinen Sinn macht oder nicht klar ist, geht es darum, einen schnellen Gruppenchat zu haben und ihn zu ändern. Auf diese Weise ist es für die Arbeit einfacher, jetzt Peer-Review zu machen, so dass wir uns gegenseitig den Inhalt überprüfen oder neue Sounds sehr einfach anhören können.

(All dieses Umschreiben erinnert mich daran, dass ich wirklich unseren Parameter'RPM' des Thrusters auf'Thrust' ändern muss. Wir verwenden derzeit einen Parameter namens'RPM' im Wwise (der gleiche Name wie in FMOD), um Thruster-Sounds anzusteuern, so dass er auf etwas Sinnvolleres umgestellt werden muss. Unsere Triebwerke drehen sich nicht wirklich pro Minute. Jetzt einfach gemacht!)

Matteo Cerquone, Junior Klangdesigner
Ich hatte das Glück, nach dem Übergang von FMOD zu Wwise dem CIG Audio-Team beizutreten, ich übersprang den ersten Teil des Prozesses der Konvertierung von Assets in die neue Audio-Engine und das gab mir mehr Freiheit bei der Audio-Implementierung.

Die Arbeit mit Wwise ist eine großartige Erfahrung, da sie es uns ermöglicht, Audio in Echtzeit zu manipulieren, umzugestalten und zu mischen, je nachdem, was im Spiel passiert.

Ich arbeitete an dem Sounddesign für die Raketen und die Implementierung dieser Assets im Spiel mit Wwise erlaubte es mir, Variationen in Abhängigkeit von der Entfernung und Geschwindigkeit hinzuzufügen: Jede Rakete, sobald sie gestartet wurde, hat drei verschiedene Schleifen, die beschreiben, wie weit sich dieses Objekt von der Zuhörerperspektive entfernt befindet, die erste Schleife besteht aus einer Raketenschicht und verschiedenen charakteristischen Geräuschen, die die Marke und den Typ der Rakete beschreiben (in den meisten Fällen wäre dies ein spezifischer Piepton), die zweite Schleife ist eine weiter entfernte Perspektive der Rakete selbst und die dritte Schleife ist ein weit entfernter, entfernter perspektivischer Raketenklang.

Mit Wwise können wir zwischen diesen drei Ebenen mischen und Echtzeitparameter wie Lautstärke oder Dopplereffekte hinzufügen, je nachdem, wie weit das Objekt vom Player entfernt ist. Wenn man von einer Rakete gejagt wird, kann man nun definitiv hören, wie weit sie entfernt ist (Mischung aus verschiedenen Schleifen, Volumen, Tiefpassfilter usw.) und wie schnell sie sich einem nähert (dank des Doppler-Effekts), auch wenn eine Rakete nah genug ist, kann man die Marke und den Raketentyp erkennen, bevor man getroffen wird (oder mit etwas Glück entkommen).

Ähnlicher Ansatz wurde für die Explosionen solcher Raketen verwendet, wir haben verschiedene Explosionsgeräusche je nach Marke und Art der Rakete erzeugt, wenn die Rakete getroffen oder verfehlt hat und wenn es weit weg vom Spieler oder in der Nähe passiert ist. Auch hier gibt uns Wwise die Werkzeuge an die Hand, um nicht nur den richtigen Sound auszulösen, sondern ihn auch zu mischen und Variationen zu erzeugen (wenn man nah genug dran ist, kann man auch das Trümmergeräusch des getroffenen Schiffes hören).

Eine weitere große Hilfe ist die Möglichkeit, eine sauberere Mischung zu erhalten, wenn ich mit den Primärtriebwerken für einige der Schiffe arbeite, wollte ich das Geräusch der Hauptmaschine dämpfen, wenn der Overdrive eingeschaltet ist, mit Wwise könnte ich einen Zähler verwenden, der die Lautstärke der Hauptmaschine entsprechend der Lautstärke des Overdrive regelt (Seitenkettenschaltung), so dass jetzt jedes Mal, wenn der Overdrive eingeschaltet wird, der Primärmotorgeräusch automatisch dämpft.

Darren Lambourne, Senior Sound Designer (Senior Sound Designer)
Wise ist ein sehr befreiendes und kreatives Werkzeug. Die Fähigkeit, schnell von einem Konzept, einer Idee auf hohem Niveau zu etwas Funktionalem in der Game Engine überzugehen, ist so entscheidend für die Abfüllung dieser ersten Inspiration.

Die Diagnose ist unübertroffen, so dass wir schnell zum Kern eines Problems kommen und es lösen können, anstatt nur einen Patch anzuwenden, um das Problem zu maskieren. Das ist wichtig bei einem Projekt dieser Größe, es gibt bereits eine verwirrende Anzahl von Audiosystemen in unserem Spieluniversum und diese Zahl wächst täglich. Wir versuchen, etwas ganz Besonderes für das Audio in Star Citizen zu schaffen. Das Projekt als Ganzes im Auge zu behalten und in Problembereiche vorzudringen, die sowohl die Genauigkeit als auch die Glätte unserer Audiosysteme beeinträchtigen können, ist absolut notwendig, um sicherzustellen, dass wir die schlechten Dinge fernhalten und die guten Dinge hervorheben.

Jason Cobb, Senior Sound Designer:
Aus meiner Sicht war die Umstellung der Audiomiddleware von Fmod auf Wwise ein einjähriger Prozess, der mit frühen naiven Bestrebungen nach einer schnellen Umstellung begann und erst nach einer langen Phase vieler inkrementeller, aber monumentaler Änderungen abgeschlossen wurde.

Aus Sicht der Audioinhalte gilt: Je früher und schneller wir konvertiert haben, desto weniger Fmod-Inhalte und Implementierungen müssten neu erstellt werden. Scheint ein Kinderspiel zu sein, aber leider würde die Situation einen so schnellen Wechsel nicht zulassen, da sich jeder auf jedes nächste Release oder jede nächste Demo-Version in diesem Jahr konzentriert.

Im Mai 2014 untersuchten wir eine Integration von Wwise in die CryEngine, die von einem externen Unternehmen durchgeführt wurde. Dies geschah zu einem Zeitpunkt, an dem Crytek eine offizielle Wise-Integration veröffentlicht hatte, und wir hatten noch keine Details darüber oder ein Eta, wann es verfügbar sein würde, was durch die Unsicherheit ihrer finanziellen Situation zu diesem Zeitpunkt noch verstärkt wurde. Für kurze Zeit sah es so aus, als hätten wir einen Weg zu einer schnellen, unkomplizierten Wise-Integration und einer minimalen Datenumstellung.

Ein Faktor zu dieser Zeit war, dass nicht genügend Ingenieure zur Verfügung standen, um einen oder mehrere für die Integration von Wwise nach dem uns zur Verfügung gestellten Beispiel zu widmen, aber allein unsere eigene Sichtweise darauf. Selbst wenn wir eine Wwise Integration von Drittanbietern oder intern verwendet hätten, hätte es zukünftige CryEngine SDK-Integrationen umso schwieriger gemacht.

Durch die Wahl der noch zu liefernden Crytek Wwise Integration haben wir den Grad der Abweichung zwischen der Star Citizen Game Engine und der Basis-SDK CryEngine minimiert. Aus audiotechnischer Sicht war damit gewährleistet, dass viel mehr Audioinhalte mit Fmod erstellt und umgesetzt werden konnten, was die Aufgabe stellte, diese Fmod-Audioinhalte und -Implementierungen in einen viel größeren und schwierigeren Job umzuwandeln.

Erst Ende September 2014 begannen wir mit der Integration von CryEngine, die auch eine Wwise Integration beinhaltete. Anstatt Fmod-Aufrufe direkt durch Wwise-Aufrufe in ihrem Spielcode zu ersetzen, wie die andere Beispielintegration, die wir uns angesehen haben, wandelte ihre Version stattdessen Audioaufrufe in den neu konzipierten Audio Translation Layer um, als Abstraktion, um zu ermöglichen, dass verschiedene Audio-Middleware darunter ausgelagert werden kann - eine großartige Funktion, wenn Sie eine Game Engine verkaufen, die viele Optionen für eine Vielzahl von Kunden benötigt, aber vielleicht ein wenig mehr, als wir damals bei Star Citizen brauchten. Dennoch ist es immer gut, zukünftige Optionen zu haben, und wir haben diese Audio-Übersetzungs-/Abstraktionsebene seitdem verstärkt genutzt, um Ereignismetadaten zu speichern.

Leider hat es durch die Existenz dieser Abstraktionsschicht und der damit verbundenen Datendateien einen neuen Schritt im Audio-Content-Workflow geschaffen, der von den Sound-Designern verlangt, die Arbeit, die sie gerade mit dem Wwise Designer-Tool gemacht hatten, zu übernehmen und manuell neue Objekte mit Bezug auf dieselben Ereignisse, Parameter, Schalter, Zustände und Soundbänke zu erstellen, die in ATL-Dateien gespeichert und im Browser der Audiosteuerung verwaltet wurden. Die ersten Tage dieses Workflows waren etwas primitiv und langsam und sehr unterschiedlich von der reibungslosen Erfahrung, Wwise in jeder anderen Spiele-Engine zu verwenden, die ich zuvor ausgeliefert habe. Aus diesem Grund habe ich mich entschieden, eine Workflow-Lösung zu entwickeln, die einfach automatisch die notwendigen ATL-Dateien für uns erstellt, wenn wir Sound-Banken im Wwise Designer-Tool aufbauen. Dann haben die Sound-Designer keine zusätzlichen Schritte, um diese ATL-Dateien manuell in CryEngine zu erstellen und zu verwalten, außer sicherzustellen, dass sie bei der Aktualisierung eingecheckt werden. Wir können unsere Sounds einfach sofort in der Game Engine verwenden, sobald wir sie in eine Sound-Bank eingebaut haben.

Währenddessen arbeitete das Audio-Team immer noch in Fmod für die Reihe von Spielveröffentlichungen und Demos, mit vielen neuen und aufregenden Spielinhalten und Sounds, die im Laufe des Jahres eingeführt wurden. Der Wwise Integrationszweig machte weiterhin Fortschritte, aber die Herausforderungen, die sich aus der Fertigstellung der gesamten Code-seitigen Arbeit in Verbindung mit Abhängigkeiten von anderen Entwicklungsintegrationen und Spielversionen ergaben, führten dazu, dass es einige Monate dauerte, bis das Fenster erschien, in dem Wwise sicher "live" im Hauptstrom der Spieleentwicklung gemacht werden konnte.

Entlang der Linie wurden engagierte Audio-Ingenieure und zusätzliche Sound-Designer an Bord geholt und die Aufgabe der Konvertierung der Audio-Inhalte und der Implementierung konnte ernsthaft beginnen. Über alle Spieldateien hinweg, die wir für Fmod-Ereignisse abgefragt haben, und richten Sie eine Konvertierungstabelle ein, um die neuen Wwise Event / ATL-Triggerzeichenketten einzugeben, die dann durch Skript-Automatisierung der Suche und des Ersetzens über Stapel von Hunderten von Datendateien hinweg konvertiert wurden.

Um es kurz zu machen, als wir alle Konvertierungen des Audiocodes und der Datenimplementierung abgeschlossen haben, haben wir bis heute unzählige tausend Spieldatendateien berührt und fast 10000 neue Wwise Events und weit über 1000 Soundbänke erstellt. Es fühlt sich so gut an, endlich mit dieser Aufgabe fertig zu werden und nun wieder zu den eigentlichen lustigen Teilen der Erstellung neuer Inhalte zu kommen, ganz zu schweigen von den Werkzeugen, die notwendig sind, um das Spiel mit den Features von Wwise und dem ATL besser zu verfeinern, zu modulieren, zu mischen und zu optimieren.

Letztendlich sind wir noch lange nicht fertig - aber wir fühlen uns an einem viel besseren Ort, um uns weiter zu verbessern und weiter zu bauen. Obwohl wir stolz auf das sind, was wir zusammenbringen, sind wir irgendwie nicht 100% glücklich, aber wir wissen, dass wir noch viel Arbeit vor uns haben und jetzt haben wir mehr von den Werkzeugen zur Hand, um es zu tun.

Wie immer freuen wir uns über Ihr Feedback und Ihre Berichte über Probleme mit dem Sound unseres Spiels. Im Abschnitt'Ask A Developer' des Forums gibt es ein Audiothema, in dem wir herumhängen und auf Soundanfragen antworten. Danke fürs Zuhören!

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!