Offene Spielwelten designen

Environment Grafiker Sascha Henrichs zeigt im Artikel, wie Piranha Bytes für Risen 2 die unterschiedlichen Elemente einer offenen Rollenspielwelt konzipiert, erstellt und implementiert hat.

Ein Gedanke, der heute jeden seriösen Publisher, Producer, Business Angel oder gar den Game-Design-Dozenten an der Universität erschaudern lässt: »Lasst uns doch ein 3D-Rollenspiel mit offener Welt machen!« Denn mittlerweile hat es sich herumgesprochen: »One does not simply walk into Mordor.«

Ein Computerspiel mit einer offenen Welt macht man nicht einfach so. Wenn man nicht weiß, worauf man sich einlässt, frisst es einen in der Entwicklung auf. So viel zum heutigen Wissensstand.

Als wir damals mit Piranha Bytes unser erstes Rollenspiel mit freier Welt entwickelten, wussten wir ebenfalls nicht, worauf wir uns einließen. Gothic war damals zusammen mit Ultima IX: Ascension allein an der Front der »Open World 3D RPGs«. Beide Spiele hatten sehr viele Bugs und erhebliche Performanceprobleme. Und zumindest von unserem Spiel weiß ich, dass es seine geplante Entwicklungszeit weit überschritten hat. Wir hatten ein Fass ohne Boden erschaffen. Und selbst nach vielen Jahren in der Branche bleibt es jedes Mal aufs Neue eine Herausforderung, allen Aspekten der Entwicklung entsprechende Beachtung in der Planung zu schenken und diese im Voraus mit realistischen Zeiteinschätzungen zu versehen.

Piranha Bytes ist seit jeher eine kleine Firma, welche die durchschnittliche Mitarbeiteranzahl von etwa 25 nur zu Gothic-1-Zeiten signifikant überschritt. Das hat zum einen den Vorteil hat, dass es uns selbst nach 15 Jahren in der Branche noch gibt, aber auf der anderen Seite auch den Nachteil, dass wir nach immer effizienteren Methoden suchen müssen, um in Sachen Technik, Feature-Anzahl und Spielgröße noch international mithalten zu können. Um einen kleinen Einblick in die Entwicklung unserer Spiele zu geben, will ich in diesem Artikel die Arbeit an offenen Welten in Computerspielen beschreiben, hauptsächlich aus der Sicht des Level-Grafikers.

Weil es gerade in der Anfangsphase eines Projekts sehr ungeordnet zugehen kann und jede Firma auch mit anderen Voraussetzungen in die Spieleentwicklung geht, kommt es vor, dass eine Prototype-Phase in der Entwicklung für verschiedenste Dinge genutzt wird. Jeder Arbeitsbereich in der Firma des Entwicklers hat hier andere Aufgaben. Wo sich Grafiker vielleicht neue Produktionstechniken aneignen oder konkret einzelne Locations des neuen Projekts ausblocken, werden dagegen bei den Programmierern und Game Designern unter Umständen neue Gameplay-Mechaniken getestet.

Und selbst die Prototype-Phase an sich kann je nach Projekt und Unternehmen komplett anders genutzt werden. In einigen Fällen wird jene Phase sowohl zum Testen von Ideen als auch für die Erstellung eines »Pitches« benutzt. Andere haben in dieser Phase bereits den Vertrag und testen weitere Features oder verbessern die firmeninternen Abläufe.

In unserem Fall der Open-World-Erstellung (mit einem kleinen Grafiker-Team) kann man davon ausgehen, dass sich noch sehr viele Dinge im Laufe der Produktion ändern werden. So wandeln sich vereinzelt etwa die Designvorstellungen, eventuell wird das ein oder andere Gameplay angepasst oder das Projekt muss verkleinert werden … auch das soll ja schon mal vorgekommen sein.

Dementsprechend hat es sich für uns als besonders sinnvoll herausgestellt, dass wir nicht schon in der Prototype-Phase die komplette Welt mit allen Inseln und Locations »ausblocken«, sondern zunächst einen grafischen Prototyp entwickeln und danach in der Pre-Production eine Location nach der anderen angehen und diese soweit wie möglich ausarbeiten. Also letztlich einzelne Teile des Spiels immer auch während der Entwicklung zu prototypen. Dies beschränkt sich in dem Fall natürlich nur auf das Level Design, beziehungsweise auf den Grafikbereich.

Es ist so, dass wir unsere Spiele teils konkret und teils nur im Hinterkopf in ihre Einzelteile zerlegen. Einzelteile sind hier sinnvoll abtrennbare Bereiche, die man im besten Fall modular abarbeiten kann. Hierbei gilt es auch immer zu beurteilen, ob ein Bereich ein »must have« oder ein »nice to have« ist. Einen abtrennbaren Bereich kann man zum einen in einer Location, einer Fraktion, einem Story-Fragment, oder gar in einem Arbeitsschritt (z.B. Innenraumausleuchtung von Gebäuden) sehen. Und diesen Bereich kann man priorisieren. Grundlage für diese Priorisierung ist im Übrigen nicht nur die Relevanz für das Spiel, sondern auch der zusammen mit dem Publisher erarbeitete Milestone-Plan für das Projekt, an dem auch Presseaktionen hängen.

So ist es zum Beispiel sinnvoll, wenn die Grafiker den Anfang des Spiels nicht zuerst erstellen, sondern den Mittelteil. Diesen muss die Story-Abteilung in der Regel nämlich am schnellsten fertigstellen, weil gerade dieser Bereich häufig besonders aufwändig oder sehr relevant ist.

Grundlage für jegliches Level Design, sei es für offene Welten oder ein lineares Spiel, ist natürlich immer die Story, die erzählt werden soll. Dazu gehören das Setting, spezielle Locations, Figuren sowie deren Geschichte. Sortiert werden diese Informationen am besten an einem zentralen Ort im Firmennetzwerk, egal ob in Form von Dokumenten oder innerhalb eines Wikis, welches in dem Zusammenhang natürlich flexibler ist, weil man Querverweise, also weiterführende Links, setzen kann.

[Wiki]

Ein Screenshot aus dem Wiki zu Risen 2, bei dem vor allem auch auf Querverweise zurückgegriffen wird.

Wenn man sich zum Beispiel eine Questreihe eines NPCs ansieht, dann sind dort direkt weiterführende Links zu seiner Person gesetzt. Im besten Fall hat man in dem Wiki immer alles abgedeckt. Bleiben wir bei dem Beispiel des NPCs, würden in dem Artikel über seine Questreihe auch Verlinkungen zu seiner Person/Geschichte, seiner Location und seinen Fähigkeiten gesetzt sein. Außerdem würde sich im besten Fall auch ein Link zu Informationen zum Animationssystem finden, da es sich ja um einen animierten Character handelt.

Die Verwendung eines Wikis hat sich insbesondere auch für den Level-Bereich als sinnvoll herausgestellt, weil grundlegende Antworten, die der Level-Bereich von der Story braucht, hier in schriftlicher Form vorliegen und somit Kommunikationsaufwand eingespart wird. Zudem werden Konzeptzeichnungen verlinkt und Level-Design-Skizzen an den entsprechenden Stellen zur Verfügung gestellt.

[Erdtempel]

Der Eintrag des Erdtempels im Wiki hilft auch beim Level-Design weiter, weil grundlegende Story-Infos dort bereits hinterlegt sind und auf diese Weise Kommunikationsaufwand gespart wird.

Natürlich kommt man nie um die direkte und enge Kommunikation mit den einzelnen Bereichen herum, aber im Wiki werden zumindest grundlegende Projektinformationen vermittelt und ein Großteil kleinerer Fragen kann auf diesem Weg bereits beantwortet werden.

Bei jedem neuen Titel sollte zunächst eine leere Projektstruktur aufgesetzt werden, in welche die Datenbasis integriert wird. Wie diese Struktur aussieht, hängt natürlich von der verwendeten Engine-Technologie ab. Wir bei Piranha Bytes benutzen seit jeher eigens programmierte Engines, die speziell auf unsere Bedürfnisse zugeschnitten sind. Dennoch kommen wir nicht umhin, unsere Projektstrukturen von Projekt zu Projekt zu verbessern und zu vereinfachen. Der Anfang eines neuen Projekts ist dementsprechend bestens dafür geeignet, noch einmal alles über den Haufen zu werfen und die Erfahrungen vom letzten Projekt in eine verbesserte Projektstruktur einfließen zu lassen. Wenn man hierfür aber eine schon vorgefertigte Struktur wie etwa im Unreal Development Kit hat, wird man es vielleicht vermeiden, große Änderungen an den Verzeichnissen vorzunehmen.

Anschließend finden Materialsichtungen statt, in denen man die Altdaten bewertet und sich entscheiden muss, was für das neue Projekt übernommen und was hingegen verworfen wird. Eventuell werden neue Nomenklaturen festgelegt, weil die alten Daten nicht gut zu handeln waren. In Risen 1 hatten wir zum Beispiel eine weniger gut sortierte Nomenklatur für unsere Texturen. So hieß eine Diffuse Texture für ein Fass etwa folgendermaßen:

[Kasten]

Obj_Barrel_1_Df.tga

Objekt-Textur/Name des Objekts/Iteration/Diffuse Texture

[Ende]

Dieser String war allerdings wenig aussagekräftig und im Hinblick auf Massen-Datenverabeitungen wenig flexibel. In Risen 2 heißt dieselbe Textur dementsprechend nun so:

[Kasten]

Obj_Dec_Barrel_Beer_1_L1_Df.tga

Objekt Textur/Objekt-Kategorie (Decoration)/Name des Objekts/Erweiterter Name des Objekts/Iteration/Level of Detail (Stufe 1)/Diffuse Texture

[Ende]

Der String wurde also durch wichtige Informationen erweitert. Durch diese Zusatzinfos können die einzelnen Assets sinnvoll in den Entwicklungstools zugeordnet (z.B. alle Decoration Assets in dem Editor automatisch in einen eigenen Ordner verschieben) oder Massenverarbeitung auf einzelne Asset-Kategorien angewendet werden (z.B. alle Terrain-Texturen (Prefix TR) um die Hälfte kleiner skalieren).

Wenn man sich also auf ein Projekt geeinigt hat und die Projektplanung entsprechend vorangetrieben wurde, kann mit der Pre-Production begonnen werden. Und zwar in unserem Fall konkret mit der Heightmap einer Insel, deren Key Features zuvor von der Stroyabteilung festgelegt wurden.

[Bild Antigua bitte mit folgender Legende bestücken]

Von der Storyabteilung werden die Key Features für eine Region erstellt. Neben Story und Quests wird auf der Skizze auch die grobe Topologie abgebildet.

Antigua Oberwelt

A) Fischerhütte von Eddie und Duncan

B) Klabautermanngrotte mit Seitenarmen

C) Kleine Schatzhöhle

D) lange Schatzhöhle, die zu Beginn verschlossen ist.

E) Macs Aussichtsturm

F) Stadt

G) Wasserstelle

Monster/Kampfplätze

1) Klaubautermanngrotte -- Leviathan

2) Garcias Schatzhöhle links -- Cavebats links in Seitenarm

3) Butchs Schatzhöhle -- Duell im hintersten Bereich

4) im Flussdelta -- Alligator

5) Höhle bei Mac zur Stadt -- Cavebats, Tombspider in Nebengang

6) Macs Strand links und Macs Strand rechts bei Höhle -- Sunken Ones

7) kleiner Strand bei Fischerhütte -- Giant Crabs

8) Dschungel -- Gorilla

[Legende Ende]

[Heightmap]

Die Heightmap wird zunächst nur grob gestaltet, um die Laufwege zu testen.

Die Heightmap wird zunächst sehr grob und ohne Texturen im eigenen Game Editor erstellt. Die Laufwege werden auf Basis der Skizzen nachgebildet und anschließend im Spiel abgelaufen. Hier ist es wichtig, auf ein spannendes Pacing zu achten, also Zeitabstände abzupassen, innerhalb denen der Spieler wieder einen neuen Schauwert oder ein Ereignis erlebt. Wenn man die Karte also abläuft und merkt, dass es langsam langweilig wird, muss dem Spieler etwas Neues in der Karte geboten werden. Dies können Vistas, also Aussichtspunkte auf die Landschaft, Mini-Locations oder auch Events sein (Spieler löst durch einen Triggerpunkt ein Ereignis wie etwa ein Erdbeben oder eine Kamerafahrt aus.) Was genau ein gutes Pacing ist, ist hierbei nicht in Stein gemeißelt. Niemand läuft bei uns mit der Stoppuhr durch die Level. Wir beurteilen die Maps immer spontan beim Durchlaufen. Jede Topologie einer Karte ist anders und es kann sein, dass man nach einer Anhäufung von Ereignissen erst einmal wieder lange Zeit gar nichts in der Karte bietet, außer Raum zum Entdecken. Auch dies wird von unserem Spieler verlangt und ist wichtiger Teil eines jeden Spiels von Piranha Bytes.

Man sollte allerdings darauf achten, dass eine Spielfläche nicht von vornherein zu groß wird. Nicht, weil man unter Umständen zu wenig Inhalt bieten kann, sondern weil jeder Quadratmeter mehr Inselfläche auch mit Objekten und Texturen versehen werden möchte und somit Mehrarbeit generiert.

Dies ist ein Punkt, der uns jedes Mal aufs Neue schwerfällt. Gebiete klein zu halten war noch nie eine unserer Stärken.

Ein sehr interessanter Aspekt bei unseren Spielen ist es, der Welt einen gewissen Sandbox-Charakter zu verleihen, dabei aber nie die Spielelogik zu vergessen. So gehen wir in der Regel nie davon aus, dass ein Spieler nur den offiziellen Weg zu einer Location nehmen kann. Die Erfahrung hat gezeigt, dass der Spieler es liebt, verbotene Wege zu gehen, also Wege, die eigentlich gar nicht zum Spielfeld gehören. Für solche Zwecke sind alle Mittel Recht, die dem Spieler zur Verfügung stehen. Sei es Levitation in Risen 1 oder das Äffchen in Risen 2, das Spieler in entlegene Winkel steuern können -- oder aber einfach nur zu seichte Heightmap-Berge, die der Spieler erspringen kann. Wir müssen stets auf der Hut sein, dass der Spieler keine signifikanten Storyteile überspringen kann, um zu einer weiterführenden Location zu gelangen. Dies ist natürlich nicht ausnahmslos möglich und im besten Fall belohnen wir auch mal einen kreativen Einfall mit einem Erfahrungsbonus oder einer neuen Dialogoption. Nach diesem kleinen Exkurs aber nun wieder zur Grafik.

Wenn man sich letztlich auf eine Landschaftliche Ausgestaltung festgelegt hat, werden schon erste Terraintexturen erstellt und verteilt. Die Texturen sind in der Regel erst einmal nur Platzhalter, weil es einiges an »Trial and Error« benötigt, vernünftige Landschaftstexturen zu erstellen. Oftmals kann man eine Textur und ihre zugehörige Normalmap erst wirklich beurteilen, wenn man diese auf der Landschaft platziert hat. Erst dann lässt sich erkennen, wie die Beleuchtung mit den »Features« der Normalmap zurechtkommt und ob die Oberflächenstrukturen gut lesbar sind. Wenn eine Normalmap eines Felsenmaterials zum Beispiel mit sehr vielen »Features«, also Ein- und Auswölbungen versehen ist, so kann dieses Material sehr unruhig wirken, wenn es letztlich auf der Heightmap liegt. Diesen Effekt kann man reduzieren, wenn man das Material etwas ausgedehnter auf die Felsen mappt -- also letztlich das UV-Mapping verkleinert. Dann wiederum hat man mit sehr großen Pixeln zu kämpfen, die das Material im Nahbereich sehr verwaschen aussehen lassen.

[Felsen]

Beispiel für verwaschene Texturen im Nahbereich. Passt die Diffuse außerdem nicht zur Normalmap, generiert man einen Pixelbrei.

Während also die Spielfläche wächst und in Absprache mit der Story ausgearbeitet wird, sind auch die anderen Mitarbeiter im Environment-Bereich (bei uns einfach »Level-Bereich« genannt) schwer beschäftigt. Jemand muss sich um das Outsourcing kümmern. Das heißt, es müssen hier Listen von Objekten verwaltet, Informationen aus allen relevanten Departments zusammengesammelt und diese mit Concept-Zeichnungen an die einzelnen Studios oder Freelancer assigned werden. Informationen müssen etwa gerade bei Interact-Objekten vom Game Designer und Animator zur Verfügung gestellt werden -- also jenen Objekten, die eine Interaktion mit dem Spieler vorsehen (meist in Verbindung mit einer Spieleranimation). Handelt es sich zum Beispiel ein Podest, auf dem eine kleine Statue platziert werden soll, so gibt der Game Designer zunächst vor, ob das Objekt von allen Seiten benutzbar sein soll. Außerdem gibt er an, ob es einer bestimmten Fraktion zugehörig ist und in welchem Zusammenhang es üblicherweise benutzt wird. Steht es zum Beispiel immer in Dungeons, würde man es nicht mit Efeu überwuchert darstellen.

Der Animator hingegen gibt uns die Maße. Er kann uns sagen, wie weit die Abstellfläche auf der Plattform vom Körper der Spielerfigur entfernt sein darf und außerdem teilt er uns mit, auf welcher Höhe die Abstellfläche stattfinden muss, um diese Animation etwa auch auf anderen Objekten anwenden zu können.

Das Outsourcing verlangt vielerlei Qualitäten von demjenigen, der es bearbeiten muss. So manch guter Grafiker wurde durch die Besetzung einer solchen Stelle schnell zu einem gefrusteten Mitarbeiter, der keine Grafiken mehr macht, sondern nur noch Listen und Assignments schreibt. Aber dies nur am Rande.

Desweiteren gibt es im Level-Department natürlich jemanden, der den gesamten Level-Bereich verwaltet und mit der Projektleitung kommuniziert. Und aufgrund unserer kleinen Teamgröße ist dieser Jemand gleichzeitig Level Lead, Teilzeit-Art-Director, Content-Ersteller, Researcher und Ansprechpartner für alles.

Die regulären 3D Artists werden gerade in der Anfangsphase für das Erstellen der Höhlen mitsamt finaler Texturen, das Ausblocken der Siedlungen und das Erstellen der Dummy Meshes (also groben 3D-Daten) für das Outsourcing eingesetzt. Hierbei verläuft das Prototyping der einzelnen Locations ähnlich wie das des Terrains.

Wenn man eine Siedlung zu erstellen hat, dann wird zunächst eine grobe Topologie der Stadtfläche in der Heightmap gebaut. Dann werden vereinfachte Modelle der Häuser unter Anleitung und in Absprache mit dem Story-Department in die Stadtfläche eingefügt.

[Stadt]

Das Prototyping der Siedlungen funktioniert genau wie beim Terrain: Zunächst wird eine grobe Topologie gebaut, dann werden die vereinfachten der Häusermodelle in Absprache mit dem Story-Department hinzugefügt.

Danach werden die Laufwege beurteilt, indem man die Locations immer wieder im Spiel abläuft, dasselbe auch bei den Höhlen. Einziger Unterschied: Hier werden keine Heightmaps benutzt. Alle Höhlen werden direkt in 3Ds Max gebaut. Zunächst sehr grob und ohne Texturen, um die Laufwege vorab in der Engine zu kontrollieren. Wurden die Ausmaße von der Stroy-Abteilung abgenommen, so wird die Höhle anschließend komplett mit Texturen final umgesetzt.

Zu diesem Zeitpunkt wird nach Möglichkeit auch schon ein Großteil der Speedtree-Vegetation erstellt. Ein Vorgang der einen Artist unter Umständen mehrere Wochen in Anspruch nimmt -- je nachdem, ob man vielleicht schon fertige Vegetation aus einem vorherigen Projekt übernehmen kann oder nicht. Wenn man allerdings einen Baum aus der mitgelieferten Library verwendet, kann dieser immer nur den Anfangspunkt für einen Ingame-Baum darstellen. Denn die Bäume aus der Library sind sehr hochpolygonal und die LOD Stufen sind oftmals nicht passend eingestellt. Außerdem möchte man vielleicht eigene Texturen für die Bäume verwenden und die Collision Cylinder müssen in der Regel auch noch nachjustiert bzw. komplett neu gesetzt werden.

[Speedtrees]

Die Bäume aus der mitgelieferten Speedtree-Library müssen immer noch nachbearbeitet werden, was einen erheblichen Arbeitsaufwand bei einem Spiel wie Risen 2 bedeutet, das sehr stark auf realistische Vegetation setzt. Im Bild sehen Sie eine Auswahl der selbst erstellten Speedtree-Bäume.

Aus diesem Grund braucht man viel Vegetation, die speziell für das eigene Spiel entworfen werden muss. So zum Beispiel unterschiedlich große Büsche, Efeu, das niedrigpolygonal gebaut wird oder spezielle Fantasiepflanzen für die Höhlenvegation.

All dies bedeutet einen immensen Arbeitsaufwand und wird aber gleichzeitig sehr früh in der Produktion benötigt. Pflanzen sind für ein Open-World-Spiel in unserem Setting unabdingbar und ein riesiger Faktor, was die optische Wirkung unserer Levels angeht. Mit Vegetation werden Silhouetten erschaffen, mit ihr kann man Räumlichkeit erzeugen und nicht zuletzt Stimmungen beeinflussen. Mit Vegetation kann man aber auch die Performance zerstören, den verfügbaren Grafikspeicher auffressen und Programmierer in den Wahnsinn treiben. Das ist wahrscheinlich auch der Grund, warum fast durch die gesamte Produktionszeit hindurch immer wieder an den Bäumen gefeilt und verbessert wird. Die letzten Änderungen an den Bäumen nimmt man in der Regel kurz vor Goldmaster vor.  Oder auch mal danach ...

Wenn man einmal die gesamte Anfangsphase in der Entwicklung gemeistert, ist der Rest in der Regel nur noch ein Rennen gegen die Zeit. Alle Posten sind besetzt, jeder weiß, was er zu tun hat, die Milestones sind bekannt und das Team hat sich nach einiger Zeit eingespielt. Das Projekt rollt. Um hier den Faden nicht zu verlieren oder Verzögerungen zu generieren, ist es unbedingt notwendig, in kurzen Intervallen (je nach Projektstand) Meetings zu halten und sich stets untereinander auszutauschen. Jeder sollte auf dem Laufenden sein, was der Andere gerade tut. Zumindest in seinem Bereich.

Ich selbst setze stark auf Transparenz innerhalb des Level-Bereichs und in Richtung Projektleitung. Dadurch, dass eigene Schritte stets unter Aufsicht stehen, sinkt das Potenzial, sich zu verrennen um ein Vielfaches. Isoliert sich ein Bereich in der Projektentwicklung zu lange, kann dies zu teils extremen Fehlentwicklungen führen. Es können hier Dinge in der Entwicklung vergessen werden (vorzugsweise Spielteile, die man sowieso immer vor sich hergeschoben hat), oder es treten signifikante Fehler in der Datenerstellung auf (Polycounts!) -- oder aber man hält sich schlichtweg nicht an Designvorgaben. Wenn man all das im Griff hat und der Affenstall nicht durchdreht, kann man das Projekt Woche für Woche wachsen sehen.

In der Regel versuchen wir, einzelne Inseln schon in einem möglichst finalen Zustand abzuliefern, bevor wir uns einer neuen Insel zuwenden. Dies funktioniert natürlich nicht immer und spätestens, wenn Outsourcing-Daten ins Spiel kommen, muss man mit Platzhaltern für die ausgelagerten Objekte arbeiten. So wird dann zumindest die Objektplazierung der Natur und der Höhlen final gehalten.

Der Tag und Nachtwechsel zusammen mit seinen verschiedenen Stimmungen und Wetteratmosphären ist in heutigen Open-World-Spielen natürlich nicht mehr wegzudenken. Und es zeigt sich, dass das Wetter zusammen mit seinen Post-Processing-Effekten ein Schlüsselelement in der Präsentation der Spielwelt darstellt. Dabei sind die Möglichkeiten hier gleichsam faszinierend wie auch lähmend umfangreich und teils zerstörerisch. Um dies zu veranschaulichen, müssen wir zunächst mal das Wettersystem von dem Post-Processing trennen. In dem Post-Processing werden komplette Bildinhalte nachträglich nochmals verarbeitet, um zum Beispiel Überstrahlungseffekte zu erzeugen oder Farb- oder Kontrastanpassungen vorzunehmen. Dies allein ist jedoch schon die Büchse der Pandora. Man kann sich hier durch falsche Einstellungen sein komplettes optisches Ergebnis zerstören und dies im schlimmsten Fall noch nicht einmal bemerken. So kam es vor, dass wir während der Entwicklung von Risen 2 zeitweilig mit absurd schwachen Texturkontrasten gearbeitet haben, um einer suboptimal eingestellten Post-Processing-Queue vernünftige optische Ergebnisse abzuringen. Dem allein muss also schon unbedingt von Anfang an viel Aufmerksamkeit geschenkt werden und in der Bearbeitung der Post-Effekte muss unbedingt eine enge Kommunikation zwischen Programmierern und Grafikern stattfinden. Das Postprocessing ist aber noch nicht alles. Bevor die Welt durch diese Effektkette geschickt wird, will sie auch beleuchtet werden, und zwar vom »Wettersystem«.

[Wettereditor]

Piranha Bytes hauseigene Genome-Engine enthält einen Wettereditor, mit dem sich eine ganze Reihe Einstellungen wie etwa die Sonnen- und Mondlichtstärke, Ambient-Farben, die Wolkendichte oder auch die Nebelhöhe einstellen lassen.

Das Wettersystem unserer Engine sieht eine ganze Reihe von Einstellungsmöglichkeiten vor. Da gibt es einfache Werte wie etwa Sonnen- und Mondlichtstärke, Ambient-Farben, aber auch viele spezielle Werte wie zum Beispiel Nebelfarben-Multiplikatoren, Wolkendichte, -farben und -schnelligkeit, Ozeanfarben, Nebelhöhe und Nebeldichte, Dämmerungshimmelsfarben, Regenwahrscheinlichkeit, Regenaussehen sowie vieles, vieles mehr. Und dies alles noch einstellbar für jede Minute eines kompletten Tagesablaufs von 24 Stunden.

Diese große Menge an Möglichkeiten und der große Arbeitsaufwand, der für die Einstellung eines solchen Wetters benötigt wird, können zu großen Schwierigkeiten führen. Nicht zuletzt deshalb, weil ein Wettersetting direkt auch durch das Post-Processing beeinflusst wird. Und wenn in einer dieser Komponenten eine Fehleinstellung vorliegt, kann es passieren, dass man versucht, dem Fehler an falscher Stelle, nämlich in der anderen Komponente, mit einer Einstellung entgegenzuwirken. So kann etwa der »Tonemapper« aus dem Post-Processing zu starke Kontraste liefern, wenn er falsch eingestellt ist und dann versucht man dies unter Umständen mit einem hohen Ambient-Beleuchtungswert im Wetter wieder auszugleichen -- oder gar mit den Texturkontrasten selbst.

Diese große Fehleranfälligkeit hat nun dazu geführt, dass »Referenzwetter« in Zusammenarbeit mit den Programmierern als Standrads erstellt werden und diverse Werte in der Post-Processing-Kette einfach nicht mehr verändert werden dürfen.

Was diese beiden Systeme allerdings erreichen können, wenn sie aufeinander abgestimmt sind, kann man in dem auf dieser Seite dargestellten Szenen-Breakdown ganz gut erkennen: Es werden schöne Kontraste zusammen mit interessanten Highlights und einem atmosphärischen Nebel erzeugt.

[Szenen-Breakdown, entweder untereinander oder am liebsten „kompakt“]

Ein Teil der Landschaft von Antigua in den unterschiedlichen Ausbaustufen, gepaart mit atmosphärischem Nebel aus dem Wettereditor.

Offene Welten zu erstellen war mal deutlich einfacher. Früher hatten wir den ganzen fancy Firlefanz noch nicht, der uns Grafikern heute feuchte Träume beschert. Alles war einfacher und viel schneller erledigt -- allerdings war alles auch viel, viel hässlicher.

Letztlich ist die Produktion für mich persönlich über die Jahre hinweg wesentlich spannender geworden. Die Möglichkeiten und die optischen Ergebnisse sind um ein Vielfaches besser, als das früher der Fall war. Computerspiele zu entwickeln ist interessanter denn je. Leider werden die Produktionen aber auch wesentlich aufwändiger und somit teurer. So teuer, dass dies nicht mehr nur mit Anpassungen vom Budget aufgefangen werden kann. Kreative und handwerkliche Arbeiten werden mehr und mehr in den Osten ausgelagert, hervorragende Grafiker werden in Content-Managment-Positionen gepresst und die Qualität ist dennoch nie auf Anschlag, man kann nie zufrieden sein.

Heutzutage muss man immer effizienter werden, um auf internationaler Ebene mitspielen zu dürfen. Fantasie-Budgets wie für diverse Topseller unter den Computerspielen werden wir in Deutschland in absehbarer Zeit nicht erreichen, aber dennoch kann man auch aus dieser Situation etwas lernen. Je mehr wir dazu gezwungen werden, unsere eigene Arbeitsweise zu hinterfragen und zu optimieren, um Kosten zu sparen, desto mehr merken wir, wie ineffizient wir eigentlich zuvor gearbeitet haben. Man kann alles immer auch noch besser machen.

Sascha Henrichs

You will take over the responsibility for the creation and management of a game over its full product lifecycle.