Die Special Effects von Spec Ops: The Line
comment
Feature

Die Special Effects von Spec Ops: The Line

Lead Effects Artist Florian Zender resümiert, wie Yager unter anderem die beeindruckenden Sandstürme von Spec Ops: The Line erstellt hat und welche Anpassungen am Workflow vorgenommen wurden, um schnell komplette Szenen repräsentativ für andere Teammitglieder zusammenbauen zu können.

Making Games

@ Facebook

Making Games

@ Twitter

In unserer Vision eines Dubais voller Sand tragen die Effekte von Spec Ops: The Line einen erheblichen Teil zur glaubhaften Darstellung der Umgebung bei. Vom wehenden und rieselnden Sand über bröckelnden Wolkenkratzen bis hin zu Sandstürmen findet sich so ziemlich alles im Spiel, was man von einer apokalyptischen Version Dubais erwarten könnte. Wie viele Assets werden benötigt? Wie viel kann die Unreal Engine auf einer Xbox oder Playstation 3 auf einmal darstellen? Und wie sehr zahlt es sich aus, alternative Ansätze zu bekannten Problemen auszutesten? All das sind Fragen, die in den letzten Jahren aufgekommen sind und beantwortet werden mussten. Auf einen Teil dieser Probleme möchte ich hier nun etwas konkreter eingehen.

Eine typische Szene aus Spec Ops: The Line: Häufig werden kleine Set Pieces wie ein Haufen brennender Reifen als Blickfang verwendet. Diese können bei guter Organisation trotz ihres häufigen Vorkommens leicht verwaltet und angepasst werden.

Die Sandstürme
Einer der großen Bestandteile aus Sicht des Effektteams sind wenig überraschend die massiven Sandstürme, die Dubai vor und während des Spiels übel zurichten. Diese sieht der Spieler in der Regel schon von weitem auf sich zurollen und findet sich dann wenig später mitten im Sturm wieder. Dies erfordert ein dynamisches Überblenden der normalen Szene zum Sandsturm und zurück, komplett mit Änderung der Beleuchtung, zunehmend wehendem Sand und einer sich stark ändernden Darstellung von Farben und Silhouetten.
Während der Pre Production wurden unterschiedliche Ansätze für die Stürme getestet. Durch gesammelte Referenzen zeigte sich schnell, dass Sandstürme in vielen Variationen erscheinen – von dunkel und einfarbig bis hin zu sehr starken Farbverschiebungen, wie es im Sandsturm von Sydney im Jahr 2009 zu sehen war. Letztere haben wir dann als Referenz für unsere Sandstürme gewählt – die Welt wird in ein orangenes Licht gehüllt, Objekte in der Distanz werden schnell zu nahezu einfarbigen Silhouetten und Lichtquellen streuen viel stärker. Diese Merkmale wurden dann verstärkt, um ein noch beklemmenderes Gefühl zu vermitteln. Nach einigem Hin und Her hatten wir einen Prototyp, der sowohl surreal wirkte, visuell einen guten Kontrast zu den normalen Spielszenen darstellte und ein verändertes Gameplay im Sturm unterstützte. Die hierfür benötigten Effekte lassen sich grob in zwei Teile zerlegen: Entweder steht der Spieler außerhalb des Sturms und sieht die Sturmwand auf sich zukommen oder er ist schon vom Sturm verschluckt worden.

In den etwas ruhigeren Szenen werden die Effekte oft eingesetzt, um die Atmosphäre zu verstärken.

Die Sturmwand
Die Sturmwand soll glaubhaft Gebäude verschlucken, bedrohlich aussehen und ein gutes Gefühl für die Gefahr geben – gleichzeitig aber auch performance-technisch günstig genug sein, um auch dann nicht zu ruckeln, wenn der Spieler sie bildschirmfüllend direkt vor sich sieht. Unterschiedliche Ansätze wurden getestet, angefangen bei vorgerenderten Fluid Simulations, die auf Polygone projiziert wurden, über Materialen mit Vertex Animation bis hin zu Partikeln. Die Partikel haben sich letzten Endes als gangbarste Methode erwiesen -- sowohl auf der visuellen als auch auf der technischen Seite. Die Dynamik der Partikel und ihre Farbe lassen sich schnell anpassen, somit kann durch schnelleres Prototyping eine größere Zahl von Sturmtypen ausprobiert werden. Von wild tosenden, schnellen Wolken bis hin zu eher sanften, behäbigen Sturmwänden. Sekundäre Effekte im Level bestehen dazu oft ohnehin schon aus Partikeln, wodurch ein leichteres Blenden der von Sturm- und anderen Effekten wie Explosionen möglich wird. Die Performance der Sturmwand skaliert dank des mächtigen Partikeleditors der Unreal Engine und der guten Kontrolle über Größe und Anzahl der Partikel sehr gut. Ein gewisses Maß an Grundperformance ist natürlich für das Darstellen der Sturmwand von Nöten. Sowohl ein Herunterschrauben der Optik zugunsten der Performance als auch ein Aufbauschen der Partikel, um die verfügbare Leistung voll auszunutzen, sind jedoch zu jeder Projektphase relativ leicht, schnell und risikofrei machbar.



Das Sturminnenleben
Für das fließende Überblenden von der normalen Szene zum Sandsturm bot sich schon früh ein Post Processing Shader an. Weil sich diese im Unreal-Materialeditor recht schnell bauen lassen, stand bald ein Prototyp, um aufkommende Probleme besser abschätzen zu können. Die Übergänge von Innenräumen zu Außenarealen, die glaubwürdige Darstellung des wehenden Sandes und vieles mehr waren Herausforderungen, die gelöst werden wollten. Nach langem Ausprobieren und sorgfältigem Einschränken der Rahmenbedingungen war es dank des Supports von Seiten des Programmierteams am Ende möglich, alle identifizierten Features zu implementieren.

Der Sand spielt bei vielen der Effekte zumindest eine unterstützende Rolle. Wird hier die Glasdecke zerschossen, regnet es nicht nur Scherben, auch der darauf liegende Sand fällt herunter und behindert die Sicht.

Wehender Sand im Sturm
Auch die Darstellung der Sandwolken im Sturm konnte zumindest teilweise durch den Post Process übernommen werden. Durch Abfragen der Spielerposition, seiner Blickrichtung und einer Liste von Sturmparametern war es uns möglich, einen Shader zu entwickeln, der die Wolkenanimation um den Spieler herum fließend an seine Perspektive anpasst, um möglichst den ganzen Bildschirm mit fliegendem Sand zu füllen. Auch wenn die Entwicklung dieses Shaders extrem aufwendig war und ein Risiko hinsichtlich der Entwicklungszeit und Machbarkeit darstellte, so stand am Ende dafür eine Lösung, die an alle Erfordernisse angepasst werden konnte. Für solch einen großen Effekt lässt er sich dazu relativ leicht aufsetzen, an den Level anpassen und wird mit festen Kosten dargestellt. Dadurch war schon recht früh im Leveldesign-Prozess bekannt, wie viel Performance mindestens für den Sturm reserviert werden sollte. Die Optik des Sturms wurde dann wie schon bei der Sturmwand je nach Performanceüberschuss mit Partikeln und Ähnlichem erweitert. Durch das »Out of the Box«-Aufsetzen der Sandstürme und erst einem späteren Aufwerten durch zusätzliche Effekte war es uns möglich, schnell einen spielbaren Level mit einer soliden Repräsentation des finalen Sturms zu erstellen, ohne konstant auf Änderungen der Level Designer oder Artists reagieren zu müssen.

Oftmals sind die Effekte bildschirmfüllend, was recht hohe Anforderungen an die Performance stellt. Hier bricht der Spieler grade durch ein Dach voller Sand.

Die Sandlawinen
Ein weiteres Teilgebiet der Effekte stellen die Sandlawinen dar. Weil ein Großteil der Stadt unter Sand begraben liegt, findet der Spieler regelmäßig Scheiben, Betonblockaden oder auch einfach nur Lüftungsschächte, die nach ein wenig Überzeugungsarbeit nachgeben und Gegner unter herausfließendem Sand begraben oder neue Wege freilegen. Diese im Designdokument recht einfach scheinende Mechanik entpuppte sich als einer der problematischeren Punkte in der Implementierung der Effekte. Einige der grundsätzlichen Fragen schienen recht offensichtlich – die Antworten leider nicht ganz so sehr. Der eigentliche visuelle Teil der Lawinen wurde in zwei Teile aufgespalten: ein Mesh, das möglichst glaubwürdig von der Startposition in die Endposition animiert wird sowie Partikel, um das Mesh besser in die Spielwelt zu integrieren und dem Sand die erwartete Staubigkeit zu verleihen.



Das Lawinen-Mesh
Für die Lawinen war eine In-Game-Simulation in Echtzeit zu aufwendig in der Implementierung, performancetechnisch zu teuer und zu guter Letzt nicht vorhersehbar genug, weil es für den Spielablauf nötig war, bestimmte Gegner unter Lawinen zu begraben. Eine vorberechnete Simulation in 3D Studio Max, projiziert auf einen Bone Rig und als Skelletal Mesh in Unreal importiert, schien daher der sinnvollste Weg. Die Anforderungen an das Mesh sind im Groben die Folgenden:

  • möglichst wenige Vertices und klarer Edgeflow
  • so wenige Bones wie möglich, mit einem Limit von 255 Knochen
  • das UV Mapping muss leicht anpassbar sein, um möglichst leicht fließenden Sand in den In-Game-Shadern zu simulieren.
  • möglichst leichtes Anpassen an sich ändernde Level-Situationen


Automatisierte Simulationen entpuppten sich auch hier als wenig vorhersehbar und selbst kleine Änderungswünsche stellten sich als recht arbeitsaufwendig und somit letzten Endes als hauptsächlich nervenaufreibend für alle Beteiligten heraus. Daher wurde beschlossen, die Meshes »per Hand« mit Hilfe von animierten Modifiern und Space Warps in 3DS Max zu implementieren. Diese Lösung lieferte ansehnliche Ergebnisse und gab uns ein ausgesprochen hohes Maß an Kontrolle sowohl beim ersten Erstellen auch bei späteren Änderungen.

Nicht nur der Sand stellt häufig Probleme für die Performance dar. In dieser Szene findet sich der Spieler gerade auf einem Schlachtfeld voller Rauch wieder.

Das Problem mit der Beleuchtung
Leider stellten sich recht schnell einige Probleme mit diesem Ansatz heraus. Das unterschiedliche Rendering von dynamischen Skelletal Meshes und der statischen Geometrie der Umgebung erzeugte starke Unterschiede in der Beleuchtung. Weil dies ein sehr grundlegendes Problem mit der Engine selbst darstellte, waren die Lösungsansätze recht abenteuerlich – und am Ende durch ihr hohes Risiko nicht tragbar. Das System musste robust genug sein, um sich Änderungen von Licht und Schatten problemlos anzupassen. Bedingt durch das Vorkommen der Lawinen als Übergang von dunklen Innenräumen zur hellen Wüsste draußen schienen die Probleme auch so systematisch, dass eine besser Lösung gefunden werden musste.

Vertexanimierte Meshes
Nach mehreren Tests mit vertexanimierten Materialien kam uns die Idee, dies auch für die Lawinen zu verwenden. Die Grundidee ist folgende: Die Lawine wird als statisches Mesh in ihrer endgültigen »herausgeflossenen« Form gebaut (was dann komplett statische Beleuchtung ermöglicht) und anschließend mit viel Liebe, Schweiß und Scripten in 3D Studio Max zurück hinter die Barriere in ihre Ausgangform animiert. Die Animationsdaten werden dabei in der VertexColor des Meshes gespeichert und im Shader zur Animation verwendet. Die aufkommenden Probleme wie die generell schlechtere Animation können leicht mit mehr Partikeln überdeckt werden. Die Performance hierfür ergibt sich aus der Tatsache, dass die statischen Meshes günstiger zu rendern sind als die Skelletal Meshes.
Dieser Ansatz wird nun für nahezu alle Lawinen im Spiel verwendet. Der vereinfachte Workflow erlaubt es uns, mehr Zeit in die Partikel und zusätzliche Details zu stecken, was das Endergebnis auf ein höheres Niveau bringt als es selbst mit aufwendigen Mesh-Animationen realistisch gewesen wäre. Aus dem Fenster im verschütten Bus kommt nicht nur Sand, sondern auch das ein oder andere Gepäckstück, die Lawine in der Hotellobby fegt bedeutungsschwanger die Modellstadt von Dubai vor der Scheibe weg. Solche Details lenken den Spielern von eventuellen Unzulänglichkeiten ab und geben jeder Lawine einen eigenen Charakter – mehr als man mit Sand, egal wie schön er auch animiert sein mag, erreichen kann.

Die Partikel
Bedingt durch das Setting von Spec Ops: The Line spielen im Level platzierte Effekte natürlich auch eine große Rolle. In einer Stadt voller Sand und Wind erwartet der Spieler auch ein angemessenes Maß an Bewegung -- am liebsten überall und zu jeder Zeit. Dieses Ziel ist natürlich aus mehreren Gründen nur schwer zu erreichen: Performanceprobleme für die offenen Umgebungen des Spiels stellen sich ebenso schnell ein wie eine unüberschaubare Anzahl von Effekt- Assets, um alle Möglichkeiten der Sanddynamik abzufangen.

Die Sandstürme verändern nicht nur die Optik der Szene, sondern haben auch Auswirkungen auf die Umgebung. Im Hotel im Hintergrund bersten schon früh im Sturm alle Scheiben, später bricht ein Teil des Gebäudes in sich zusammen.

Anzahl der Effekte
Weil es durch eine zu große Anzahl verschiedener Assets für alle Beteiligten sehr schnell verwirrend und ausgesprochen frustrierend wird, immer den optimalen Partikeleffekt zu finden, wurde die Anzahl der »generischen« Effekte (alle Effekte die frei im Level platziert werden können) zunehmend reduziert. Was wie ein Nachteil hinsichtlich der visuellen Qualität klingen mag, stellt sich schnell auf breiter Front als großer Vorteil heraus. Durch die geringere Anzahl kann in die einzelnen Assets mehr Zeit investiert werden, wodurch sie sowohl performancetechnisch günstiger als auch visuell ansprechender werden. Effekte für eine spezifische Situation können dank besserer Übersicht leichter ausgewählt werden, was sowohl das Platzieren beschleunigt als auch die visuelle Qualität im Level erhöht. Bugs lassen sich leichter erklären, Performance einfacher verbessern, die Auswirkungen globaler Einstellungen auf die Systeme sind leichter nachzuvollziehen -- die Liste der Vorteile ist lang.
Gegen Ende des Projekts stehen wir nun mit weniger als zwei Dutzend Assets als Kern des partikelbasierten Sands da. Die weiteren großen Effektkategorien Feuer, Rauch und Explosionen liegen zusammengenommen mit ihren Haupteffekten bei einer ähnlichen Anzahl. Dies zeigt sich nun vor allem in den finalen Phasen des Spiels als großer Vorteil -- sowohl performancetechnisch als auch visuell und für den Workflow.

Asset-Struktur
Eine möglichst klare und einfache Aufteilung der Assets in Packages, Gruppen und Namen vermeidet viele Probleme oder hilft zumindest bei deren Vermeidung. Durch eine gut durchdachte Struktur lassen sich leicht die folgenden Ergebnisse erzielen:

  • Man kann einen Effekt leicht finden und sich relativ sicher sein, dass in der Kiste auch wirklich das steckt, was man erwartet.
  • Das unnötige Erstellen von Assets, die man eigentlich schon hat und nur grade nicht findet, wird unterbunden.
  • Eine sinnvolle Aufteilung ermöglicht das leichte und übersichtliche Aufsplitten eines Assets in eine »Standardvariante« sowie in eine billigere und teurere Variation mit gleicher Größe und ähnlicher Dynamik.
  • Eine klare Trennung zwischen generischen (d.h. Effekten, die überall im Spiel verwendet werden) und level-spezifischen Effekten (die nur in genau einer Szene verwendet werden) wird erleichtert. Hierdurch kann man sicher die Risiken und Auswirkung von Bugfixes und visuellen Änderungen abschätzen.
  • Alles in allem gibt es keinen guten Grund, nicht von vornherein eine möglichst klare Struktur für die Hierarchie der Assets und deren Namen festzulegen. Auch wenn dies früh im Projekt unter Umständen schwer erscheint, so ist das spätere Umbenennen und neu organisieren im Falle von schlechten Konventionen dennoch dem Sortieren eines heillosen Chaos vorzuziehen.


Performance-Optimierung
Mit einem regelrechten Rundumschlag lassen sich dank des klaren Aufbaus die Effekte schnell und zuverlässig am Stück optimieren. Eine Checkliste mit den richtigen Einstellungen für jeden Emitter (Partikelanzahl, Materialien, Bounding Box etc.) kann schnell, effizient und vor allem zuverlässig abgearbeitet werden, ohne viel Zeit daran zu verlieren, Effekte aufzuspüren oder Risiken zu evaluieren. Dies ermöglicht es uns noch spät im Entwicklungsprozess, größere Änderungen zu implementieren ohne Angst haben zu müssen, auf eventuell auftretende Probleme nicht angemessen reagieren zu können.

Ruhiger Moment: Auch die Cutscenes wurden intern mit Effekten versehen.

Visuelle Optimierung
Ist der obige Schritt zumindest durch die erste Iteration der Performanceoptimierung gelaufen, so können die Effekte und Performance in den Levels leicht aufeinander abgestimmt werden. Dank klarer Namenskonventionen sind alle Effekte in der Datenbank als »Standardversion« gebaut und entsprechend mit Tags versehen worden. Diese sehen gut aus, kosten angemessen wenig oder viel und treffen einfach gesagt einen guten Mittelweg zwischen Optik und Performance. Gegen Ende der Produktion ist ein Großteil des Spiels schon mit diesen existierenden generischen Effekten ausstaffiert worden, so dass man nun etwas gezielter Zeit in kleine Set Pieces investieren kann, um deren Qualität anzuheben. Sinnvoll ist es hier, die Standardversion in eine teurere und eine billigere Version zu duplizieren – solange sich weder die Größe noch die Dynamik schwerwiegend ändern. Ein Feuer bekommt für die teurere Version mehr Funken, Rauch und Hitzeflimmern, bleibt aber von den Ausmaßen und dem allgemeinen Aussehen gleich. Nun kann man Level ausgesprochen schnell durch das Ersetzen der schon platzierten Emitter in Hinsicht der Framerate und Optik überarbeiten. Hat die Szene noch Performance übrig, so reichen einige wenige Klicks, um die bestehenden Effekte durch eine visuell ansprechendere Variante zu ersetzen. Ruckelt eine Szene dank der Effekte nur noch vor sich hin, kann man die billigere Variante der Effekte einsetzen.

Workflow
Dieser Workflow kommt nicht nur dem Spiel, sondern auch den Nerven aller Beteiligten zugute. Durch die frühe und doch recht zuverlässige Repräsentation können Level Designer mit den Effekten scripten, die kreative Führungsriege hat eine gute Idee vom Endresultat und die Effektkünstler haben den Seelenfrieden, dass zumindest die größten Überraschungen vermieden werden. Die klare Aufteilung mit teuren Variationen und die kontrollierte Anzahl der Effekte stellen auch auf der kreativen Seite einen ausgesprochen großen Vorteil dar. Anstatt Szenen im Spiel aus dem Stand von nichts auf »so gut wie möglich« zu bringen, kann mit bedeutend weniger Zeit die Szene ohne große Mühe repräsentativ zusammengebaut werden. Sie sieht dann vielleicht noch nicht großartig aus, aber alle Beteiligten haben zumindest eine grobe Vorstellung vom Endergebnis. Die Zeit, die explizit nicht ins Polieren der Szene gesteckt wird, kann nach der Arbeit der anderen Teams dazu verwendet werden, die Effekte möglichst stark aufzuhübschen. Die Vorteile für das Team sind immens -- anstatt eine Szene unter Zeitdruck möglichst beim ersten Anlauf direkt »richtig« hinbekommen zu müssen, ist die erste Iteration bei diesem Ansatz ganz klar nur ein besserer Platzhalter. Spätere Fixes sind fest eingeplant, und richtig toll muss das Ganze sowieso erst nach der letzten Phase aussehen. Am einfachen Beispiel erklärt: In sechs Stunden eine Szene mit Effekten von »nichts« auf »fertig« zu bringen, kann recht stressig sein und muss später oft überarbeitet werden. Dreimal eine Stunde für das Bauen, Bugfixes und Anpassungen und dann einmal drei Stunden am Stück, um einen eigentlich schon fast fertigen Effekt richtig zum Glänzen zu bringen, klingt dagegen für die meisten Artists ansprechender. Anstelle von einem unter Druck zusammengebauten Effekt, der meistens hinter den Ansprüchen des Künstlers zurückbleibt, gibt es genug Zeit zum Überlegen, zum kontrolliert Fehler machen und letzten Endes um Arbeit abzuliefern, die den persönlichen Standards nahe kommt.

Fazit
Was hoffentlich in nahezu allen Teilen dieses Artikels durchschimmert, ist ein Gefühl von »Weniger ist Mehr«. Diese sehr einfachen Worte stellen natürlich in unserer Branche eine extreme Gratwanderung dar: Jeder für sich und die Firma im Allgemeinen will das beste Projekt entwickeln, der Publisher hätte das Ganze gerne auch noch pünktlich und dazu ist da noch das Bestreben der Mitarbeiter, sowohl Freizeit als auch ein erträgliches Maß an Stress zu haben.
»Weniger« heißt hier aber vor allem eins: Mehr Zeit, um sich auf das Wesentliche zu konzentrieren, mehr Kontrolle über Risiken, mehr Übersicht über erledigte und geplante Arbeit und mehr Zufriedenheit dank eines besseren Spiels.
Schon das Streichen oder Kürzen einiger weniger Eckpunkte kann einen massiven positiven Schub für das Projekt bedeuten. In einem effektlastigen Shooter heißt das Schneiden einer Explosion von vielen wohlmöglich, dass der betroffene Mitarbeiter den Rest seiner Arbeit als bedeutend entspannter, kreativer und nicht zuletzt belohnender empfindet. Das Resultat ist vielleicht eine Explosion weniger, aber dafür eine höheres Maß an visueller Qualität für den Rest des Spiels. Der Spieler wird die fehlende Explosion bei geschickter Planung nicht vermissen, dafür aber feststellen, wie gut der Rest des Spiels aussieht – ein klarer Gewinn für den Spieler, für das Projekt und seine Bewertung und vor allem für die Entwickler selbst.
Florian Zender

Florian Zender
ist Lead Effects Artist bei Yager Development.

Florian hat Informatik an der FH Trier und Kunst an der University of Teesside in England studiert und arbeitet seitdem bei Yager Development in Berlin. Heute ist er Lead Effects Artist von Spec Ops: The Line.