CIG hat vergangenen Freitag ein sehr ausführliches Audio Update samt einiger interessanter Beispielsounds (Qunatensprung!) veröffentlicht.

Wir haben Euch das gesamte Update übersetzt; viel Spaß beim Lesen (und Hören! ;-))!

---

Star Citizen Audio Update

Hallo zusammen!

Wir sind stolz, Euch unsere erste Iteration des Wwise Audiosystems für Star Citizen präsentieren zu können. Der Umstieg auf Wwise hilft uns, den sich ausdehnenden Umfang unseres Spiels auch unterstützen zu können.

Wir haben einige Monate unserer Zeit darauf verwendet, die bestehenden Inhalte aus unserer vorherigen Middleware Lösung zu migrieren, um dann die Art und Weise zu überarbeiten, wie der Ton innerhalb der CryEngine implementiert ist, um ihn dann neu zu strukturieren. Wir haben bereits in früheren Updates erwähnt, welche Vorteile uns Wwise bringt. Aber ich möchte nochmals über einige der Hauptmerkmale sprechen (ein Wort der Warnung: die Liste besteht nicht nur aus glamourösen Funktionen und ich werde vermutlich viele Begriffe wie „Pipeline“, „Workflow“ oder „Iteration“ verwenden müssen!).

Unser vermutlich erster größerer Erfolg ist die Reduzierung der Abhängigkeiten, die zwischen den Sound Designern auf der einen und den Audio Programmierern auf der anderen Seite herrschten. Natürlich benötigen wir noch immer Audio Programmierer, um unsere Sounds in das Spiel zu implementieren. Aber es gibt eine Menge Dinge, die wir jetzt direkt in Wwise tun können, die im Vorfeld nur über relativ hart zu programmierenden Code definiert werden konnten.

Was können wir also in Wwise selbst tun?

• Klangstrukturen erstellen, sie re-sequenzieren und mehrfach überlagern, um eine nahezu unbegrenzte Varianz zu erhalten.
• Die Simulationstools nutzen, um einen Prototypen zu erstellen und zu prüfen, wie sich diese Sounds im Kontext des Spieles tatsächlich verhalten.
• Diese Sounds können in „Spiele-freundliche“ Banks integriert oder so eingestellt werden, dass sie von der Festplatte/DVD abgespielt oder z.B. in den RAM geladen werden.
• Ereignis-„Haken“ („event hooks“) erstellen, die in Auslöser und Parameter für die CryEngine konvertiert werden.
• Einmal implementiert, können wir diese Haken mit dem Spiel verknüpfen und darin Profile erstellen. Außerdem können wir überwachen, wie sich der Spielesound verhält und Bugs oder Ressourcenspitzen untersuchen. Und das Mischen, also das Verändern der Toneigenschaften, funktioniert jetzt in Echtzeit!

Das alles wirkt vielleicht etwas trocken, aber je passender und solider dieses Grundgerüst steht, desto mehr Zeit haben wir, uns spannenderen Dingen zu widmen: z.B. der Erstellung cooler Soundeffekte, deren Iteration und der umfassenden Überprüfung, wie das gesamte Klangbild zusammenpasst.

Für ein Spiel dieses Ausmaßes, insbesondere in Bezug auf die riesigen Onlinewelten, ist das besonders wichtig. Unsere Grundtechnologie stellt das Fundament für alles andere, das wir tun möchten, dar. Und wir können uns nicht um coolere Funktionen kümmern, solange wir mit der Integration nicht zu 100% zufrieden sind.

Vieles davon sind Standards in Wwise. Mit einem Werkzeugkasten wie diesem und durch die Migration unserer vorherigen Audiodateien bereiten wir bereits alle weiteren Sounddateien für Module wie FPS oder das PU in Wwise vor. Das Meiste können wir sowohl in Squadron 42 als auch im persistenten Universum verwenden.

Mit den kontinuierlichen Releasezyklen müssen wir uns auf unsere Mixes verlassen können, je weiter wir vorankommen. Dazu hat Stefan etwas aufgesetzt, das wir „Soundcaster Session“ nennen – im Wesentlichen ist das eine Palette von Events, die ausgelöst werden können. Dieser „Soundcaster Session“ dient als Referenzpunkt für das Setzen der relativen Lautstärke für alle Typen von Tönen im Spiel.

Damit können wir festlegen, wie laut die Waffen z.B. in Relation zur Lautstärke der Umgebung sein sollen. Darauf hinzuweisen, scheint trivial zu sein, aber eine solche Möglichkeit zur Hand zu haben, zu jeder Zeit Zugriff auf die gesamte Projektperspektive zu haben – und das außerhalb des laufenden Spiels, ermöglicht uns, sicherzustellen, dass wir alle mit den gleichen Lautstärkestandards arbeiten. Und das ist nur eine kleinere Sorge, die wir haben. Allerdings ist es auch ein Schritt zu einer höheren Gesamtqualität.

Im Folgenden äußern sich noch unsere Teammitglieder über die Umstellung auf Wwise, außerdem könnt Ihr Euch einige Klangbeispiele von Wwise anhören!

Graham Phillipson, Audio Programmierer

Aus Codesicht erlaubt uns Wwise, Ereignisse auszulösen, die umfangreicher sind als nur „spiele Sound ab“ und „stoppe Sound“. Das bedeutet, dass wir dem Spiel in vielen Fällen einfach neue Audio „Haken“ hinzufügen können. Diese können die Sounddesigner nutzen, um komplexe Ereignisse auszulösen, die dann Sounds starten/stoppen, Veränderungen am Mix vorzunehmen und Schalter und Parameterzustände zu verändern. Es eignet sich auch wirklich gut für Untersuchungen samt Debugging. Wenn wir uns mit dem Spiel verbinden, können wir Graphen der Instanzenzähler sehen, genauso wie die CPU Auslastung, den Streamzähler, die Bandbreiten und die RAM Auslastung und wir können „Bäume“ mischen. Nur einzelne Klänge anzuhören oder komplett stummzuschalten sind weitere hilfreiche Debugging Tools. Zusätzlich liefert uns der 3D-Objektbetrachter eine gute Übersicht, welche Sounds gerade in der Spielwelt abgespielt werden – und das ohne diese lästige Spielegrafik. 😉

Luke Hatton, Senior Sound Designer

Es ist toll, endlich mit Wwise und den bereits migrierten Audioinhalten arbeiten zu können, nachdem ich bereits letztes Jahr im Juli zum Team gestoßen bin, als wir noch unsere alte Middleware-Lösung genutzt haben. Es war – erst vor wenigen Tagen – sehr belohnend, als ich endlich wieder Betty im Cockpit und die arbeitenden, mechanischen Schiffsteile hören konnte – und dieses Mal in der neuen Soundengine! Für uns intern bedeutete der Start des Wwise Konvertierungsprozesses vor vielen Monaten, dass wir in den internen Builds wieder ohne Sound da stehen. Langsam haben wir aber klangtechnisch alles wieder hergestellt. Und es ist großartig, an diesem neuen Anfang zu stehen und ich bin mir sicher, dass der Sound dadurch so viel besser wird als jemals zuvor!

Der Hauptgewinn für mich persönlich ist aber, dass wir nun ein sauberes, ordentliches und einfach zu verwaltendes Tool für all unsere Sounddateien und all unsere Echtzeitprozesse haben. Damit meine ich, dass jeder Sound umbenannt oder in unterschiedlichen Weisen kategorisiert werden kann und das nicht den dafür gesetzten „Haken“ im Spiel beeinflusst. Das bedeutet auch, dass wir versuchen werden, unsere Dateien einheitlich zu strukturieren. Trotzdem könnten wir unsere Meinung, warum auch immer, ändern, ohne dass das viel Arbeit nach sich ziehen würde. Deswegen produzieren wir Audioinhalte jetzt sehr viel systematischer als zuvor. Wir erstellen stabile Systeme, die auf allgemeinen Szenarien ausgerichtet sind, anstatt einzelne Ein-Aus-Sounds zu bauen, die von einer bestimmten Animation oder einem bestimmten Skript abhängig sind.

Die Umstellung auf Wwise repräsentiert auch das im Vergleich zu letztem Jahr gewachsene und optimierte Audioteam. Bei so vielen Sounddesignern und täglich hinzugefügten Assets ermöglichen uns unsere neue Namenskonvention und unser neuer Arbeitsablauf, einfacher kurzfristige Entscheidungen zu treffen, die dann auf einer Spiele-weiten Ebene durchsickern. Wenn etwas in unserem Wwise Projekt abgelegt wird, das keinen Sinn ergibt oder das nicht verständlich ist, können wir schnell einen Gruppenchat eröffnen und das ändern. Auf diese Weise ist es einfacher, Inhalte gegenseitig zu überprüfen und neue Sounds vorzuspielen.

(Bei dieser Runderneuerung fällt mir ein, dass ich wirklich die „RPM“ Parameter unserer Schubdrüsen auf „nur Schub“ anpassen muss. Wir nutzen derzeit in Wwise einen Parameter namens „RPM“ (den Namen haben wir aus FMOD übernommen), um die Sounds der Schubdrüsen zu verwalten. Da unsere Schubdrüsen nicht wirklich „per Minute rotieren“ (-> RPM), wollen wir das in etwas Sinnvolleres abändern – mit dem neuen System ist das schnell gemacht!)

Matteo Cerquone, Junior Sound Designer

Ich hatte das Glück, mich erst nach dem Umstieg von FMOD auf Wwise dem CIG Audio Team anzuschließen. Ich habe damit den ersten Teil des Konvertierungsprozesses der Assets in die neue Audioengine übersprungen und das gab mir mehr Freiheiten in Bezug auf die Audio-Implementierung.

Es ist eine tolle Erfahrung, mit Wwise zu arbeiten, da es uns erlaubt, den Sound entsprechend der Geschehnisse im Spiel in Echtzeit zu verändern, neu zu formen und zu mischen.

Ich habe am Sounddesign für die Raketen gearbeitet. Die Einbindung dieser Assets in das Spiel mit Hilfe von Wwise hat mir erlaubt, mehrere Variationen abhängig von der Distanz und der Geschwindigkeit der Rakete hinzuzufügen: jede Rakete, die einmal abgefeuert wurde, hat nun drei verschiedene Phasen, die die Entfernung zum Ausgangspunkt des Zuhörers beschreiben. Die erste Phase ist als Raketenlayer mit unterschiedlichen Charakteristika komponiert, die die Marke und den Typ der Rakete beschreiben. In den meisten Fällen ist das ein spezifischer Peep-Ton. bei der zweiten Phase handelt es sich um eine weiter entfernte und bei der dritten Phase um eine sehr weit entfernte Perspektive des Raketenklangs.

Mit Wwise können wir diese drei Layer vermischen und in Echtzeit, abhängig von der Entfernung des Objekts zum Spieler, Parameter wie die Lautstärke oder Dopplereffekte hinzufügen. Wenn man von einer Rakete verfolgt wird, kann man jetzt durchaus hören, wie weit sie entfernt ist (durch die Mischung der verschiedenen Phasen, der Lautstärke, der Tiefenpass-Filter, etc.) und wie schnell sie näher kommt (dank des Dopplereffekts). Wenn die Rakete nah genug ist, könnt Ihr sogar Marke und Typ erkennen, bevor sie Euch trifft (oder Ihr mit etwas Glück entkommt).

Ähnlich sind wir bei den Explosionen solcher Raketen vorgegangen. Wir haben unterschiedliche Explosionsklänge erstellt: entsprechend der Marke und des Typs der Rakete, ob sie getroffen oder verfehlt hat und ob sie weit entfernt oder in der Nähe des Spielers detoniert. Nochmals: Wwise gibt uns Werkzeuge in die Hand, mit denen wir nicht nur bestimmte Sounds auslösen, sondern sie auch vermischen und Variationen davon erstellen können. Solltet Ihr nahe genug dran sein, könnt Ihr sogar den Klang der Trümmer hören, wenn das Schiff getroffen wird.

Eine weitere große Hilfe ist die Möglichkeit, die Abmischung der primären Triebwerke einiger Schiffe sauberer abspielen zu lassen. Ich wollte den Sound der Haupttriebwerke etwas absenken, wann immer der Overdrive aktiviert wird; mit Wwise kann ich ein Messgerät verwenden, das die Lautstärke der Haupttriebwerke kontrolliert und automatisch anpasst, je nachdem wie laut der Overdrive ist.

Darren Lambourne, Senior Sound Designer

Wwise ist ein unabhängiges und kreatives Werkzeug. Die Möglichkeit, schnell von einem Konzept, einer sehr guten Idee, zu etwas Funktionalem in der Spieleengine zu gelangen, ist entscheidend für das Fassen flüchtiger Ideen.

Die Diagnosemöglichkeiten sind unübertroffen. Sie lassen uns schnell zum Kern der Probleme vordringen und sie lösen, anstatt einen Patch anzuwenden, der den Fehler nur maskiert. Bei der Größe dieses Projekts ist das wichtig, denn es gibt bereits eine verwirrende Anzahl von Audiosystemen in unserem Spieleuniversum und diese Zahl wächst täglich an. Wir versuchen, etwas wirklich Besonderes für den Ton in Star Citizen zu erschaffen. Es ist absolut essentiell, das Projekt als Ganzes im Auge zu behalten und die Probleme in kleinere Bereiche herunter zu brechen, die sowohl die Klangtreue als auch die „Smoothness“ unseres Audiosystems betreffen können. Wir stellen dadurch sicher, „schlechtes Zeug“ draußen zu lassen und „gutes Zeug“ zu betonen.

Jason Cobb, Senior Sound Designer

Aus meiner Sicht war die Umrüstung der Audio Middleware FMOD zu Wwise ein „ein-Jahres-Prozess“, der mit einer beinahe naiven Hoffnung auf eine schnelle Umsetzung begann, und der erst nach einer langen Strecke inkrementeller, aber auch monumentaler Veränderungen abgeschlossen worden ist.

Aus Sicht der Audioinhalte müssen wir, je schneller wir die Umstellung abgeschlossen haben, weniger FMOD Inhalte konvertieren, implementieren und neu bauen. Das scheint zwar ein Kinderspiel zu sein, aber leider erlaubte uns die Situation keinen schnellen Umstieg, weil wir uns das gesamte Jahr immer auch auf den nächsten Release oder die nächste Demo vorbereiten mussten.

Im Mai 2014 untersuchten wir eine von einer externen Firma durchgeführte Integration Wwise’ in die CryEngine. Das war noch die Zeit, bevor Crytek eine offizielle Wwise Integration angekündigt hatte und wir hatten auch so keine Details darüber oder gar ein geschätztes Veröffentlichungsdatum. Das hing sicherlich auch mit der Unsicherheit bzgl. ihrer finanziellen Situation zu dieser Zeit zusammen. Für eine kurze Zeit sah es danach aus, als würde es ein schneller und unkomplizierter Integrationsweg für Wwise mit einer minimalen Datenumstellung.

Außerdem hatten wir zu dieser Zeit mit einem Mangel an verfügbaren Technikern zu kämpfen, die sich mehr oder minder ausschließlich um die Integration von Wwise kümmern konnten. Hätten wir eine Third-Party oder in-house Integration durchgeführt, hätte sich eine zukünftige Integration des CryEngine SDKs (Software Development Kit) deutlich schwieriger gestaltet.

Aufgrund unserer Wahl für die noch nicht veröffentlichte Crytek Version der Wwise Integration minimierten wir die Menge der Unterschiede zwischen unserer Star Citizen Spieleengine und dem CryEngine Basis-SDK. Auf der anderen Seite machte die Erstellung und Implementierung weiterer FMOD Audioinhalte die spätere Umstellung auf Wwise deutlich umfangreicher und schwieriger.

Erst Ende September 2014 haben wir die neue Version des SDK (Software Development Kit) der CryEngine erhalten, die auch die gewünschte Wwise Integration enthielt. Anstatt die FMOD-Calls im Spielecode mit Wwise-Calls zu ersetzen, so wie es bei den von uns angesehenen anderen Beispiel-Integrationen der Fall war, konvertierte ihre Version die Gameaudio-Calls in einen neu konzeptionierten Audio-Translation-Layer. Ein großartiges Feature, wenn man die Spieleengine verkaufen möchte, da sie dann viele Optionen für eine Vielzahl von Kunden benötigt. Aber für uns war es zu dieser Zeit vielleicht ein bisschen zuviel des Guten. Trotzdem ist es natürlich praktisch, zukünftig weitere Optionen zu haben. Wir haben seitdem auch bereits Nutzen aus diesen Translation/Abstraction Layern gezogen, um dort die Ereignis-Metadaten zu speichern.

Leider macht diese Existenz des Abstraction-Layers und den dazugehörigen Dateien auch ein neuer Schritt im Arbeitsablauf der Audioerstellung nötig. Dadurch müssen die Sounddesigner ihre Arbeit, die sie gerade im Wwise Designertool erstellt haben, nehmen und manuell neue Objekte erstellen, die sich auf die gleichen Ereignisse, Parameter, Switches, States und Soundbanks beziehen. Dann müssen sie sie in ATL Dateien speichern und im Audio-Kontrollbrowser verwalten. Unsere ersten Schritte mit diesem Arbeitsablauf waren mehr als primitiv. Sie waren außerdem langsam und ganz anders, als meine bisherigen Erfahrungen bei der Nutzung von Wwise in anderen Spieleengines. Aus diesem Grund habe ich beschlossen, eine Workflow-Lösung auszuarbeiten, die einfach alle notwendigen ATL Dateien automatisch für uns erstellt, wenn wir Soundbanks im Wwise Designertool bauen. Dadurch erspare ich den Sounddesignern zusätzliche Schritte, die für die manuelle Erstellung der ATL Dateien nötig wären. Außerdem können sie diese Dateien in der CryEngine wie gewohnt verwalten. Sie müssen nur darauf achten, Dateien, an denen sie arbeiten, auch einzuchecken. Wir können unsere Sounddateien inzwischen unmittelbar in der Spieleengine verwenden, sobald wir sie in eine Soundbank gepackt haben.

Währenddessen hat das Audioteam noch immer in FMOD für die regelmäßigen Spielereleases und Demos, sowie an vielen der neuen und aufregenden Spieleinhalte sowie Sounds gearbeitet, die den Rest des Jahres kamen. Der Wwise Integrationszweig machte zwar weiter Fortschritte, aber all diese Nebentätigkeiten in Verbindung mit Abhängigkeiten von anderen Entwicklungsintegrationen bedeutete auch, dass Wwise erst in einigen Monaten wirklich „live“ gehen können wird.

Daneben haben wir engagierte Audiotechniker und zusätzliche Sounddesigner an Bord geholt und dann begann die heiße Phase der Implementierung und Konvertierung der Audioinhalte. Wir haben zunächst alle Spieledateien auf FMOD Event Strings überprüfen und eine Umrechnungstabelle erstellen müssen, in die die neuen Wwises Event / ATL Auslöser Strings eingetragen wurden. Die haben wir dann mit Hilfe eines automatischen Skripts konvertieren lassen und in hunderten Dateien haben wir dann auf einmal die Operation „suche und ersetze“ ausgeführt.

Lange Rede, kurzer Sinn: bis wir all den Audiocode und die Datenimplementierung umgesetzt hatten, haben wir ungelogen tausende von Spieledaten angefasst, nahezu 10.000 neue Wwise Events und gut über 1.000 Soundbanks erstellt. Es fühlt sich so gut an, endlich mit dieser Aufgabe fertig zu sein und jetzt zum tatsächlich spaßigen Teil zu kommen: endlich wieder neue Inhalte produzieren. Ganz davon zu schweigen, dass wir jetzt die Werkzeuge haben, um den Spielesound mit den von Wwise und ATL zur Verfügung gestellten Funktionen zu verfeinern, zu regulieren, zu mischen und zu optimieren.

Im Grunde sind wir aber noch immer nicht ganz am Ziel angekommen – aber wir fühlen uns jetzt im Stande, die Dinge weiter zu verbessern und die Dinge weiter aufzubauen. Auch wenn wir natürlich stolz darauf sind, was wir hier schon geschaffen haben, sind wir noch nicht 100% glücklich. Wir haben eingesehen, dass wir noch viel Arbeit vor uns haben. Aber jetzt haben wir zumindest auch die Werkzeuge, um diese zu erledigen.

Wie immer schätzen wir Euer Feedback und jegliche Fehlerberichte zum Thema Audio. In der „Ask a Developer“ Sektion im Forum gibt es einen Thread, in dem wir auf solche Themen antworten. Vielen Dank fürs Lesen!

 

Quelle: RSI