Konzept und Design einer generischen Asset-Pipeline für 3D-Games

Transkript

1 Konzept und Design einer generischen Asset-Pipeline für 3D-Games Jan-Felix Wall D I P L O M A R B E I T eingereicht am Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg im September 2009

2 Copyright 2009 Jan-Felix Wall Alle Rechte vorbehalten ii

3 Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Hagenberg, am 19. September 2009 Jan-Felix Wall iii

4 Inhaltsverzeichnis Erklärung Vorwort Kurzfassung Abstract iii vii viii ix 1 Einleitung Hintergrund und Motivation Aufbau der Arbeit Vorbetrachtungen zum Thema Vorhergehende Entwicklung Besondere Anforderungen von Spielen Die Situation an der FH-Hagenberg Aufbau von Asset-Pipelines Vergl. mit der Kompilierung in der SW-Entwicklung Source-Engine als klassisches Beispiel Detaillierte Betrachtung der Model Pipeline Überblick der sonstigen Assets Der Entwicklungsprozess bei Cogaen Einbindung von 3D-Daten Levelerstellung Direkte Folgerungen aus den Problemen Asset-Pipelines Pipeline Anforderungen Contenterstellung Anbindung des Contents Asset Workflow Kollaboration Versionsmanagement Automatisierung und Pipeline Management iv

5 Inhaltsverzeichnis v 3.3 Analogien zu klassischen Pipelines D-Animation Kollaboration Renderfarmen Verwendbare Technologien aus der Softwareentwicklung Cross-Platform Development Versionsmanagement Continuous Integration Release Packaging Game Asset-Pipelines als Mischform Konzeption Wahl von Zwischenformaten Verschiedene Medien Grafik Sound Metadaten D COLLADA als zentrales Format COLLADA ist standardisiert und Open-Source Geeigneter und vielseitiger Aufbau Tools zur Contenterstellung D und Animation D-Grafik Sound Game-spezifisches Dedizierte Tools Integration ins 3D-DCC-Tool Versionsverwaltung und Kollaboration Aufteilung der Projektstruktur Code Repositories Artist Workspace Transferdaten der Pipeline Runtime Repository Dependencies und Tools Projekt Repository Weiterverarbeitung der Assets COLLADA in der Pipeline Automatisierte und ausgelagerte Verarbeitung Continuous Integration Zentrale Buildsysteme Konfiguration, Verwaltung und Überwachung Buildsystem Steuerung

6 Inhaltsverzeichnis vi 5 Projektarbeit Konzentration auf funktionale Schwerpunkte Contenterstellung und Export Weiterverarbeitung Engineanbindung Beschreibung des Projektes Maya Plug-In für Kollisionskörper Maya im Überblick Implementierung des Plug-Ins Anpassung des COLLADA-Exporters Refinery und Conditioner Post-Mortem-Analyse des Projektes Schlussbetrachtung 58 A Inhalt der DVD 60 A.1 Masterarbeit A.1.1 PDF-Dateien A.1.2 Grafiken A.2 Projekt A.2.1 Binaries A Windows A Mac OS X A.2.2 Testdaten A.2.3 Quellen A Visual Studio 2008 Sulutions A Xcode Projekte Literaturverzeichnis 63

7 Vorwort Als Artist, im tendenziell sehr technischen Fachbereich Game Development, gestaltete sich die Suche nach einem geeigneten Thema für die Masterarbeit anfänglich schwierig. Einen hilfreichen Ansatz bot dabei die Frage nach dem Grund für die allgemeine Unzufriedenheit im Studienalltag. Dabei zeigte sich schnell, dass in den Projekten immer wieder viel Zeit damit verloren ging, erstellte Assets an Änderungen der Engine anzupassen. Das Problem lag darin, dass Cogaen, die an der FH-Hagenberg entwickelte und verwendete Game-Engine über keinerlei Asset-Pipeline verfügt. Dieser umfangreiche und interdisziplinäre Themenbereich ließ zwar keine vollständige Implementierung im begleitenden Semesterprojekt zu, doch an dieser Stelle fehlte selbst ein grundlegendes Konzept ein solches Konzept sollte also Thema der Arbeit werden. Der Dank für direkte Beiträge zur Arbeit fällt an dieser Stelle kurz aus. Besonders meine Mutter hat durch ihre Korrekturvorschläge viele grammatikalische Winkelzüge verhindert und so stark zur Lesbarkeit des Textes beigetragen. Aber, wie so oft, liegen die Wurzeln des Erfolges weit entfernt. Ohne Rémi Arnauds Vortrag auf der FMX 2008 hätte ein entscheidender Ansatzpunkt für weitere Recherchen gefehlt, ohne meinen Praktikumskollegen Manuel Scherer hätte ich besagten Vortrag nie besucht; also Dank an beide, auch wenn sie sich ihres Wirkens in keinster Weise bewusst sind. Auch die Motivation ist entscheidend; während des Studiums und so letztlich auch für die Masterarbeit. Nicht zuletzt die hervorragende Zusammenarbeit im Game Development Kurs gab immer wieder neuen Antrieb und Schwung, trotz aller Widrigkeiten nicht aufzugeben. Auch all jenen, die mir in schweren Momenten beistanden, bin ich zu tiefem Dank verpflichtet: allen voran Andrzej Kozlowski und Claus Helfenschneider. An letzter und damit besonders exponierter Stelle, möchte ich schließlich meinem Betreuer Roman Divotkey und meiner geschätzten Studienkollegin Martina Karrer danken: Für die vielen Gespräche beim Mittagessen, die sich mitunter zwar nur am Rande, oder gar weit abseits des Themas Asset- Pipelines bewegten, dennoch aber stets wichtige Impulse für die Arbeit setzten. vii

8 Kurzfassung Die Komplexität heutiger Computer- und Videospiele erfordert umfangreiche Systeme für die Verwaltung und Integration der benötigten Assets. Im Gegensatz zur Verwaltung, existieren für die Engine-Anbindung keine umfassenden Standardlösungen, weshalb diese für jede Engine neu entwickelt werden. Das Ziel der vorliegenden Arbeit ist die Konzeption eines allgemeinen Basissystems für Asset-Pipelines, welches sich durch entsprechende Module leicht für die speziellen Anforderungen der jeweils verwendeten Engine adaptieren lässt. Die Grundidee besteht dabei in der Adaption bereits verfügbarer Teillösungen. Neben der naheliegenden Verwendung von COLLADA als zentrales Austauschformat wird dabei vor allem auf verschiedene Konzepte und Technologien aus der Softwareentwicklung zurückgegriffen. Den konkreten Anwendungsfall des entwickelten Konzeptes bildet der Aufbau einer Asset-Pipeline für die, an der FH-Hagenberg entwickelte Engine, Cogaen. Dies impliziert weitere Grundsätze in der Konzeption: Wegen des derzeitigen Fehlens einer Asset-Pipeline, sollten sich, zumindest die Basisfunktionalitäten des Systems, schnell umsetzten lassen. Verbesserungen des Workflows und der Integration können dagegen, durch den Austausch einzelner Module, in weiteren Entwicklungsschritten folgen. Da sich die Dauer einzelner Teilprojekte dabei prinzipiell auf jeweils ein Semester beschränkt, ist es wichtig, eventuelle Probleme mit den verwendeten Technologien im Vorhinein zu identifizieren, um diese bei der jeweiligen Projektplanung entsprechend berücksichtigen zu können. Zur Ermittlung entsprechender Erfahrungswerte dient dabei die erfolgte Testimplementierung. Aus diesem Grunde zielt diese auch nicht auf einen großen Funktionsaufwand ab, sondern auf den Einsatz möglichst aller unbekannten und damit kritischen Technologien. viii

9 Abstract The complexity of current computer and video games requires extensive systems for the management and integration of the needed assets. In contrast to the management of content, no complete standard solutions are available for the engine integration. Therefore, these Systems are developed from scratch for every single engine. The goal of the thesis at hand is the design of a generic base for asset pipelines, which can be easily customized to meet the specific requirements of the used game engine. One basic idea of this modular approach is to adopt available partial solutions for the various aspects of the system. Besides the rather obvious use of COLLADA as a central interchange format, many concepts and technologies are adopted mainly from classic software development. The implementation of an asset pipeline for Cogaen is used as a concrete use case of the presented concept. This game engine is developed at the University of Applied Sciences Hagenberg and therefore implies some more requirements for the concept: due to the lack of any asset pipeline for the engine, a basic version of the system should be implemented as quick as possible, while improvements of workflow and integration can be added in future iterations. The time frame of such sub-projects is generally limited to only one semester. Therefore it is vital to know any potential problems that may occur while using the various technologies and account for them early in the project scheduling. The test implementation of the system is developed to acquire the empirical values for such a scheduling. Because of that, it is not designed for great functionality, but to make use of any unknown and therefore critical technology that is involved in the system. ix

10 Kapitel 1 Einleitung Asset-Pipelines werden in der Spieleentwicklung allgemein wenig beachtet. Dies ist schwer nachvollziehbar, denn die Asset-Pipeline stellt den einzigen Anknüpfungspunkt des Artists an das Spiel dar. Somit ist sie für den Entwicklungsprozess eigentlich von zentraler Bedeutung und steht der Engine und ihren verschiedenen Systemen Rendering, Physik, KI, Sound etc. in keiner Weise nach. Dennoch finden sich sehr wenige einschlägige Quellen und meist wird das Thema nur in anderem Kontext, oft dem Multi-Platform-Development, angeschnitten. Immerhin besteht dabei aber ein weitgegender Konsens über den grundsätzlichen Aufbau von Asset-Pipelines: Eingangsdaten werden automatisch verarbeitet und schließlich in, für die Engine geeigneter Form, wieder ausgegeben. Die Implementierungen dieses einfachen Grundsatzes fallen dagegen sehr vielseitig aus, doch abgesehen von den immer wieder gleichen Features, die für jede Pipeline neu entwickelt werden, scheint ein grundsätzliches Problem in der allgemeinen Wahrnehmung des Themas zu liegen. Anders als Engines, werden Asset-Pipelines meist monolitisch betrachtet. Hier erfolgt oft nicht die, bei Engines übliche, Aufspaltung in verschiedene Teilbereiche, die, von den jeweiligen Fachleuten, einzeln entwickelt werden. Nein, Asset- Pipelines werden stattdessen als ganzes der Toolentwicklung zugeschrieben, häufig fehlt wohl auch jede Kommunikation mit der Contenterstellung (Zumindest die Interfaces mancher Tools lassen sich anders kaum erklären). Dass Asset-Pipelines jedoch mindestens ebenso interdisziplinär, wie Spiele und Engines sind, wird dabei regelmäßig unterschlagen. 1.1 Hintergrund und Motivation Die Erfahrung mit verschiedenen Systemen zeigt, dass, wenn auch unterschiedlich implementiert, sich Funktionen und Arbeitsabläufe stets sehr ähneln und sogar die gleichen Probleme auftreten. Diese Feststellung drängt 1

11 1. Einleitung 2 die Frage auf, ob bestimmte Grundstrukturen von Asset-Pipelines vielleicht doch vereinheitlicht werden können, um ein modulares Basissystem zu entwickeln. Dies böte den Vorteil, dass lediglich wenige Module für die konkrete Engine Implementierung angepasst werden müssen, während für alle Standardfunktionen auf ein stabiles Framework zurückgegriffen werden kann. Diese Überlegungen führen zur Idee einer generischen Asset-Pipeline. Wie bereits angemerkt, decken Asset-Pipelines das gleiche, weite Feld an Disziplinen, ab, wie dies auch bei Game-Engines der Fall ist. Dabei beschäftigen sie sich zwar nicht mit den verschiedenen Umsetzungen, wie der verwendeten Rendering-Technik, der Art der Physiksimulation etc., sind in ihrer konkreten Implementierung jedoch eng daran gebunden. Die Asset- Pipeline stellt die von den Systemen benötigten Daten bereit. Dies soll in möglichst optimaler Form erfolgen, doch um dies zu erreichen, sind zur Umsetzung, in jedem Teilbereich, genaue Kenntnisse der Materie erforderlich. Dies übersteigt wohl in den meisten Fällen die Fähigkeiten eines einzelnen Entwicklers, aber auf jeden Fall den Umfang einer einzigen Masterarbeit und der begleitenden Projektarbeit. Was an dieser Stelle also erfolgen kann, ist nicht die Implementierung, sondern das Konzept und Design, eines solchen modularen Frameworks. Die Konzeption erfolgt dabei in erster Linie aus Sicht des Anwenders welche Funktionen sind wichtig, hilfreich oder wurden vielleicht immer vermisst? Die verschiedenen Anforderungen ergeben sich dabei vorrangig aus eigenen Erfahrungen und Gesprächen mit anderen Entwicklern. Viele Feststellungen gründen auf der jahrelangen Beschäftigung mit der Contenterstellung für Spiele und lassen sich, in Ermangelung entsprechender Standardwerke, kaum durch konkrete Quellen belegen. Aus diesen Gründen mag die Arbeit teilweise essayeske Züge aufweisen, bei einem theoretischen High- Level-Concept erscheint dies jedoch weniger problematisch, als bei der Auseinandersetzung mit rein eindeutigen Fakten. Die dabei entwickelten Lösungsvorschläge orientieren sich vor allem an den, an der FH-Hagenberg, gegebenen Möglichkeiten zur Umsetzung. Dies bezieht sich einerseits auf die vorhandenen Technologien, folgt darüber hinaus aber einem sehr pragmatischen Ansatz: Da die Game-Engine der FH- Hagenberg bisher über keine Asset-Pipeline verfügt, muss sich eine, zumindest minimale, Pipeline möglichst schnell umsetzen lassen. Dieses, dann bereits produktiv einsetzbare, System sollte in weiterer Folge erweitert und verbessert werden können um schließlich die zeitgemäße Entwicklung von Spielen zu ermöglichen. 1.2 Aufbau der Arbeit Kapitel 2 dient dazu, ein grundsätzliches Verständnis der Materie aufzubauen und die derzeitige Situation zu erklären. Eine detailliertere Beschreibung der

12 1. Einleitung 3 Funktionsweise von Asset-Pipelines folgt in Kapitel 3. Dies bildet die Grundlage für die anschließende Konzeption. Dabei liegt ein Hauptaugenmerk auf der möglichen Adaption etablierter Systeme aus anderen Bereichen, die zu diesem Zweck näher beschrieben und analysiert werden. In Kapitel 5 wird schließlich die Projektarbeit beschrieben. Diese dient als Proof of Concept der erarbeiteten Konzepte, wobei anschließend sowohl Erfolge als auch die aufgetretenen Probleme erörtert werden.

13 Kapitel 2 Vorbetrachtungen zum Thema Dieses Kapitel dient dem grundlegenden Verständnis von Asset-Pipelines. Es verdeutlicht ihren grundlegenden Aufbau, die Gründe für die Verwendung von Pipelines und bietet verschiedene Beispiele für die Integration von Assets ins Spiel. 2.1 Vorhergehende Entwicklung Asset-Pipelines sind heute ein zentraler Bestandteil des modernen, sogenannten Tool-Based Development von Computerspielen, welches mit dem wachsenden Umfang von Projekten zunehmend an Bedeutung gewinnt. In der Pionierzeit wurden Computerspiele dagegen von wenigen, oft einzelnen Entwicklern programmiert, was sogar wörtlich zu nehmen ist. In weiterer Folge kam zur Programmierung die Erstellung verschiedenster Assets, also vom Spiel verwendeter Mediendaten hinzu. Dies erforderte, neben der Vergrößerung der Entwicklungsteams, die Notwendigkeit diesen Content in das Spiel zu integrieren. Die Programme mussten die entsprechenden Daten also lesen und verarbeiten können. Aufgrund etablierter und verbreiteter Formate für Bild- und Sounddaten, stellte sich dies zu Zeiten von 2D-Grafik noch wenig problematisch dar, doch änderte sich dies mit dem Aufkommen von 3D-Engines grundsätzlich Besondere Anforderungen von Spielen Die begrenzte Rechenleistung bedingt bei Spielen mitunter Daten, welche mit den bei Film und Animation eingesetzten Tools schlicht nicht erstellbar sind. Deshalb ist die Entwicklung spezieller Tools notwendig. Ein Beispiel 4

14 2. Vorbetrachtungen zum Thema 5 hierfür ist die CSG 1 -basierte Levelgeometrie wie sie seit Quake 2 und Unreal 3 eingesetzt wird um verschiedene Formen Szenenmanagements zu ermöglichen oder zu vereinfachen. Doch auch generell eignen sich die nativen Datenformate typischer DCC 4 - Tools wie Maya 5 oder 3ds Max 6, aufgrund ihres Aufbaus, nicht zur Verwendung in anderen Applikationen und das Fehlen geeigneter Standardformate führte zu einem anhaltenden Wildwuchs proprietärer Lösungen. Folglich bringt fast jede 3D-Engine ein Anzahl verschiedener Tools zur Contenterstellung mit In einfachsten Fällen beschränken sich diese auf Exporter für 3D-Meshes und Animationen, erstrecken sich jedoch häufig über Level-Editoren bis hin zu grafischen Tools zur Erstellung von Shadern und Materialien und vor allem auch einer automatisierten Pipeline zur Verarbeitung des erstellten Contents. Tatsächlich ist der Umfang des bereitgestellten Toolsets der zentrale Punkt bei der Vermarktung von 3D-Engines Die Situation an der FH-Hagenberg Betrachtet man die derzeitige Situation bei Cogaen 7, zeigt sich ein zweigeteiltes Bild. Bei der Entwicklung der Engine wird stark auf einen modularen Aufbau gesetzt. Das heißt alle Teilsysteme werden durch allgemeine Interfaces gekapselt, wodurch sich die jeweilige Implementierung leicht austauschen lässt. Dies bietet auf Seiten der Programmierung eine große Flexibilität und macht das Projekt sowohl aus akademischer Sicht als auch im Hinblick auf das, zunehmend an Bedeutung gewinnende, Multi-Platform- Development sehr interessant. Jedoch wurde gleichzeitig die Assetanbindung, konzeptionell und in ihrer Implementierung, bisher stark vernachlässigt, was die Engine derzeit praktisch produktionsuntauglich macht. Im Umgang mit Assets implementiert Cogaen lediglich die Grundfunktionen der verwendeten Middlewares, wie beispielsweise das Laden von 3D- Meshes aus dem Dateisystem. Für spielspezifische Daten wie Levels, welche eine komplexe Ansammlung von Einzelobjekten und Eigenschaften darstellen, bietet die Engine jedoch keine Unterstützung. Stattdessen wurde eine Notlösung entwickelt. Bei dieser wird vom Level-Editing Tool, im konkreten Fall Maya, Code generiert, welcher die Funktionen zum Erstellen und Platzieren der entsprechenden Objekte aufruft. 1 Constructive Solid Geometry, Konstruktive Festkörpergeometrie 2 Quake ist ein Ego-Shooter von id Software aus dem Jahre 1996 ( 3 Unreal ist ein Ego-Shooter von Epic Games aus dem Jahre 1998 ( 4 Digital Content Creation, üblicherweise mit Bezug auf 3D-Anwendungen verwendet 5 DCC-Tool der Firma Autodesk ( 6 DCC-Tool der Firma Autodesk ( 7 Component Based Game Engine, eine an der FH-Hagenberg entwickelte Game Engine (

15 2. Vorbetrachtungen zum Thema 6 Die hierbei verwendeten Daten, wie zu ladende Meshes oder verwendete Materialien, sind spezifisch für die jeweilige Implementierung. Somit entsteht eine starke Abhängigkeit zwischen Assets und Implementierung, welche in striktem Gegensatz zum modularen Grundgedanken von Cogaen steht. Vielmehr bewirkt dieses Vorgehen, dass bereits fertiger Content immer wieder überarbeitet werden muss, wenn sich auch nur Details der Implementierung ändern. 2.2 Aufbau von Asset-Pipelines Eine Asset-Pipeline bietet die Möglichkeit zur Umgehung der meisten dieser Probleme. Sie bietet die nötige Abstraktion zwischen Asset-Erstellung und Engine, gleichzeitig ist dazu die detaillierte Konzeption der entsprechenden Interfaces erforderlich, welche bei der bisherigen Entwicklung von Cogaen stark vernachläsigt wurde. Erst dadurch kann sich die Engine jedoch von einer Programmierer-Sandbox zur produktionstauglichen Game Engine entwickeln Vergleich mit der Kompilierung in der Softwareentwicklung Funktional ist eine Asset-Pipeline vergleichbar mit dem Kompiliervorgang bei Hochsprachen in der Programmierung. Dabei wird aus mehr oder weniger stark abstrahiertem Sourcecode, mit Hilfe von Compilern, Maschinencode erzeugt, welcher für die Zielhardware und das verwendete Betriebssystem spezifisch ist. Entscheidend sind dabei zwei Punkte: Erstens kann, entsprechend sorgfältige Programmierung vorausgesetzt, das gleiche Programm durch Anpassung des Compilers für verschiedene Plattformen übersetzt werden und zweitens werden die jeweiligen Einstellungen in Projekt- oder Makefiles festgehalten. Dadurch ist der Vorgang jederzeit reproduzierbar und bedarf keiner weiteren Interaktion. Änderungen der Zielplattform erfordern lediglich die Erstellung neuer Settings und ein Neukompilieren des Quellcodes. Eine Asset-Pipeline verhält sich hierzu grundsätzlich analog. Der größte Unterschied besteht in der Erstellung der Sourcen. Während dies bei der Programmierung meist einfache Textdateien sind, welche mit beliebigen Editoren geschrieben werden können, kommen bei der Contenterstellung komplexe Tools zum Einsatz, welche in der Regel proprietäre Formate verwenden. Zwar wäre es in vielen Fällen auch möglich, diese direkt zu kompilieren, jedoch würde dies eine sehr enge Bindung an die jeweiligen Tools bedeuten. Bedenkt man, dass häufig verschiedene Werkzeuge für gleiche oder ähnliche Aufgaben zum Einsatz kommen, sei dies bedingt durch Lizenzen, unterschiedliche Eignung für konkrete Problemstellungen oder schlicht persönliche Präferenzen der jeweiligen Artists, ist eine solche Festlegung auf ein einziges Tool wenig erstrebenswert.

16 2. Vorbetrachtungen zum Thema 7 Source Assets 3ds Max + Plug-Ins Model + Animations.max Photoshop + Plug-Ins Texture.psd Intermediate Assets Model Max Exporter Animation Photoshop Exporter Texture (.tiff + Options) To the Game (Fast Path) Conversion Program + DLLs Final Assets Platform A Assets Packager Program Platform B Assets Platform A Assets Platform B Assets To the Game (Normal Path) Abbildung 2.1: Überblick einer Asset-Pipeline Aus diesem Grunde kommt für die verschiedenen Arten von Content jeweils ein gemeinsames Zwischenformat zum Einsatz. Dieses kann von jeweils allen verwendeten Tools im- und exportiert werden und dient auch zur Weiterverarbeitung in der Pipeline. Abb. 2.1 nach Noel Ilopis [7] zeigt neben dem grundsätzlichen Aufbau noch einen weiteren Unterschied zur Programm-Kompilierung, welcher besonders bei moderneren Pipelines zum Tragen kommt. Dies ist der in der Abbildung angeführte Fast Path, welcher eine Umgehung der Pipeline zu Entwicklungszwecken darstellt. Ein solcher ist sinnvoll, da die in der Pipeline durchgeführten Prozesse teilweise sehr rechenintensiv und damit zeitaufwändig sind und dem Artist so ein schnelles Feedback über Änderungen ermöglicht wird. Klassischere Pipelines lösen dieses Problem durch die weniger komfortable Möglichkeit einer schnellen Kompilierung. Die

17 2. Vorbetrachtungen zum Thema 8 Daten werden dabei weniger optimiert und aufwändige Berechnungen, wie zum Beispiel die Erstellung von Lightmaps, entfallen. Dies ist wiederum mit einem nicht optimierten Debug-Build von Programmen vergleichbar Source-Engine als klassisches Beispiel Ein sehr klassisches Beispiel stellt die Pipeline der Source-Engine 8 von Valve 9 dar. Diese wurde im Jahre 2004 zum ersten Mal für das Spiel Half-Life 2 10 verwendet und verfolgt mit ihrer Pipeline auf Grund ihrer Geschichte einen klassischeren Ansatz als viele Engines vergleichbaren Alters. Sie wird hier, vor allem wegen der sehr klaren Analogie zur Software- Kompilierung, herangezogen und gleichzeitig verdeutlicht ihre Geschichte, dass dieses Konzept trotz seiner Einfachheit äußerst flexibel ist. Während die Engine neu entwickelt wurde, weist die Pipeline nur kleine Veränderungen gegenüber der des Vorgängerspieles aus dem Jahre 1998 auf. Tatsächlich ist der Content des Vorgängers größtenteils kompatibel mit der neuen Engine, beziehungsweise ihrer Pipeline. Gerade am Beginn der Entwicklung stellt dies einen großen Vorteil dar, denn so kann auf einen umfangreichen Pool an (temporären) Assets zurückgegriffen werden, die sich später schrittweise ersetzen lassen Detaillierte Betrachtung der Model Pipeline Im Detail soll hier beispielhaft die Pipeline für 3D-Modelle betrachtet werden. Als Quelldateien dienen hier SMD 11 -Files, welche einfache ASCII-Dateien darstellen, die aus dem jeweiligen DCC-Tool exportiert werden. SMD ist ein rudimentäres 3D-Format und zeigt drei Ausprägungen, die sich nicht in ihrer sehr einfachen Syntax unterscheiden und primär einer besseren Übersicht dienen. Reference-Files beinhalten neben dem Skelett-Setup die Meshdaten in der Bind-Pose. Animation-Files beschreiben jeweils einen Animationsclip. Dazu beinhalten sie pro Frame eine Liste der animierten Nodes mit den jeweiligen Transformationsdaten. Vertex-Files, beinhalten sämtliche Blendshapes. Die Dateiendung lautet hierbei VTA, aber Syntaktisch sind diese lediglich eine Abwandlung der Animation-Files, wobei jeder Frame ein Blendtarget beschreibt. 8 Mehr Informationen unter 9 Valve Corporation, ein US-amerikanischer Spieleentwickler ( StudioMdl Data, ein Überblick über das Format findet sich unter:

18 2. Vorbetrachtungen zum Thema 9 model.qc model.mdl model_ref.smd model.dx80.vtx model_ani#.smd model_lod#.smd studiomdl.exe model.dx90.vtx model.sw.vtx model_phy.smd model.phy model_blend.vta model.vvd Abbildung 2.2: Überblick der Model-Pipeline der Source-Engine. Die Output-Daten erklären sich folgendermaßen: MDL-Dateien dienen zur Referenz des Modells und enthalten die Animationen, VTX-Dateien enthalten die optimierten Meshdaten (eine je unterstützter Plattform), PHY-Dateien enthalten Kollisionsmeshes und VVD-Dateien die Blendshapes. Hierzu werden, anstatt der Nodes, bei jedem Frame jene Vertices, inklusive ihrer Position aufgelistet, welche im entsprechenden Blendshape von der Bindpose abweichen. Die Aufschlüsselung der einzelnen Dateien dient zur Verdeutlichung der Einfachheit des Systems welches in Abb. 2.2 dargestellt ist. Das äußerst simple Format kann die benötigten Daten exakt abbilden und definiert sich dabei nur über die unterstützten Features. Dadurch ist es nicht nur von der konkreten Implementierung unabhängig, sondern könnte auch als Quellformat für jede andere Engine mit ähnlichem Featureset Verwendung finden. Zur Kompilierung des finalen Models wird neben sämtlichen SMD-Files noch ein QC 12 -File benötigt. Dieses ist mit einem Makefile vergleichbar und enthält alle zum Kompilieren notwendigen Informationen, wie Name und Pfad des finalen Modells, Suchpfade für die verwendeten Materialien, wie die verschiedenen SMD-Files zu behandeln sind und verschiedene enginespezifische Daten. Soll das Modell schließlich kompiliert werden, muss lediglich der Compiler mit dem QC-File als Parameter aufgerufen werden, was, zum Zweck einer Neukompilierung, sehr leicht für alle Models eines Projektes automatisiert werden kann. 12 Eine Zusammenfassung der Funktionen ist zu finden unter:

19 2. Vorbetrachtungen zum Thema 10 Hammer Editor map.vmf vbsp.exe map.bsp vvis.exe map.bsp vrad.exe map.bsp Abbildung 2.3: Überblick der Level-Pipeline der Source-Engine. Die schrittweise verarbeitete BSP-Datei kann in jedem Stadium von der Engine geladen werden Überblick der sonstigen Assets Auch andere Assets werden in sehr ähnlicher Weise behandelt. Die Erzeugung von Texturen erfolgt aus TGAs 13, wobei die benötigten Informationen zu Kompression 14, Filterung 15 und dergleichen in entsprechend benannten Textfiles festgehalten werden. Bei Levels kommt dagegen, die bereits erwähnte Möglichkeit eines verkürzten Kompiliervorganges zu Entwicklungszwecken, zum Tragen. Im Gegensatz zu den anderen Assets, sind Levels in der Source-Engine weitaus komplexer (Abb. 2.3 zeigt die Level-Pipeline). Sie bedürfen in ihrer finalen Version aufwändiger Vorberechnungen für das Szenenmanagement 16, sowie das Baking von Lightmaps. Dieses Preprocessing kann mehrere Stunden in Anspruch nehmen und würde den Entwicklungsprozess stark behindern, wenn es nicht umgangen werden könnte. Deshalb ist das Map-Compiling in drei Stufen aufgeteilt, welche verschiedene Abhängigkeiten aufweisen. Im ersten Schritt wird durch den BSP-Compiler 17 die von der Engine geladene Datei erzeugt, was zum Testen des Layouts oder gescripteter Ereignisse vollkommen ausreicht. Der anschließend ausgeführte VIS-Compiler 18 fügt der zuvor erzeugten Datei verschiedene für das Szenenmanagement und die Beleuchtung verwendete Informationen hinzu. Dieser Schritt kann während der Entwicklung ausgelassen, oder im Fast -Modus durchgeführt werden. Das größte Potential zur Verkürzung dieses Prozesses bieten jedoch vor al- 13 Truevision Advanced Raster Graphics Array: Ein einfaches Format für 2D Rastergrafik mit weitreichender Unterstützung 14 Je nach Bildinhalt unkomprimiert oder eine geeignete, von der Hardware unterstützte, Kompression 15 Die bei der Erstellung von Mip Maps verwendete Filterung 16 Source verwendet BSPs, wobei ein Culling über PVSs (Potentially Visible Set) erfolgt 17 Beschreibung des Tools unter 18 Beschreibung des Tools unter

20 2. Vorbetrachtungen zum Thema 11 lem spezifische Optimierungen des Levels, welche sich ebenso positiv auf das Laufzeitverhalten der Map auswirken. Der zuletzt ausgeführte Lighting-Compiler 19 (VRAD) berechnet die statische Beleuchtung der Szene. Verfügt die Map über die Daten aus dem VIS-Prozess, so erfolgt dies mit Hilfe einer Radiosity-Simulation, ansonsten kann durch Raytracing nur die direkte Beleuchtung berechnet werden, wobei sich beim Lighting, durch verschiedene Qualitätseinstellungen, typischerweise die meisten Möglichkeiten zur Zeitersparnis bieten. Während also beim Entwicklungsprozess hauptsächlich mit Testversionen der Levels gearbeitet wird, bietet dieses System die Möglichkeit zum Release, oder als Nightly-Builds, vollständig optimierte und final beleuchtete Versionen der Maps zu erstellen Der Entwicklungsprozess bei Cogaen Betrachtet man derzeit die Produktion eines Spieles mit Cogaen, fällt schnell auf, dass hier keine der angesprochenen Mechanismen umgesetzt sind. Beispielhaft sei hier das Projekt CaptAncestor 20 aus dem Sommersemester 2008 genannt, bei dem der Content im Wesentlichen in zwei Teilsysteme der Engine eingebunden werden muss Zur Darstellung wird die Open-Source Engine Ogre3d 21 verwendet, die physikalische Simulation erfolgt mit PhysX Einbindung von 3D-Daten Ogre3d verwendet proprietäre Binärformate für Meshes und Animationen, welche, mit den entsprechenden Exportern, direkt aus dem verwendeten DCC-Tool (Maya) exportiert werden, wohingegen Materialien von Hand mit Textdateien definiert werden müssen. Auch für die verwendete PhysX-Engine stehen, für Erstellung und Export von physikalischen Szenen, zwar Plug-Ins bereit, jedoch werden diese in der verwendeten Cogaen-Anbindung nicht unterstützt. Um den Aufwand für die Toolentwicklung zu minimieren und die Definition eines Szenenformates zu umgehen, wurde, wie bereits erwähnt, ein Maya-Script programmiert, welches den benötigten Code zur Erstellung der Spielobjekte generiert. 19 Beschreibung des Tools unter 20 Mehr Informationen zu CaptAncestor im Game-Development Wiki der FH-Hagenberg ( Hardwarebeschleunigte Echtzeit Physikengine der Firma Nvidia (

21 2. Vorbetrachtungen zum Thema 12 1 Macro("LevelMesh") { 2 setparameter("mesh", "prop_coffin_vault01.mesh"); 3 setparameter("prefix", "vault02coffin03"); 4 setparameter("translate", , -2.25, ); 5 setparameter("rotate", 0.0, , 0.0); 6 } Programm 2.1: Beispielcode zur Platzierung eines statischen Meshes im Level Levelerstellung Das Level besteht hierbei aus verschiedenen Meshes, welche einzeln aus Maya exportiert werden, um diese beim Rendering instanziieren zu können und so Ressourcen zu sparen. Das Zusammensetzen des Levels erfolgt wiederum ebenfalls mit Hilfe von Maya, wobei die verwendeten Meshes hierbei nur als Proxyobjekte zur Positionierung und Ausrichtung dienen. Die tatsächliche Verknüpfung mit den bereits exportierten Ogre3d-Meshes erfolgt über custom Attributes 23 in Maya. Bei jedem platzierten Objekt muss von Hand der Pfad zum verwendeten Mesh angegeben werden, was ebenso für weitere Metadaten, wie beispielsweise die verwendete Lightmap, gilt. Die so markierten Objekte werden schließlich, auf Basis ihres type-attributes, in Scriptaufrufe mit den entsprechenden Parametern übersetzt (Prog. 2.1). Neben der Platzierung müssen für das Beispielobjekt also 3 zusätzliche Attribute von Hand erstellt werden: type = LevelMesh: Durch die Existenz des Type-Attributes werden Objekte zum Export markiert, der Wert bestimmt hierbei das zur Erstellung verwendete Makro mesh = prop_coffin_vault01.mesh: Hiermit wird das von der Engine verwendete Ogre3d-Mesh bestimmt prefix = vault02coffin03: Dies ist eine eindeutige ID der Instanz und wird zur Bestimmung der verwendeten Lightmap benötigt. Da diese wiederum auch in den, von Hand zu erstellenden, Material-Definitionen verwendet wird, sollte sie zur besseren Übersicht und Wartbarkeit einer verständlichen Struktur folgen, und kann somit ebenfalls nicht automatisch generiert werden. Die übrigen Parameter, translate und rotate, werden vom Exportscript aus den Transformationsdaten des jeweiligen Objektes ausgelesen. 23 Beliebige Eigenschaften (Integer, Float, Boolean, String, Vector und Enum), die Objekten zugewiesen werden können

22 2. Vorbetrachtungen zum Thema 13 1 Macro("LevelPhysics") { 2 setparameter("form", "cube"); 3 setparameter("debug", 0); 4 setparameter("translate", -3.0, -0.15, -21.0); 5 setparameter("rotate", 0.0, 0.0, 0.0); 6 setparameter("scale", 3.0, 0.3, 3.0); 7 } Programm 2.2: Scriptaufruf für die Platzierung eines Kollisionsobjektes Analog dazu erfolgt auch die Positionierung von Kollisionsobjekten. Da hierbei lediglich Box-Shapes (also Quader) Verwendung finden, ist es möglich, diese mit Hilfe von Würfeln zu platzieren, wobei die Skalierung selbiger die Größe der Kollisionskörper bestimmt(prog. 2.2). Der Beispielcode beinhaltet darüber hinaus noch weitere Parameter, welche jedoch global gesetzt werden: form = cube: Das verwendete Makro unterstützt auch die Erstellung anderer Formen, wie beispielsweise sphere, was jedoch im genannten Projekt nicht zur Anwendung kommt. Somit kann der Parameter global vom Exporter gesetzt werden und es wird kein weiteres Custom- Attribute benötigt debug = 0: Der Exporter unterstützt die Erstellung einer Debugversion des Levels. Bei einem Wert von 1 würden vom Makro zusätzlich grafische Repräsentationen der Kollisionsobjekte erstellt. Diese Vorgehensweise erfordert zwar tatsächlich nur geringen Aufwand seitens der Toolprogrammierung, der Aufwand für den Anwender ist jedoch umso größer. So müssen sämtliche Metadaten von Hand eingetragen werden, was bei Erstellung und Änderungen sehr umständlich ist. Ein viel größeres Problem stellt jedoch die Fehleranfälligkeit dar, da beispielsweise auftretende Tippfehler schwer aufzuspüren sind. Besonders bei Änderungen kommt zudem zum Tragen, dass bei der Vielzahl von bearbeiteten Objekten leicht das ein oder andere vergessen wird. Beim genannten Projekt wurden beispielsweise die Lightmaps erst später hinzugefügt, weshalb, im bereits fertig gestellten Level, zu sämtlichen Meshes das erwähnte prefix-attribut hinzugefügt werden musste Direkte Folgerungen aus den Problemen Ein Großteil dieser Arbeiten und Probleme könnten dabei durch eine entsprechende Asset-Pipeline umgangen werden. Betrachtet man die Entwicklung

23 2. Vorbetrachtungen zum Thema 14 von CaptAncestor für sich, so ließe sich, bereits durch ein besseres Zusammenspiel der verwendeten Tools, eine deutliche Reduzierung des Arbeitsaufwandes erreichen. Könnte beispielsweise der Exporter die referenzierten Meshes als solche erkennen, würde die Angabe des benötigten Ogre3d-Meshes entfallen. Diese könnten beim Levelexport sogar automatisch erstellt werden. Ähnlich verhält es sich mit den, für die Lightmaps benötigten, eindeutigen IDs. Innerhalb einer Maya-Szene ist ohnehin jedes Objekt eindeutig identifizierbar, die manuell zu erstellenden Ogre3d-Materialien erfordern jedoch die einfache Lesbarkeit dieser IDs. Würden die Materialien stattdessen automatisch erstellt, entfiele also auch die hier nötige Arbeit. Gleichzeitig ließe sich der dabei nötige Aufwand zur Toolentwicklung, für ein einziges Projekt, nicht rechtfertigen. Da sämtliche Tools an die gerade verwendete Implementierung der Engine gebunden wären, müssten diese aber bei jeder größeren Änderung, wie beispielsweise einem Austausch der hier verwendeten Ogre3d und PhysX durch die intern entwickelten Systeme CBero beziehungsweise PhysiKCHs, weitreichend überarbeitet werden, was die letztlich angestrebte Reduzierung des Arbeitsaufwandes stark relativieren, beziehungsweise diesen nur verlagern würde.

24 Kapitel 3 Asset-Pipelines Eine Asset-Pipeline ist die Verbindung zwischen Contenterstellung und der Game-Engine selbst. Sie dient zur Abstraktion der erstellten Assets von der konkreten Engine-Implementierung oder Zielplattform und somit primär zur Umwandlung verschiedener Datenformate und der Auslagerung zeitintensiver Offlineberechnungen. Betrachtet man den eigentlichen Produktionsvorgang eines Spieles, zeigt sich aber schnell, dass eine reine Offline-Pipeline, wie sie bereits beschrieben wurde auch Nachteile bringt alle Änderungen müssen die Pipeline durchlaufen, was einen erheblichen Zeitaufwand bedeuten kann. Klassischere Engines wie Source bieten deshalb die Möglichkeit zur Abkürzung der Pipeline, neuere Architekturen verfolgen einen anderen Ansatz: Durch die Leistungsfähigkeit heutiger Computersysteme entfällt zunehmend die Notwendigkeit aufwändigen Preprocessings, was es ermöglicht, die Engine, während des Entwicklungsprozesses, direkt auf die Source-Assets zugreifen zu lassen, womit die Pipeline jedoch nicht gänzlich entfällt. Besonders beim Multi-Platform-Development für Konsolen ist eine Offline-Pipeline kaum zu umgehen und auch für die Release-Version bietet die Asset-Pipeline, neben Möglichkeiten zur Optimierung, auch Schutz vor Manipulationen der Daten durch den Endbenutzer. Aus diesem Grunde soll hier der Schwerpunkt dennoch auf der klassischen Offline-Pipeline liegen, da sich der Aufwand einer direkten Engine-Anbindung, bei entsprechender Konzeption, in einem überschaubaren Rahmen hält. 3.1 Pipeline Anforderungen Grundsätzlich bildet die Asset-Pipeline eine Brücke zwischen der Contenterstellung und dem Laden der Assets durch die Engine. Dass der direkte Export in die benötigten Laufzeitformate kein sinnvoller Weg ist, wurde bereits in Abschnitt 2.2 erläutert. Diese Überbrückung durch die Pipeline dient jedoch allein der technischen Abstraktion, während sie den Workflow tenden- 15

25 3. Asset-Pipelines 16 ziell stört, beziehungsweise verlangsamt. Aus Sicht der Usability besteht die wichtigste Anforderung an die Pipeline deshalb in ihrer Transparenz. Im Idealfall wird sie nicht einmal wahrgenommen, sondern erledigt ihre Aufgaben im Verborgenen. Um eine solche Transparenz zu erreichen, sind vor allem Anfang und Ende der Pipeline von Bedeutung. Der Weg aus der Contenterstellung sollte sich nahtlos in die verwendeten Tools integrieren, die Integration in die Engine darf keinerlei Nacharbeiten erfordern Contenterstellung Am Beginn der Pipeline steht die Erstellung des benötigten Contents. Bei Spielen erstreckt sich dies über unterschiedlichste Disziplinen: 3D-Modellierung, 2D-Grafik, Animation, verschiedene Bereiche der Audioproduktion und Video, welche alle kombiniert und von der Pipeline behandelt werden müssen. Für alle dieser Medientypen stehen jeweils verschiedene, etablierte Standardtools zur Verfügung, während es für ihre Zusammenführung, in der Weise, wie sie für Spiele nötig ist, keine etablierten Lösungen gibt. So kommen in der Film- und Effektindustrie zwar im Wesentlichen die gleichen Medien zum Einsatz, doch wird hier in vorgegebenen Shots gearbeitet und so kann in Rendering, Schnitt, Compositing und Audiomastering alles genau von Hand aufeinander abgestimmt werden. Der große Unterschied bei Spielen besteht darin, dass sie dynamisch vom Spieler abhängen und so während der Produktion keine fixe Gesamtkomposition erstellt werden kann. Vielmehr geschieht das endgültige Zusammenfügen aller Einzelteile während der Laufzeit durch die Engine, was erst durch eine weitere Komponente möglich wird: Metadaten. Diese weisen beispielsweise einen Animationsclip als Walkcycle aus oder kennzeichnen ein 3D-Modell als Türe, welche sich öffnen und schließen lässt und dabei wiederum bestimmte Geräusche von sich gibt. Für all diese Aufgaben gibt es weder Standardformate noch -tools, vielmehr werden diese Daten oft, wie dies auch bei der Source-Engine(Abschnitt 2.2.2) teilweise der Fall ist, in manuell erstellten Textdateien beschrieben, oder verschiedene Namenskonventionen dienen zur logischen Zuordnung einzelner Assets, was aber unflexibel ist und leicht zu Unübersichtlichkeit führen kann. Beiden dieser Ansätze ist gemeinsam, dass sie anfällig gegen Flüchtigkeitsfehler sind und sich kaum für komplexe Beschreibungen eignen. Abhilfe schaffen hier enginespezifische Spezialanwendungen, wobei diese, normalerweise grafischen, Tools, sehr vielseitig ausfallen und hier nur einige Beispiele genannt werden sollen: Material-Editoren dienen neben der Erstellung von Shadern auch der Festlegung physikalischer Materialeigenschaften wie Reibung, Aufprallgeräuschen oder dem Schadensverhalten wie der Darstellung von Oberflächenschäden, Partikeleffekten oder sogar dynamischem Bruchverhal-

26 3. Asset-Pipelines 17 ten. Mit Animationseditoren werden zuvor erstellte Animationsclips inhaltlich beschrieben, damit sie von der Engine, zur Laufzeit, im richtigen Kontext verwendet werden können (Idle, Walk, Run, Attack etc.), aber auch die Festlegung möglicher Übergänge und Überlagerungen zwischen den einzelnen Clips erfolgt hier. Leveleditoren stellen einen Grenzfall dar. Zwar dienen diese oft der Erzeugung von Levelgeometrie, der Generierung von Navigationsdaten für die KI oder ähnlichem. Eine zentrale Aufgabe ist jedoch die logische und inhaltliche Verknüpfung zuvor erstellter Assets. Ein genereller Trend besteht darin, all diese Funktionen in ein einziges Tool, zu integrieren. Bei aktuellen Engines (und ihren Toolsets) zeichnen sich dazu zwei unterschiedliche Richtungen ab. Entweder werden immer mehr Funktionen in den Leveleditor integriert, wie dies bei der aktuellen Unreal- Engine 1 der Fall ist oder die Engine selbst wird um einen Tool-Modus erweitert. Beispiele hierfür sind der Particleeditor der Source-Engine oder id Tech4 2, bei der sämtliche Tools, einschließlich des Leveleditors in die Engine integriert sind. Handelt es sich bei dieser Integration um eine Weiterentwicklung bestehender Systeme und waren die verschiedenen Funktionalitäten vorher bereits in Einzelanwendungen umgesetzt, tritt mitunter ein Problem zu Tage: Oft werden die von solchen Tools verwendeten Datenstrukturen ad-hoc auf das konkrete Problem zugeschnitten und sind, obwohl sehr ähnlich, untereinander nicht kompatibel, womit, bei einer Zusammenführung der Programme, lediglich das Frontend vereinheitlicht werden kann, während die verschiedenen Backends erhalten bleiben und somit auch weiterhin gewartet werden müssen. Bei einer Neukonzeption bietet sich dagegen die Gelegenheit, alle benötigten Arten von Metadaten einheitlich zu strukturieren und damit ein Basissystem zu entwickeln, welches modular um die jeweils benötigten Funktionen zur Bearbeitung und Interpretation der verschiedenen Daten erweitert werden kann Anbindung des Contents Bei der Engineanbindung der Assets können, je nach Anwendungsfall, verschiedene Aspekte im Vordergrund stehen: Ladezeiten, Dateigrößen, Streaming, Veränderbarkeit des Contents 3 etc. 1 aktuell in Version 3 verfügbar, mehr Informationen unter 2 Aktuelle Engine von id Software, mehr Informationen unter 3 Soll custom Content unterstützt werden, muss sich dieser leicht einbinden lassen; zur Erschwerung von Cheats, sollten die Assets geschützt, oder verschlüsselt sein

27 3. Asset-Pipelines 18 Die Bedeutung dieser Punkte wechselt von Projekt zu Projekt, unterscheidet sich je nach Zielplattform und ändert sich auch während des Entwicklungsprozesses eines Spieles. Deshalb ist es wichtig, die Schnittstelle zwischen Pipeline und Engine möglichst klein und modular zu halten. Die Pipeline selbst, mit allen ihren Verarbeitungsprozessen, arbeitet dabei unabhängig vom letztlich verwendeten Output-Modul und lässt sich auch unter veränderten Anforderungen weiterverwenden. Gleichzeitig erfordern die, zur Enginanbindung benötigten, Module nur einen minimalen Entwicklungsaufwand und lassen sich durch Konfigurationsänderungen austauschen. Die letztliche Implementierung der Engineanbindung ist dabei weitestgehend freigestellt und auch die Unterschiede zwischen Offline- und Online- Pipeline fallen an dieser Stelle nur minimal ins Gewicht. Vielmehr stellt auch eine Echtzeitanbindung lediglich ein, zur Offline-Version alternatives, Output-Modul dar. 3.2 Asset Workflow Ein zentraler Punkt bei der Pipeline-Entwicklung ist die Optimierung des Workflows und dabei vor allem die Vermeidung von Routinearbeiten, welche den kreativen Prozess stören. Dies bezieht sich nicht ausschließlich auf die eigentliche Erstellung von Assets und die Integration selbiger in die Engine, sondern auf die gesamte Strukturierung und Verwaltung des Projektes. Wichtige Aspekte sind dabei der Datenabgleich zwischen den verschiedenen Entwicklern, die Verwaltung des bestehenden Asset-Pools und ein möglichst transparentes Funktionieren der Pipeline Kollaboration Bei der Erstellung des Contents ist wichtig, dass möglichst barrierefrei auf bereits vorhandene Ressourcen zugegriffen werden kann und Änderungen möglichst schnell propagiert werden. Voraussetzung hierfür ist zunächst ein problemloser und verlustfreier Datenaustausch zwischen den verwendeten Programmen, was bei sehr kleinen Teams bereits ausreichen kann. Mit zunehmender Komplexität von Projekten, wird jedoch vielfach parallel an verschiedenen, voneinander abhängigen Assets gearbeitet, was einen gewissen Organisationsaufwand und diszipliniertes Einhalten entsprechender Richtlinien zur Vermeidung von Konflikten mit sich bringt, denn anders als bei der Programmierung gibt es in der Asset-Erstellung kaum Möglichkeiten zum Merging von Daten. Die meist einzige Lösung, um ein paralleles Arbeiten dennoch zu ermöglichen ist eine sehr feine Unterteilung der Assets in einzelne Dateien, welche lediglich referenziert werden. Die Möglichkeiten hierzu unterscheiden sich bei verschiedenen Medien, aber auch Tools, wesentlich: So ist eine solche Referenzierung bei der Verarbeitung großer Datenmengen, wie

28 3. Asset-Pipelines 19 in der Audio- und Videobearbeitung, ohnehin üblich; bei der Bildbearbeitung dagegen kaum möglich. 3D-Anwendungen erfordern hierbei wiederum primär Disziplin, so bieten diese zwar grundsätzlich die Möglichkeit zur Referenzierung externer Daten, wie beispielsweise einzelner Animationsclips, jedoch müssen diese dazu ausdrücklich exportiert werden. Darüber hinaus ist bei der Entwicklung von 3D-Tools derzeit ein genereller Trend zur Verbesserung der Kollaborationsmöglichkeiten zu beobachten. So bietet beispielsweise Maya, seit der aktuellen Version 2009, die Möglichkeit zur Definition von Schnittstellen für komplexe Szenenelemente, sogenannter Asset-Container, deren Inhalt sich dadurch leicht austauschen lässt. Ein interessantes Forschungsprojekt zum Thema stellt COLLADA Collaboration 4 dar, welches die gleichzeitige Bearbeitung einer Maya-Szene von unterschiedlichen Arbeitsplätzen aus ermöglicht, wobei die Synchronisation über einen zentralen Server erfolgt Versionsmanagement Das Versionsmanagement ist ein wichtiger Bestandteil des Entwicklungsprozesses und vereinfacht unter anderem auch die Kollaboration. Versionsverwaltungssysteme protokollieren die Fortschritte des Projektes und halten so den jeweiligen Entwicklungsstand und die entsprechende Version jeder einzelnen benötigten Datei fest. Sie bieten die Möglichkeit, jederzeit, zum Beispiel bei Fehlern, einen vorangegangenen Status wiederherzustellen, und vereinfachen, durch die Protokollierung der an Änderungen beteiligten Benutzer und Kommentare, die Nachverfolgung von Änderungen. So vereinfachen sie die parallele Entwicklung an abhängigen Projektteilen, da die Gründe für möglicherweise entstehende Inkompatibilitäten leichter aufgespürt werden können, als dies sonst der Fall wäre. Auch der gleichzeitige und problematische Zugriff auf die Daten, wie beispielsweise bei einem gemeinsamen Netzwerk- Share, wird vermieden, stattdessen arbeitet jeder Benutzer mit einer eigenen, sogenannten Arbeitskopie der Projektdaten, welche in geeigneten Intervallen mit dem allgemeinen Projektstatus synchronisiert wird. Ein weiterer Vorteil hiervon ist, dass während der Asset-Produktion, häufig zu Testzwecken, erstellte Dateien (zum Beispiel beim Testen verschiedener Rigging-Setups) nicht den gemeinsamen Asset-Pool aufblähen. Vielmehr lassen sich diese lokal erstellen und von der Versionsverwaltung ausnehmen, während sie dennoch beliebige Projektdaten referenzieren können und diese Referenzen keiner weiteren Anpassung bedürfen, falls die Daten doch zum Projekt hinzugefügt werden. Dadurch, dass so nur tatsächlich benötigte As- 4 COLLADA Collaboration ist ein Projekt von Offset Software ( und wurde unter anderem auf der FMX 2009 ( präsentiert. Abgesehen von einen Video ( sind derzeit jedoch keine öffentlichen Referenzen zu finden.

29 3. Asset-Pipelines 20 sets zum Projekt hinzugefügt werden, wird zudem die automatische Verarbeitung durch die Asset-Pipeline vereinfacht: Alle im Versionsmanagement vorhandenen Quelldaten werden kompiliert, womit eine weitere Unterscheidung zwischen, für das Spiel benötigten und lediglich temporären, Daten entfällt Automatisierung und Pipeline Management Die Automatisierung der Pipeline dient in erster Linie dazu, die Verarbeitungsprozesse für den Entwickler transparenter erscheinen zu lassen. Wird also Content zum Projekt hinzugefügt oder geändert, so erfolgt die Kompilierung in die finalen, von der Engine verwendeten Assets ohne weitere Interaktion des Entwicklers. Dieses Konzept ist an das, aus der Softwareentwicklung bekannte, Prinzip der Continuous Integration (siehe auch Abschnitt ) angelehnt und bringt, gegenüber der manuellen Steuerung der Asset-Pipeline, verschiedene Vorteile. Primär wird sichergestellt, dass die für die Engine aufbereiteten Assets stets ein exaktes Abbild der Quellassets darstellen, also vollständig und aktuell sind, wobei sich gleichzeitig Inkonsistenzen im Projekt frühzeitig erkennen lassen, da die Build-Fähigkeit des gesamten Projektes in kurzen und regelmäßigen Abständen überprüft wird. Doch auch der Arbeitsablauf wird von den Verarbeitungsprozessen der Pipeline weniger beeinflusst: Wenn Quellassets einzeln und manuell verarbeitet werden, um die Kompilate anschließend in das Projekt einzupflegen, entstehen mitunter erhebliche Wartezeiten, welche jedoch kaum sinnvoll genutzt werden können, da die Pipeline-Prozesse auf der Workstation des Entwicklers ablaufen und diese auslasten. Werden diese Aufgaben hingegen durch die Automatik an ein dezidiertes Build-System ausgelagert, steht der Arbeitsplatz weiter für produktive Zwecke zur Verfügung. Diese Auslagerung und Automatisierung erfordert, gegenüber einer manuellen Bedienung der Asset-Pipeline, allerdings auch ein komplexeres System zum Management verschiedener Konfigurationen. Diese können, bei einer manuell angestoßenen Pipeline, für jedes Asset individuell und den Erfordernissen der aktuellen Entwicklungsphase entsprechend angepasst oder ausgewählt werden, was schnell deutlich wird wenn man die sehr unterschiedlichen Stadien betrachtet, welche beispielsweise ein Level während seiner Entwicklung durchläuft. In der Layout-Phase wird die Grundstruktur festgelegt und alle für das Game-Play relevanten Elemente platziert, später erfolgt die Einbindung der letztlich verwendeten Assets, wie 3D-Meshes und Texturen, dann die Beleuchtung und schließlich noch finale Anpassungen und Optimierungen. Während all dieser Phasen müssen unterschiedliche Aspekte getestet werden, während andere vollkommen nebensächlich sind und beim Kompilieren nur unnötig Rechenzeit in Anspruch nehmen würden.

30 3. Asset-Pipelines 21 Während der Layout-Phase müssen von der Pipeline nur rein funktionale Daten, wie beispielsweise Navigationsmeshes für NPCs 5 generiert werden, eine Optimierung der hierbei ohnehin nur temporären 3D-Meshes oder die Vorberechnung von Beleuchtungsdaten wäre dagegen ein unnötiger Aufwand an Rechenzeit. In den folgenden Design-Phasen ist die spielerische Funktionalität des Levels wiederum nebensächlich, vielmehr werden hier die gestalterisch relevanten Daten benötigt. 3D-Meshes müssen in ihrer endgültigen Form vorliegen (inklusive eventuell vorberechneter LOD 6 -Stufen oder ähnlichem), um diese unter gestalterischen Aspekten beurteilen zu können. Lightmaps müssen in finaler Qualität und Auflösung berechnet werden und auch vom Sound-System benötigte Daten sind hier erforderlich. Die Optimierungsphase bietet die wenigsten Möglichkeiten zur Einsparung von Vorberechnungen, da hier alle Daten, zumindest aus technischer Sicht, final sein müssen, das heißt: vollständiges Gameplay, finale 3D-Daten und so weiter. Doch bei genauer Betrachtung finden sich auch hier kleine Einsparungsmöglichkeiten. Texturen müssen zwar grundsätzlich in ihrer endgültigen Auflösung und Kompression vorliegen, beziehungsweise werden diese im Zuge der Optimierungen noch angepasst. Generierte Texturen wie Normal- oder Lightmaps können jedoch in schlechterer Qualität berechnet 7 werden, als dies für das fertige Produkt vorgesehen ist. Leider lassen sich diese verschiedenen Konfigurationen nicht in eine einfache Hierarchie von Qualitätsstufen einordnen. Das macht ein entsprechendes System zur Verwaltung und vor allem Anwendung selbiger, ungleich komplizierter, als dies bei der Softwareentwicklung ist, wo es außer Release- und Debug-Build selten weitere Konfigurationen gibt. 3.3 Analogien zu klassischen Pipelines Es wurden bereits verschiedene Vergleiche zwischen Asset-Pipelines und anderen Disziplinen angestellt, welche nun, besonders im Hinblick auf die mögliche Adaption bestehender und erprobter Konzepte, genauer ausgeführt und ergänzt werden sollen. 5 Non-Player Character, KI-gesteuerte Spielfiguren 6 Level Of Detail, Objekte werden in mit zunehmender Entfernung zur Kamera durch vereinfachte Versionen ersetzt (geringerer Poly-Count, weniger Joints, einfachere Shader etc.) 7 Raytracing-Einstellungen, Anti-Aliasing und ähnliches

31 3. Asset-Pipelines D-Animation Die vordergründigsten Ähnlichkeiten der Asset-Produktion und -Verarbeitung finden sich zunächst mit der klassischen 3D-Animation aus den Bereichen Film uns Visual-Effects. Hier besteht eine große Schnittmenge zwischen den verwendeten Daten und Tools, wodurch sich die Arbeitsabläufe zumindest bei der Erstellung des Contents sehr ähneln und sich im Wesentlichen nur durch verschiedene Texturauflösungen, Polygonzahlen von 3D-Modellen und dergleichen unterscheiden Kollaboration Im Animationsbereich bieten sich wenige Standardlösungen zur einfacheren Zusammenarbeit in größeren Teams und abgesehen von proprietären Eigenentwicklungen großer Studios, werden entsprechende Features erst in jüngster Zeit verstärkt von den üblichen DCC-Tools unterstützt. Dabei fallen die meisten Ansätze zur Kollaboration ohnehin eher in den Bereich von Best Practices und lassen sich nur durch die disziplinierte Einhaltung entsprechender Konventionen durchsetzen. Diese beginnen bei der normierten Benennung von Dateien, Nodes und Attributen, bedeuten aber in erster Linie eine möglichst atomare Aufteilung von Assets und die Referenzierung dieser, an Stelle des Importes in große Masterfiles. Diese, von den meisten etablierten DCC-Tools gebotenen Möglichkeiten der Szenenaufteilung, bedeuten jedoch einen zusätzlichen Aufwand und sind meist schlecht in den eigentlichen Workflow integriert, was wenig zu ihrer Anwendung motiviert. Zudem waren diese Funktionen, zumindest im Fall von Autodesk Maya (für andere Packages wie Softimage 8 oder 3ds Max kann hier nicht auf Erfahrungswerte zurückgegriffen werden), in der Vergangenheit sehr fehleranfällig und führten immer wieder zu Problemen mit kaum identifizierbaren Ursachen. Seit Kurzem rückt die Kollaboration jedoch verstärkt in den Mittelpunkt der Entwicklung von DCC-Tools und im Falle von Maya zeigt sich dies, neben der stabileren Szenenreferenzierung, besonders im Asset-System von Maya 2009, welches eine logische Zusammenfassung von Teilen einer Szene zu sogenannten Asset-Containern ermöglicht. Diese sammeln, darüber hinaus, alle außerhalb des Containers relevanten Attribute in einer festen Schnittstelle, wodurch sich der Inhalt leicht austauschen und somit parallel entwickeln lässt. Gleichzeitig lassen sich diese Schnittstellen als Templates abspeichern und erleichtern so die Umsetzung verschiedener Variationen, technisch praktisch gleicher Objekte, wie diese in Spielen sehr häufig vorkommen, beispielsweise Türen oder Kisten, die sich öffnen und schließen lassen oder komplette Character-Setups. 8

32 3. Asset-Pipelines Renderfarmen Eine, auf die Verarbeitung in der Asset-Pipeline selbst bezogene Analogie aus dem Animationsbereich, stellen Renderfarmen dar. Diese dienen der Auslagerung der aufwändigen Berechnungen von Animationssequenzen, wobei fertig animierte 3D-Szenen an einen zentralen Server übergeben werden, welcher diese sogenannten Renderjobs zur Abarbeitung kontinuierlich an eine Vielzahl von Rendernodes weiterleitet. Dabei gibt es zwei Methoden zur Aufteilung der einzelnen Renderjobs. Entweder jeder Renderknoten berechnet jeweils ein Einzelbild einer Sequenz, oder mehrere Knoten rechnen parallel am gleichen Bild. Die erste Alternative ist sehr viel einfacher umzusetzen und benötigt keine spezielle Unterstützung durch den verwendeten Renderer. Zudem ist der Ausfall einzelner Rendernodes weniger problematisch, da im Fehlerfall nur die wenigen, vom entsprechenden Knoten verarbeiteten Einzelbilder, erneut berechnet werden müssen, anstatt aller Frames, bei denen der betroffene Node nur zu einem kleinen Teil beteiligt war. Trotz dieser Vorteile ist diese Methode jedoch nur zur Berechnung von Sequenzen geeignet. Beim Rendering von Einzelbildern, wie dies auch in der Spieleentwicklung mit Light-, Occlusion- oder Normalmaps der Fall ist, muss also auf die letztere der beiden Möglichkeiten zurückgegriffen werden. Damit ist impliziert, dass sich bereits Standardlösungen für Renderfarmen, wie diese zu den meisten 3D-Grafikprogrammen angeboten werden, direkt in die Game-Asset-Pipeline integrieren lassen. Darüber hinaus sind vergleichbare Techniken, zur parallelen Verarbeitung auf vernetzten Rechenknoten, jedoch auch für Pipeline-Tools zur Abarbeitung anderer rechenintensiver Prozesse, einzuplanen Verwendbare Technologien aus der Softwareentwicklung Im Gegensatz zur Animation, erscheinen Vergleiche zwischen der reinen Softwareentwicklung und Asset-Pipelines für Spiele weniger offensichtlich und naheliegend. Tatsächlich lassen sich jedoch viele Konzepte direkt oder nur leicht modifiziert übertragen Cross-Platform Development Die wichtigsten Gemeinsamkeiten und gleichzeitig einer der Hauptgründe für eine umfangreiche Asset-Pipeline finden sich im Cross-Platform-Development oder allgemeiner in verschiedenen und wechselnden Zielplattformen. Dies schließt auch Änderungen und Weiterentwicklungen an der Engine selbst ein. Assets werden zwar durch die zunehmende Rechenleistung auch bei Echtzeitanwendungen immer unabhängiger von der verwendeten Architektur und Engine. Assets, die in einem höher abstrahierten Format vorlie-

33 3. Asset-Pipelines 24 1 #ifdef WIN32 2 # include <windows.h> 3 #else 4 # include <unistd.h> 5 #endif Programm 3.1: Typische Präprozessoranweisungen zur Sicherstellung der Kompatibilität mit verschiedenen Plattformen gen, werden während des Ladeprozesses in die entsprechenden Laufzeitformate umgesetzt. Zum einen zeigt sich dieser Fortschritt bei Consolen jedoch in weit geringerem Maße als beim PC, zum anderen beschränken sich plattformspezifische Anpassungen nicht allein auf die hardwarenahe Strukturierung der Daten sondern auch auf Aspekte wie beispielsweise die unterschiedliche Interpretation von Gamma-Kurven [9]. Solche notwendigen und nicht von der Performance abhängigen Plattformanpassungen bieten auch in Zeiten des Next-Gen-Development noch ein schlagendes Argument für, ansonsten oftmals als altmodisch oder umständlich betrachtete, Offline-Pipelines. Die Analogie zum Softwaredevelopment besteht in der Kompilierung der immer gleichen Quelldaten mit verschiedenen, festgelegten Einstellungen. Durch bedingte Übersetzungsanweisungen lassen sich zudem gezielte Anpassungen vornehmen. Analog zu einer Präprozessoranweisung, wie Prog. 3.1, kann es beispielsweise aufgrund von Speicherbeschränkungen sinnvoll sein, einzelne Texturen für bestimmte Plattformen, wie Consolen, in geringerer Auflösung zu exportieren, dies jedoch nicht als globale Regel, also für alle Texturen festzulegen Versionsmanagement Versionsmanagement ist in der Software- und auch Spieleentwicklung gang und gäbe. Es bietet sich, über Game-Asset-Pipelines hinaus, aber für jede Form der Contentproduktion an, wo es jedoch nur selten zur Anwendung kommt. Während sich verbreitete Tools wie Subversion 9, Perforce 10 oder Alienbrain 11, entgegen der weit verbreiteten Meinung, grundsätzlich durchaus gut zur Verwaltung von Content eignen, muss beim Umgang mit Assets jedoch auf verschiedene Unterschiede zu Quelltext-Dateien geachtet werden. Da die Daten meist binär, oder zumindest nicht in menschenlesbarer Form vorliegen, ist ein Merging verschiedener Versionen, wie dies bei Sour- 9 Subversion ist eine verbreitete Versionsverwaltungssoftware unter Open-Source Lizenz ( 10 Perforce ist ein kommerzielles System zur Versionsverwaltung ( 11 Alienbrain ist eine kommerzielle Versionsverwaltungssoftware, welche spezielle Features für den Umgang mit Assets bereitstellt (

34 3. Asset-Pipelines 25 cecode relativ einfach ist, praktisch unmöglich. Stattdessen sollten Versionskonflikte durch die sorgfältige Anwendungen der entsprechenden Sperrmechanismen, wie zum Beispiel svn lock, strikt vermieden werden. Die oft als problematisch betrachteten, großen Datenmengen bei Assets, lassen sich dagegen sinnvoll auf verschiedene Repositories aufteilen. Diese Daten sind meist das Ergebnis von Rendering-, Export- oder Kompilationsprozessen. Sie sollten, wegen des zur Erstellung notwendigen Aufwandes an Rechenleistung, zwar zentral vorgehalten werden. Da sie leicht wiederhergestellt werden können, bedürfen sie jedoch nur einer relativ geringen Datensicherheit und können in ein verhältnismäßig schwach gesichertes Output-Repository ausgelagert werden, um das gut abgesicherte Projekt-Repository nicht unnötig aufzublähen. Die Daten aus dem Output-Repository lassen sich dabei leicht, durch Funktionen wie svn:externals, in die Verzeichnisstruktur des Projekt-Repositories eingliedern. Dieses Vorgehen bietet sich darüber hinaus auch sehr in der Softwareentwicklung an, zur konfigurationsfreien Einbindung von Abhängigkeiten und auch Binaries, wie dies Julien Koenen in seinem Vortrag auf der GDC Europe 2009 überzeugend dargelegt hat [8] Continuous Integration Continuous Integration ist eine Form der Softwareentwicklung, bei der durch fortwährendes, automatisches Kompilieren und Testen zu jedem Zeitpunkt eine weitgehende Fehlerfreiheit des Projektes sichergestellt werden soll. Im Bezug auf die Asset-Pipeline, sind hierbei vor allem die hierzu verwendeten Buildsysteme von Bedeutung, welche, bei Änderungen im Repository, automatisch verschiedene Prozesse starten können. Im Normalfall ist dies das Kompilieren des Sourcecodes und die Abarbeitung verschiedener Tests. Prinzipiell lassen sich aber beliebige Anwendungen ausführen, also auch die Pipeline-Verarbeitung von Assets. Auch, wenn solche Systeme, wie zum Beispiel CruiseControl 12 oder Apache Continuum 13, nicht bei der Codeentwicklung angewandt werden, bietet ihre Adaption für die Asset-Pipeline den Vorteil, dass, für die Automatisierung und Auslagerung der Pipeline-Prozesse, auf fertige und stabile Systeme zurückgegriffen werden kann. Diese Systeme erfüllen alle nötigen Anforderungen, wie die Überwachung des Repositories auf Änderungen, Remotekonfiguration und Benachrichtigungen im Fehler- wie auch Erfolgsfall etc. 12 CruiseControl ist ein freies System zur Umsetzung kontinuierlicher Entwicklungsprozesse ( 13 Continuous Integration Server unter der Apache License 2.0 (

35 3. Asset-Pipelines Release Packaging Während sich das Release Packaging, im Softwarebereich, primär auf die Erstellung von Installern zum Deployment beschränkt und somit während des Entwicklungsprozesses bestenfalls zu Testzwecken durchgeführt wird, hat es bei der Verarbeitung von Assets, auch während der Entwicklung, eine wichtige Bedeutung, welche sich in erster Linie auf die Erstellung von Ressourcenpaketen bezieht. Selbst wenn sich die Iterationszeiten dadurch verlängern, ist es, besonders im Hinblick auf Ladezeiten und das Sreaming von Daten, wichtig, auch während der Entwicklung Laufzeitbedingungen zu schaffen, welche denen der finalen Anwendung möglichst nahe kommen. Die verwendeten Mechanismen entsprechen dabei jenen der Softwareentwicklung und lassen sich problemlos in automatische Build-Systeme, wie sie zur Continuous Integration angewandt werden, integrieren. Abweichend ist dabei lediglich die Regelmäßigkeit des Packens. Beim Streaming sind, besonders bei Consolenentwicklungen, oft umfangreiche und langwierige Optimierungen, zur Anordnung der Daten innerhalb des Paketes, erforderlich, was ein Packaging auf Grund kleiner Änderungen impraktikabel macht. Hier sollte auf regelmäßige, zum Beispiel nächtliche, Rebuilds zurückgegriffen werden, wobei sich Änderungen schnell, durch das Überschreiben der jeweiligen Daten innerhalb des Ressourcenpaketes, durch externe Dateien testen lassen Game Asset-Pipelines als Mischform Zusammenfassend, lässt sich festhalten, dass Asset-Pipelines für Spiele eine komplexe Verknüpfung von Konzepten aus Contenterstellung und Softwareentwicklung sind. Bei ihrer Entwicklung und Umsetzung, sollte vor allem einem Punkt, Rechnung getragen werden. Sie werden in erster Linie von Artists verwendet und somit muss das wichtigste Ziel darin bestehen, benötigte Tools und Pipeline-Abläufe möglichst nahtlos in bekannte und etablierte Arbeitsweisen und -abläufe zu integrieren. Dies wird besonders im Umfeld von FH-Projekten, aber auch im professionellen Bereich, allzu gerne unterschlagen, sollte jedoch bereits in die grundlegende Konzeption von Tools als, auch der Engine selbst, einfließen. Anleihen aus dem, für Toolprogrammierer oftmals wenig bekannten, Gebiet der Content-Erstellung liegen also größtenteils in den Bereichen der Bedienung, Verständlichkeit und allgemeinen Usability. Viele Möglichkeiten der Implementierung lassen sich dagegen direkt, oder mit geringeren Anpassungen, aus etablierten Systemen der Softwareentwicklung übernehmen.

36 Kapitel 4 Konzeption Nach der Darlegung der verschiedenen Grundlagen und der Beschreibung der Funktionsweisen einer Asset-Pipeline für Spiele, stellt sich nun die Aufgabe ihrer Konzeption. Wie bereits festgestellt, bietet sich durch die heute vorhandene Rechenleistung, neben der klassischen Offline-Pipeline mit aufwändigem Preprocessing, auch die Möglichkeit zu einer Online-Pipeline mit direktem Bridging zwischen Editoren und Engine. Die Grundlagen sind dabei jedoch in beiden Fällen gleich oder sehr ähnlich, wodurch sich eine Offline- Pipeline bei entsprechender Konzeption problemlos um eine Echtzeitanbindung erweitern lässt. Da dies jedoch einen weitaus größeren Entwicklungsaufwand und tiefgreifende Integration mit verwendeter Drittsoftware erfordert, soll hier in erster Linie auf die klassische Offline-Pipeline eingegangen werden, zumal, besonders im Hinblick auf die Verwendbarkeit von Cogaen, die schnelle Umsetzbarkeit der grundlegenden Pipeline-Funktionen im Vordergrund steht. 4.1 Wahl von Zwischenformaten Bei beiden Formen der Pipeline kommen verschiedene Arten von Zwischenformaten zum Einsatz. Für viele Bereiche stehen etablierte (Industrie-)Standards zur Verfügung, welche jeweils verschiedene Vor- und Nachteile bieten. Einige dieser Nachteile, wie die Verlustbehaftung vieler Kompressionen, sind offensichtlich, während andere sich erst in der praktischen Anwendung, durch nicht einheitliches Verhalten von Im- und Exportern, zeigen, einem Hauptgrund für die etwas detailliertere Betrachtung und Gegenüberstellung verschiedener Formate an dieser Stelle Verschiedene Medien Da die Spieleentwicklung praktisch alle Disziplinen der digitalen Content- Erstellung abdeckt, soll hier keine vollständige Gegenüberstellung, aller in 27

37 4. Konzeption 28 Betracht kommenden Datenformate, sämtlicher Teilbereiche, erfolgen. Vielmehr sollen die bekanntesten Möglichkeiten verglichen und, besonders die Probleme mit teilweise oft eingesetzten Formaten, angesprochen werden. Darüber hinaus bezieht sich die folgende Gegenüberstellung in erster Linie auf die praktische Anwendbarkeit der unterschiedlichen Lösungen und begründet sich in erster Linie auf Erfahrungen in verschiedenen Projekten. Für weiterführende Informationen, sei an dieser Stelle jedoch Ben Carters The Game Asset Pipeline [3] erwähnt Grafik Grafik stellt einen grundsätzlich weiten Begriff dar, soll an dieser Stelle jedoch auf 2D-Rastergrafiken beschränkt werden. Diese finden in der Spieleentwicklung verschiedene Anwendungsbereiche: zum Beispiel als Texturen auf 3D-Objekten, Sprites von Partikelsystemen, im User-Interface oder als direkte Szenenelemente in 2D-Spielen. Da es sich hierbei um ein sehr weit verbreitetes und in verschiedensten Formen verwendetes Medium handelt, existiert eine Vielzahl mehr oder weniger bekannter Formate, von denen sich jedoch nur wenige zur Anwendung in Asset-Pipelines eignen. Viele, wie zum Beispiel JPEG, scheiden wegen ihrer verlustbehafteten Kompression grundsätzlich aus. Auch verlustfreie Kompressionen, wie bei PNG, erweisen sich jedoch für ein Transfer-Format in Pipelines wenig geeignet. Sie sind schlecht mit der Funktionsweise der meisten Versionskontrollsysteme (der Protokollierung von Änderungen) zu vereinbaren und der geringere Speicherverbrauch wird durch die Größe der Changesets stark relativiert. Andere, bei Animation und Compositing eingesetzte Formate, wie das von Maya bevorzugte IFF, SGI oder ähnliche, eignen sich, auf Grund ihres geringen Verbreitungsgrades und der damit eingeschränkten Unterstützung durch verschiedene Tools, nur bedingt. Eine sehr gute Lösung scheint, zunächst, der TIFF -Container darzustellen. Das Format bietet, mit praktisch beliebigen Bittiefen, von 8 Bit Paletten bis hin zu 32 Bit Float für HDR-Texturen, Alphakanälen etc., alle erdenklichen Optionen. Zudem bietet es die Möglichkeit zur Einbettung beliebiger Metataten: beispielsweise die gewünschte Kompressionsart der finalen Texturen, benötigte Mipmaps, die Art des Filterings und so weiter. Gerade in diesen, fast unbegrenzten Möglichkeiten, steckt jedoch auch die Problematik dieses Formates: Die Exportoptionen verschiedener Tools lassen sich selten eindeutig auf konkrete Formateigenschaften übertragen, wodurch es in der Praxis, bei der Verwendung verschiedener Programme, insbesondere unterschiedlicher Hersteller, immer wieder zu Inkompatibilitäten kommt. Crytek 1 umgeht dieses Problem, indem eigene Im- und Exporter für das TIFF -Format verwendet werden, eine Lösung die zwar sehr komfortabel 1 Deutscher Spieleentwickler (

38 4. Konzeption 29 ist, zumal beispielsweise der verwendete Photoshop-Exporter verschiedene Vorschaufunktionen für die Kompression und ähnliches bietet, andererseits, durch die nötige Eigenentwicklung der Exporter, einen nicht unerheblichen Mehraufwand mit sich bringt. Die krasse Alternative dazu wird mit Valves Source-Engine (siehe Abschnitt 2.2.2) verfolgt. Sie besteht in der Verwendung verschiedener, möglichst einfacher und damit durchwegs eindeutig behandelter Formate wie TGA. Dieses bietet zwar nur RGB oder RGBA mit 8 Bit pro Kanal, deckt damit aber die allermeisten Anwendungsfälle in der heutigen Spieleentwicklung ab. Lediglich für HDR-Skyboxes benötigt Valve, mit PFM 2, ein weiteres Bildformat in seiner Pipeline, während die zugehörigen Metainformationen in, der jeweiligen Textur entsprechend benannten, Textdateien festgehalten werden. Eine solche, minimalistische Herangehensweise, erscheint für die erste Implementierung sehr geeignet. Sie bedarf nur eines sehr geringen Aufwandes und bringt für den Workflow nur geringe Nachteile. Auch bei einer Umstellung auf ein beispielsweise TIFF -basiertes System, wie bei der CryEngine 3, müsste nur sehr wenig Arbeit verworfen werden Sound Im Soundbereich stellen sich sehr wenige Optionen für Transferformate. Da Kompressionsverluste an dieser Stelle strikt zu vermeiden sind und auch verlustfreie Kompressionen, wie beispielsweise FLAC 4, wegen der relativ geringen Datenmengen bei Spielen, durch den zur Kodierung nötigen Zeitaufwand, mehr Nach- als Vorteile bringen, beschränkt sich die Auswahl im Wesentlichen auf Container für unkomprimierte PCM-Daten. Als bekannteste und am weitesten verbreitete Formate sind hier WAV und AIFF zu nennen, welche sich, in ihrer Eignung und der Unterstützung durch gängige Tools, kaum unterscheiden. Von diesen beiden hat WAV, auf den in der Spieleentwicklung hauptsächlich eingesetzten Windows-Systemen, eine sehr viel höhere Verbreitung und genießt im Spielebereich deshalb meist den Vorzug. Auch bei der Neukonzeption einer Pipeline spricht nichts gegen WAV, da sich AIFF kaum davon unterscheidet und keinerlei Vorteile bietet Metadaten Die bereits mehrfach angesprochenen und in der Spieleentwicklung extrem wichtigen Metadaten, werden in verschiedensten Formen festgehalten. Mitunter werden diese, wie bei der genannten TIFF -Implementierung von Cry- 2 Portable FloatMap, eine kurze Übersicht des Formates findet sich unter 3 Von Crytek entwickelte Game Engine ( 4 Free Lossless Audio Codec (

39 4. Konzeption 30 tek, direkt in die jeweiligen Dateien integriert. Da dies bei den meisten Standardformaten jedoch nur in sehr geringem Umfang möglich ist, kommt eine Vielzahl von zusätzlichen Dateien zum Einsatz, von denen INI -Files, Excel- Sheets und XML nur eine kleine Auswahl darstellen. Das Hauptproblem bei diesen zusätzlichen Metadateien stellt die nicht immer gewährleistete Synchronität mit den Daten dar, da sie bei Änderungen manuell aktualisiert oder durch speziell angepasste Exporter parallel angepasst werden müssten. Deshalb sind eingebettete Metadaten grundsätzlich vorzuziehen D Einen vergleichsweise problematischen Bereich stellen 3D-Daten dar, da hier kaum geeignete Formate zur Auswahl stehen. Die meisten sind proprietäre Formate und wurden zudem nie zum Austausch zwischen verschiedenen Programmen entwickelt, sondern sind, wie zum Beispiel 3DS 5 oder OBJ 6, sehr alte, native Formate früherer DCC-Tools. Diese wurden im Laufe der Zeit öffentlich spezifiziert oder von verschiedenen anderen Tools nachimplementiert, um zumindest einen grundlegenden Datenaustausch zu ermöglichen. Eine wirklich weitgehende Unterstützung hat sich dabei jedoch nur für OBJ entwickelt. 3DS lässt sich dagegen, beispielsweise mit Maya, auch mit Zusatztools, nur importieren. Viele andere Implementierungen unterstützen darüber hinaus nur triangulierte 3DS-Daten. Im Gegensatz zu diesen Formaten, für rein statische Objekte, stellt FBX 7, welches ursprünglich für die Motion-Capture- und Animationssoftware FiLMBOX (heute MotionBuilder 8 ) entwickelt wurde, eine Ausnahme dar. Es unterstützt neben Geometrie- vor allem auch Animationsdaten. Zudem wurde es von Autodesk kontinuierlich zum Austauschformat zwischen verschiedenen Programmen weiterentwickelt und wird heute von vielen Tools unterstützt. Der Hauptnachteil von FBX besteht darin, dass das proprietäre Format selbst undokumentiert ist und nur über das von Autodesk angebotene C++ SDK angebunden werden kann, womit eine FBX -basierte Pipeline von Autodesks Updatezyklen abhängig ist. Dieses Fehlen von wirklich universellen Austauschformaten für 3D-Daten führte zur Entwicklung von COLLADA 9, welches von der Khronos Group 10, im Januar 2006, als offizieller Standard übernommen wurde (nach [1, S.IX]). Dieses offene, XML-basierte Format, wurde von Beginn an, als Austauschund besonders als Pipelineformat für Spiele, konzipiert und bietet umfangreiche Unterstützung für Polygonbasierte Szenen, Animationen, Shader und 5 3D Studio File Format, Meshformat von 3ds Max 6 3D Objekt-Format, ursprünglich von Wavefront Technologies entwickelt Motion-Capture und Animationssoftware der Firma Autodesk ( 9 Mehr Informationen unter

40 4. Konzeption 31 Physiksimulation. Ein weiterer Vorteil ist die Möglichkeit, das Format um beliebige Features, wie applikationsspezifische Zusatzinformationen oder Metadaten, zu erweitern. Diese können, ohne großen Aufwand, in die verfügbaren Open-Source Im- und Exporter integriert werden COLLADA als zentrales Format Insgesamt stellt COLLADA nicht nur für 3D-Daten eine sehr gute Lösung dar, sondern kann durch seine Erweiterbarkeit auch zur Verknüpfung sämtlicher Asses dienen und beispielsweise als Levelformat verwendet werden COLLADA ist standardisiert und Open-Source Eine wichtige Grundlage für solche Erweiterungen ist, neben der expliziten Unterstützung durch das Format, dass COLLADA eine frei zugängliche und standardisierte Spezifikation zu Grunde liegt. Anders als zum Beispiel bei FBX, unterliegen Eigenentwicklungen somit nicht der Gefahr, durch unvorhergesehene Änderungen inkompatibel zu werden, sondern sie lassen sich auf Basis einer konkreten Version umsetzen und im Bedarfsfall auf neuere Revisionen portieren. Ein Hauptvorteil besteht darin, dass sich COLLADA DOM 11, die zentrale Library zum Umgang mit dem Format, durch einen frei zugänglichen Code-Generator aus dem COLLADA Schema 12 erzeugen lässt. Dies ermöglicht es, Erweiterungen und Anpassungen einfach auf Basis des Schemas vorzunehmen, wodurch sich diese, praktisch nahtlos, in das Format integrieren. Durch Merging des Schemas lassen sich Änderungen zudem sehr einfach auf neue Versionen portieren. Auch die sonstigen, relevanten Tools, wie die Pipeline Anwendung COLLADA Refinery 13 und Translator-Plug-Ins, sind im Sourcecode erhältlich, was insbesondere bei den Exportern wichtig ist. Durch deren Quellenverfügbarkeit wird einerseits ermöglicht, die benötigten Anpassungen des Formates vorzunehmen, ohne die Exporter vollständig neu zu schreiben, andererseits können auch Daten aus anderen Plug-Ins, welche vom verwendeten DCC-Tool nicht nativ unterstützt werden, berücksichtigt werden Geeigneter und vielseitiger Aufbau Die Eignung von COLLADA zur zentralen Verknüpfung sämtlicher Asset- Daten, lässt sich jedoch vor allem auf den Aufbau des Formates zurückführen, welches vielseitige Möglichkeiten zur Referenzierung und Instanzi Erhältlich unter beziehungsweise 13 Eine kurze Übersicht über COLLADA Refinery findet sich unter

41 4. Konzeption <library_visual_scenes> 3 <visual_scene id="visualscenenode" name="example"> </visual_scene> 6 </library_visual_scenes> <scene> 9 <instance_visual_scene url="#visualscenenode"/> 10 </scene> Programm 4.1: Beispiel für die Unterscheidung zwischen Libraries und Szene im COLLADA-Format ierung von Daten ermöglicht. Das einzige notwendige Element unterhalb von <COLLADA> ist dabei <asset>, welches Informationen über die Datei selbst, also Autor, Quelldatei, Änderungszeit etc. enthält. Das zur Darstellung erforderliche <scene>-element ist dagegen optional, was Dateien ermöglicht, welche lediglich verschiedene, dann meist mehrfach genutzte, Daten bereitstellen ohne, diese selbst in einer Szene zu platzieren. Diese Daten werden in einer Vielzahl von <library_*>-elementen, beispielsweise <library_visual_scenes>, verwaltet und wie im Beispiel (Prog. 4.1) über URIs referenziert. Durch die Verwendung von URIs muss sich die verwendete Ressource dabei jedoch nicht in der gleichen Datei befinden. Sie kann von praktisch beliebigen Datenquellen bereitgestellt werden. Während beispielsweise Texturen wie bei praktisch jedem 3D-Format aus externen Dateien referenziert werden, können so, auch die in COLLADA selbst enthaltenen Daten, wie Geometrie, Animationen oder Materialien, aus verschiedenen Dateien referenziert werden. So lässt sich leicht eine Library von wiederverwendbaren Assets, wie Materialien, Objekten, Characters oder ganzen Teilszenen, aufbauen. Die einzelnen Assets lassen sich dabei zudem unabhängig voneinander, also auch parallel, erstellen. Dieser Punkt ist bei der Entwicklung in Teams wichtig. Die Referenzierung bietet in Verbindung mit der Anpassbarkeit des Formates jedoch auch viele weitere Möglichkeiten, insbesondere im Hinblick auf die Verwendung als Pipelineformat. Da Veränderungen am Format durch beliebige eigene Profile umgesetzt werden, welche lediglich alternativ zur Default-Implementierung angeboten werden, kann COLLADA durch die Pipeline nahtlos vom Transferformat in ein optimiertes Laufzeitformat umgesetzt werden, wobei die Verarbeitung sowohl zur Laufzeit als auch im Preprocessing geschehen kann. Dies lässt sich anhand des einfachen Beispiels von Polygonmeshes verdeutlichen: Die hierfür benötigten Arrays von Vertexpositionen, Faces, Texturko-

42 4. Konzeption 33 ordinaten etc. werden normalerweise in COLLADAs XML-Struktur, also als Klartext, gespeichert. Durch den damit verbundenen Overhead zum Parsen und die Größe der Dateien, eignet sich COLLADA als solches, relativ schlecht als Laufzeitformat, jedoch lässt sich dies durch die Implementierung eigener Profile leicht umgehen. Diese können die benötigten Daten aus optimierten Binärdateien referenzieren und bei der Entwicklung für mehrere Plattformen lassen sich zudem alle in der gleichen Datei angeben, da nur das beste von der jeweiligen Plattform unterstützte Profil zur Anwendung kommt. Dies ist im schlechtesten Fall die Standartimplementierung und somit lässt sich auch leicht eine On-Demand Optimierung implementieren, indem die Engine beim ersten Laden der Daten auf das Standardprofil zurückgreift und die erstellten Laufzeitdaten in ein entsprechendes Profil überträgt, ein Konzept, welches in gleicher Weise auch im Preprocessing umgesetzt werden kann. Wenn beim finalen Packaging sämtliche für die Zielplattform irrelevanten Profile und somit auch die Daten der Standardimplementierung entfernt werden, lässt sich COLLADA, trotz des durch XML entstehenden Overheads, auch als relativ gut optimiertes Laufzeitformat für Characters, Levels und Ähnliches verwenden, welches lediglich die nötigen Informationen über den Szenenaufbau, wie Positionen oder Hierarchien von Objekten, und verschiedene benötigte Metadaten enthält, während alle sonstigen Daten aus entsprechend angepassten Binärdaten referenziert werden. 4.2 Tools zur Contenterstellung Neben den verwendeten Formaten sind beim Aufbau einer Pipeline natürlich die verwendeten Tools von entscheidender Bedeutung. Für viele der verwendeten Assets können hierbei Standardtools zum Einsatz kommen, nach denen sich zum Teil auch die Auswahl der in der Pipeline verwendeten Formate richtet. Andere Daten sind dagegen sehr spezifisch für die Spieleentwicklung oder gar die konkrete Engine, weshalb für diese spezielle Tools, oder zumindest entsprechende Plug-Ins, benötigt werden. In beiden Fällen ist eine möglichst nahtlose Integration in die etablierten Abläufe der Contentproduktion von großer Bedeutung. So sollte bei der Toolentwicklung, neben der reinen Funktionalität, auch auf die Usability Wert gelegt werden. Diese kommt bei verschiedenen Exportern, Editoren und Preview-Applikationen im Spielebereich leider immer wieder zu kurz; die Asset-Tools der Gamebryo-Engine 14 (Version 2.3) stellen dabei nur ein Beispiel unter vielen dar. 14 Mehr Informationen zur Engine auf der Produktseite unter

43 4. Konzeption D und Animation Anders als bei den Formaten gestaltet sich die Auswahl an Tools zur Erstellung von 3D-Assets sehr vielseitig. Die Toolchain kann sich dabei, wie im reinen Animationsbereich, zum größten Teil an persönlichen Vorlieben, bereits vorhandenen Lizenzen oder speziellen Features orientieren und auch der Einsatz verschiedener Tools ist dabei möglich. Der Vielfalt sind dabei kaum Grenzen gesetzt und während manche Tools bei Modellierung oder Animation vielleicht gewisse Vorteile und Arbeitserleichterungen bringen, sind beispielsweise zum Sculpting ohnehin zusätzliche Programme notwendig. Lediglich die Zusammenführung und der Export aller Daten sollte in einem oder wenigen Tools erfolgen, um den Entwicklungsaufwand für die Pipelineanbindung in Grenzen zu halten. In Ermangelung ausreichend vielseitiger, verbreiteter oder bedienbarer Alternativen, wird die Entscheidung in den meisten Fällen auf einen der großen Drei von Autodesk fallen: 3ds Max erfreut sich trotz seiner Unübersichtlichkeit speziell beim Nachwuchs großer Bekanntheit und findet besonders in der Spielebranche weite Verbreitung. Maya war lange Zeit mit Abstand am teuersten und gründet seine Mächtigkeit vor allem auf die umfangreiche aber auch notwendige Erweiterbarkeit. Softimage führt dagegen zwar ein relatives Nischendasein, dürfte aber das innovationsfreudigste der genannten Tools sein und steht Maya zumindest durch die jüngeren Neuerungen an Vielseitigkeit kaum nach. Was die Anforderungen der Spieleentwicklung betrifft, lässt sich tatsächlich kaum eine rationale Entscheidung zwischen diesen genannten Tools treffen und das praktisch einzige objektive Auswahlkriterium wären wohl die Lizenzkosten, weshalb der Schwerpunkt dieser Arbeit auf dem, an der FH- Hagenberg ohnehin verwendeten, Maya liegt D-Grafik Der 2D-Grafikbereich bei Spielen unterscheidet sich wenig von anderen Branchen und verbindet vielmehr sehr verschiedene Disziplinen. Neben der Texturierung von Objekten, spielt auch das Design beziehungsweise Skinning von Interfaces eine wichtige Rolle. Dieser Vielfalt entsprechend können auch diverse Tools zum Einsatz kommen: Eine klassische Bildbearbeitungssoftware, wie Photoshop 15, bildet für die meisten Anwendungen und zum Export eine wichtige Grundlage, doch verschiedene Spezialtools können den Workflow entscheidend vereinfachen oder beschleunigen. Beim realistischen texturieren, besonders von organischen Objekten, können die 3D-Painting Funktio- 15 Verbreitete Bildbearbeitungssoftware der Firma Adobe (

44 4. Konzeption 35 nen von Programmen, wie ZBrush 16 oder Mudbox 17, große Arbeitserleichterungen bringen, aber auch Programme zur Erstellung von Vektorgrafiken eignen sich, je nach gewünschtem Stil, zur Texturierung, aber besonders zur Gestaltung von Interfaceelementen für Menüs und HUDs. Wichtig ist dabei, wie auch im 3D-Bereich, lediglich die Anbindung an die verwendeten Pipelineformate, was bei der Verwendung von einfachen Standartformaten, wie TGA, in den seltensten Fällen problematisch ist. Lediglich wenn, wie für die CryEngine, spezielle Exporter benötigt werden, wird sich die Pipelineanbindung wohl auf nur ein einziges oder wenige Programme beschränken können, welches dann, ähnlich wie bei den 3D-Daten, als zentrales Tool zur Zusammenführung der Daten dient Sound Auch im Soundbereich lässt sich, zumindest zur Erstellung und Bearbeitung, praktisch jede verfügbare Standardsoftware verwenden, da wohl jede zumindest WAV unterstützt. Zudem sind hier, im Gegensatz zu Bildformaten, auch keine Metadaten erforderlich, welche sich abseits der Standardimplementierungen bewegen. Mitunter benötigte Cue- und Looppoints gehören ebenso zum Format, wie ein entsprechendes Labeling dieser Punkte. Neben der Markierung von Loops oder beliebigen Events, lassen sich diese beispielsweise ebenso leicht für Lipsync-Daten verwenden. Zur Erstellung solcher Daten sind zwar spezielle Tools notwendig, der Vorteil liegt aber darin, dass normale Features des Formates verwendet werden können. Dadurch gehen die Daten bei Änderungen, wie einem Umschnitt, nicht verloren, sondern werden sogar an die Änderungen angepasst Game-spezifisches Neben Assets, für die Standardtools zur Verfügung stehen und dementsprechend auch verwendet werden sollten, erfordern Spiele verschiedene, spezielle Daten, die sich je nach Genre und verwendeter Technologie stark unterscheiden und somit keinen Markt für Drittanbieter darstellen. Die angesprochenen Lipsync-Daten für Audiofiles sind dabei ein sehr spezielles Beispiel und die standardkonforme Einbettung in die jeweiligen WAV -Dateien, nur eine von vielen möglichen Lösungen, welche beispielsweise bei der Source-Engine zum Einsatz kommt. Der wichtigste Aspekt dieses Bereiches besteht jedoch in der Definition von Objekten, welche mit der Programmlogik verknüpft werden. Dies umfasst alles, womit der Spieler interagiert: Bewegliche und zerstörbare Objekte, spielbare und nicht spielbare Charaktere und komplette Levels. 16 Sculpting Programm (2.5D) der Firma Pixologic ( 17 3D-Sculpting Anwendung der Firma Autodesk (

45 4. Konzeption Dedizierte Tools Die meisten Toolchains für Spiele beinhalten, zur Erstellung solcher spieloder enginespezifischen Daten, verschiedene proprietäre Anwendungen, welche in ihrer Komplexität durchaus mit professionellen 3D-Anwendungen vergleichbar sind. Das wichtigste Tool ist hierbei der klassische Leveleditor, der je nach Enginearchitektur verschiedene Aufgaben erfüllt und bei weitem nicht (mehr) nur der Erstellung oder Platzierung von Umgebungsgeometrie dient. In jedem Fall ist eine Platzierung und logische Verknüpfung von Spielrelevanten Objekten und die Einstellung globaler Mapeigenschaften nötig. Praktisch immer erforderliche Beispiele sind dabei Startpunkte für Spieler und die Festlegung von Siegbedingungen beziehungsweise Ladepunkte für angrenzende Levels, andere sind dagegen sehr vom jeweiligen Spiel abhängig und variieren stark in ihrer Komplexität. Während bei Multiplayerspielen in erster Linie eine faire Verteilung von Items, Waffen oder Ressourcen wichtig ist, werden im Singleplayer viele weitere Daten benötigt. KI-Charaktere müssen platziert werden und brauchen eine Vielzahl von Informationen über ihre Umgebung (das Level): Zu einfachen Navigationsmeshes, welche nach einer meist automatischen Generierung oft angepasst werden müssen, kommen verschiedene spezielle Punkte oder Objekte. Dies sind beispielsweise Deckungsmöglichkeiten, Angriffsziele oder Objekte auf welche der Spieler aufmerksam gemacht wird, um seinen Spielfluss und die Story voran zu bringen. Andere dienen schlicht dazu, KI-Charaktere lebendiger wirken zu lassen, indem sie auf Auffälligkeiten in ihrer Umgebung reagieren können ( Igitt, überall Blut! oder ähnliche, eigentlich sinnlose, Aussagen am Rande des Spielgeschehens). Neben Quests und Dialogoptionen in RPGs 18 oder Adventure-Games, sind sehr komplexe Setups, beispielsweise auch für in-game Cinematics, wie in Half-Life 2, nötig, bei denen der Spieler die Kontrolle über die Spielfigur behält. Anders als klassische Cutscenes, welche als einfache Animation abgespielt werden können, erfordern diese eine Vielzahl von Markierungen und entsprechende KI-Scripts, was durch ein Beispiel schnell deutlich wird: Angenommen, der Spieler erreicht zusammen mit einem NPC eine Türe mit Codeschloss, welche nur vom NPC geöffnet werden kann. Nachdem die Türe geöffnet wurde, gehen beide hindurch, sie schließt sich wieder und das normale Spielgeschehen wird fortgesetzt. Bei einer Cutscene folgt nach dem Betreten eines Triggers 19 eine feste Animation beider Charaktere und der Spieler erhält die Kontrolle jenseits der Türe zurück. Eventuell plötzliche Positionswechsel lassen sich dabei durch geschickte Kameraeinstellungen 18 Role Playing Games 19 Trigger bezeichnet im Leveldesign ein unsichtbares Volume, das, durch verschiedene Kontanktzustände von Objekten (on enter, on leave, while touching, while inside etc.), Ereignisse auslösen kann

46 4. Konzeption 37 verbergen. Behält der Spieler jedoch die Kontrolle, ergibt sich folgendes Setup: Der Spieler betritt Trigger A und löst so die Szene aus. Der NPC läuft zu Punkt B vor dem Codeschloss. Steht der Spieler dabei im Weg, muss er gebeten werden, zur Seite zu treten. Entfernt er sich zu weit vom NPC, folgt ihm der NPC und fordert ihn auf, ihm zu folgen, während er sich zu Punkt B zurück bewegt. Hat der NPC Punkt B erreicht, betätigt er das Codeschloss. Dabei wird seine Hand, mittels IK 20, exakt über dem Eingabepanel platziert, wofür eine weitere Markierung C notwendig ist. Anschließend tritt der NPC durch die Türe, zum Punkt D und fordert den Spieler auf, ihm zu folgen. Entfernt sich der Spieler währenddessen zu weit vom NPC, folgt dieser dem Spieler, und fordert ihn auf, ihm zu folgen, während er sich wieder zu Punkt D bewegt. Befinden dich beide innerhalb von Trigger E, jenseits der Türe, schließt sich diese und die KI des NPC kehrt in ihren normalen Status zurück. Insgesamt werden für diese einfache Szene also fünf Markierungen, zwei KI-Scripts ( Erreiche Punkt X und halte den Spieler dabei innerhalb von Radius Z, Berühre Punkt X mit der Schreibhand ) und diverse Sprachszenen benötigt. Diese müssen innerhalb des Leveleditors platziert und verknüpft werden. Zu diesem Zweck dienen entweder schriftliche Scripts oder grafische Systeme, wobei beide Vor- und Nachteile haben: Grafische Editoren sind für Artists meist intuitiver zu bedienen und führen bei einfachen Aufgaben oft schneller zu Ergebnissen. Schriftliches Scripting bietet dagegen vielseitigere Möglichkeiten und erfordert weniger Vorausplanung eventuell benötigter Funktionen. Über die reine Levelerstellung hinaus werden die entsprechenden Editoren jedoch zunehmend um weitere Funktionen erweitert, beispielsweise zur Erstellung von Partikelsystemen, Shadern beziehungsweise Materialien und Charactersetups, was besonders durch moderne Animationssysteme zunehmend an Bedeutung gewinnt. Während früher einfache Modelviewer zur schnellen Kontrolle der Exportierten Modelle und Animationen ausreichend waren, benötigen heutige Systeme aufwändige Setups von Ragdolls, IK-Chains, Animationsüberblendungen, Gesichtsanimationen oder gar zur Integration prozeduraler Systeme, wie Morpheme 21. Der Umfang und die Vielseitigkeit all dieser Funktionen trägt enorm zur Komplexität moderner Level- oder besser Game-Editoren bei, was zu verschiedenen Problemen 20 Inverse Kinematik 21 Prozedurales Echtzeit Animationssystem der Firma NaturalMotion (

47 4. Konzeption 38 führt. So ist der allgemeine Entwicklungsaufwand, im Vergleich zu den früher oft sehr einfachen Leveleditoren, stark gestiegen und besonders Engines mit weit zurückliegenden Wurzeln stehen vor dem Problem, dass die stetig weiterentwickelten Tools an ihre architekturbedingten Grenzen stoßen und mit der Integration immer weiterer Features zunehmend instabiler werden Integration ins 3D-DCC-Tool Eine Möglichkeit zur Reduzierung dieses großen Entwicklungsaufwandes ist die Integration der benötigten Features in ein bestehendes DCC-Tool wie Maya. Dieser Ansatz ist vor allem bei kleinen Engines verbreitet und dort leider selten wirklich gut und oft wenig robust umgesetzt, weshalb dem Konzept tendenziell der Ruf einer billigen Notlösung anhaftet. Betrachtet man aber ähnliche Integrationen beispielsweise im Bereich von Renderern, so sind Vue xstream 22 oder RenderMan for Maya 23 ausgezeichnete Beispiele für eine praktisch nahtlose und stabile Einbindung von Third-Party-Features in verschiedene DCC-Tools. Tatsächlich ist im Fall von Maya gerade der modulare Aufbau und die besonders gute Erweiterbarkeit einer der Hauptgründe für seine weite Verbreitung im Filmbereich, da hier häufig Eigenentwicklungen neuer Technologien zum Einsatz kommen, die dementsprechend (noch) nicht von Standardtools angeboten werden, während, das Programm für sich genommen, anderen Lösungen in manchen Bereichen durchaus unterlegen ist. Bei dieser Integration von Features mittels Plug-Ins, ist der genannte, geringere Entwicklungsaufwand jedoch auf keinen Fall mit einem Minimalaufwand zu verwechseln, wie er häufig von preisgünstigeren Engines betrieben wird. Es genügt in aller Regel nicht, den gegebenen Funktionsumfang durch einen Exporter und verschiedene Scripts zu ergänzen, sondern vielmehr muss das verwendete System in der konzeptionellen Betrachtung auf seine relevanten Basisfunktionalitäten reduziert werden: Ein erprobtes und stabiles GUI-System mit 3D-Interaktion 24 und Szenenverwaltung. Dazu kommt der, weniger technische, Aspekt, der etablierten und langjährig bewährten Bedienungskonzepte, welche von Eigenentwicklungen, obwohl problemlos nachimplementierbar, oft genug ignoriert werden. Davon ausgehend lassen sich die gleichen Features implementieren, wie dies auch bei Stand-Alone Editoren der Fall ist: Beliebige Tools, eigene Geometriearten wie CSG, Terrains, Echtzeitshader, die Einbindung des eigenen Renderers oder der Physikengine, Echtzeitanbindung an die Engine und vieles mehr. Zudem bietet die Verbindung von Modeler und Leveleditor sogar Vorteile 22 Landschafts-Renderer der Firma e-on Software ( 23 Maya-Integration von Pixars Renderer RenderMan ( 24 Wichtig sind hierbei vor allem die Funktionen zur Selektion und Manipulation im 3D-Raum

48 4. Konzeption 39 im Workflow: Heutige Engines, deren Levels meist meshbasiert sind, haben gegenüber älteren Ansätzen, bei denen die Levelgeometrie im Level-Editor erstellt wird, den Nachteil, dass Änderungen und Anpassungen von Objekten stets in einem externen Modeler erfolgen müssen. Es ist also notwendig, die Quelldatei, des entsprechenden Teilstücks des Levels, gesondert zu öffnen, die Änderungen durchzuführen und es anschließend neu zu exportieren, was im seltenen Idealfall über ein automatisches Bridging in Echtzeit geschieht. Ist der Leveleditor dagegen in das DCC-Tool integriert, stehen sämtliche Modellierungswerkzeuge jederzeit zur Verfügung und die Objekte können direkt im Level angepasst werden, was den zusätzlichen Vorteil bringt, dass auch die umgebenden Objekte vorhanden sind und so als Referenz dienen können. Dies stellt bei entsprechender Implementierung auch kein Problem für mehrfach genutzte, referenzierte Objekte dar. Diese können auf Nachfrage überschrieben, oder als neue Variante gespeichert werden, wobei die Referenzen automatisch aktualisiert werden. Den einzigen Nachteil einer solchen integrierten Lösung stellt, vor allem im Bereich der Versionskompatibilität, die Abhängigkeit von entsprechenden Drittanbieter dar. Da aber auch die Filmbranche seit Jahren große Investitionen in vergleichbare Lösungen tätigt, ist hier, zumindest in der praktischen Umsetzung, kaum mit Problemen zu rechnen. Generelle Bedenken gegenüber eines möglichen Vendor Lock-Ins lassen sich dagegen selbstverständlich nicht ausräumen. 4.3 Versionsverwaltung und Kollaboration Ein einheitlicher Versionsstand ist Grundvoraussetzung für die effektive Zusammenarbeit. Dies gilt in der Spieleentwicklung nicht nur für die Quelldateien selbst, sondern besonders auch für die verschiedenen Produkte. Da hier, mit Asseterstellung und Programmierung, zwei sehr unterschiedliche Bereiche zusammenarbeiten, ist es nicht, wie in der reinen Softwareentwicklung, möglich, dass jeder Entwickler seine Binaries selbst kompiliert, und somit nur die Quellen synchronisiert werden müssen. Vielmehr benötigen beide Seiten Zugriff auf die Produkte der jeweils anderen, die Programmierer auf die Assets im Laufzeitformat und die Artists auf aktuelle Programmdateien. Ein Builden des gesamten Projektes am jeweiligen Arbeitsplatz ist dagegen, aus Zeitgründen, fehlendem Know-how und der dann lediglich zum Builden benötigten Lizenzen, nicht praktikabel Aufteilung der Projektstruktur Da also Binaries benötigt werden, ist der sonst durchaus sinnvolle Grundsatz, diese nicht ins Repository einzupflegen hinfällig. Grundsätzlich sinnvoll ist dieser jedoch, da er einem allzu schnellen Verbrauch, des, gut abgesicherten und damit teuren, Speicherplatzes im Versionsverwaltungssystem,

49 4. Konzeption 40 entgegenwirkt. Ein Problem, welches sich aber lösen, oder zumindest abschwächen lässt. Nicht für alle Projektdaten, insbesondere die Binaries und Runtime-Assets, ist eine besondere Datensicherheit erforderlich und somit stellt die einfachste Lösung die Aufteilung auf verschiedene Repositories und Speichersysteme dar Code Repositories Die Code Repositories enthalten, wie auch in der normalen Softwareentwicklung, sämtliche für das Projekt benötigten Sourcecodes. Da auch hier in sehr verschiedenen Bereichen, wie Engine, Tools und Spiellogik, gearbeitet wird, kann aber eine weitere Aufteilung auch an dieser Stelle sinnvoll sein. Dies gewährleistet eine klare Trennung zwischen verschiedenen Projektteilen und vermeidet damit Abhängigkeiten zwischen verschiedenen Projekten. Gleichzeitig wird so auch die Weitergabe abgeschlossener Teile an Lizenznehmer vereinfacht. Wie auch immer sich die genaue Ausprägung des oder der Code Repositories gestaltet, hat die Datensicherheit unbedingte Priorität, womit die Kosten für den hier verwendeten Speicherplatz entsprechend hoch sind. Der Grund für die Trennung von nicht weniger wichtigen Asset Repositories liegt dabei vielmehr in der Langen Lebensdauer der Codebasis. Diese wird, im Gegensatz zu Assets, oft über lange Zeit und mehrere Projekte weiterentwickelt und lässt sich somit nicht einfach nach Projektabschluss archivieren Artist Workspace Der Artist Workspace beinhaltet sämtliche Assets in den nativen Formaten der zur Erstellung verwendeten Programme, also Maya-Files (.mb), Photoshop-Dateien (.psd) und dergleichen. Auch dieses Repository erfordert eine ähnliche Datensicherheit wie die Codebasis, jedoch kann das große Datenvolumen an dieser Stelle durchaus ein Problem darstellen. Nicht nur sind die verwendeten Binärdaten grundsätzlich schlecht für die, meist auf Changesets basierende, Versionierung geeignet, sondern zur Verarbeitung ist zudem die bestmögliche Qualität der Daten empfehlenswert. Bilder sollten mit 16 Bit pro Kanal verarbeitet werden anstatt der später üblichen 8 Bit, um Qualitätseinbußen bei Überblendungen und Filtern zu vermeiden. Gleiches gilt für Audiodaten, die üblicherweise, mit einer Quantisierung von mindestens 24 Bit, verarbeitet werden, während im Endprodukt 16 Bit meist ausreichen. Gegenüber High-Poly Modellen, zur Generierung von Normalmaps, die nicht selten jeweils mehrere Hundert Megabytes in Anspruch nehmen, sind dies jedoch relativ kleine Posten der Gesamtbilanz. Neben diesen, bereits problematischen Grundvoraussetzungen, ist aber auch die im Artist Workspace erforderliche Arbeitsweise einem sparsamen Umgang mit Speicherplatz wenig zuträglich. Es werden an dieser Stelle nicht

50 4. Konzeption 41 nur Daten benötigt, die tatsächlich ihren Weg in das finale Produkt finden, sondern es sind immer wieder gestalterische Alternativen und Testszenarien für verschiedene Lösungsansätze erforderlich, welche parallel abrufbar sein müssen, um einen direkten Vergleich zu ermöglichen. Ein Vorteil bietet sich lediglich dadurch, dass Assets im Gegensatz zu Programmcode normalerweise nur für ein konkretes Projekt benötigt werden. Eine Weiterverwendung in anderen Projekten scheitert meist am Design, beziehungsweise der weiterentwickelten Technologie (Polygonanzahl, Texturauflösung). Somit lassen sich die Daten nach Projektabschluss, spätestens aber nach der Supportphase, archivieren und benötigen keinen weiteren Zugriff über das Repository, weshalb diese von Beginn an in einem vom Sourcecode unabhängigen System verwaltet werden sollten Transferdaten der Pipeline Die Eingangsdaten der Pipeline, also die in das Zwischenformat exportierten Daten sind von zentraler Bedeutung für die Verknüpfung der Assets und die gemeinsame Arbeit an verschiedenen Teilen des Projektes. Diese lassen sich zwar jederzeit neu aus ihren nativen Quellen exportieren, bilden aber den verfügbaren Pool von Assets, aus dem die benötigten Daten referenziert werden, und müssen daher ebenfalls zentral zur Verfügung gestellt werden. Zudem sollte dieser Datenbestand genau die vom Projekt benötigten Assets umfassen, wodurch sein Versionsstand die Grundlage für die Buildversion der Laufzeitdaten bilden kann. Dadurch dient er gleichzeitig als Basis für die automatisierte Pipelineverarbeitung, indem Änderungen an diesem Repository das Buildsystem starten und eine Synchronisierung der Laufzeitdaten bewirken Runtime Repository Wie bereits eingangs erwähnt, erfordert die Spieleentwicklung auch die zentrale Verwaltung der ausführbaren Programmdateien und der Laufzeitassets, beziehungsweise wird sie dadurch deutlich vereinfacht. Allein schon wegen des teilweise großen Zeitaufwandes für die Verarbeitung von Assets in der Pipeline ist eine Auslagerung dieser Prozesse vom Arbeitsplatzrechner auf eine dedizierte Infrastruktur erstrebenswert, was im direkten Widerspruch zur sonst oft gebräuchlichen Praktik des Source-Check-out mit anschließendem Kompilieren ist. Doch dies ist nicht der einzige Grund für die zentrale Bereitstellung der Lauftzeitdaten, welche am komfortabelsten ebenfalls über das Versionsverwaltungssystem erfolgt. Da mit Programmierern und Artists zwei Fachbereiche mit sehr unterschiedlichem Hintergrund beteiligt sind, ist nicht das nötige Know-how in der jeweils fremden Domäne vorauszusetzten. So bestünde ein Rebuild der Programmdateien beziehungsweise der Assets im Idealfall zwar

51 4. Konzeption 42 im einfachen Ausführen eines entsprechenden Setup-Scriptes, jedoch ist in der Praxis damit zu rechnen, dass abweichende Systemkonfigurationen und ähnliches immer wieder zu Fehlern führen. Einfache Beispiele hierfür wären Library Dependencies, welche selbst bei reinen Softwareprojekten, zumindest im Open-Source Bereich, oft mangelhaft dokumentiert sind, aber auch Asset-Tools deren Einstellungen vom Standard abweichen. Während sich solche Probleme durch eine lückenlose Dokumentation vielleicht lösen ließen, stellen die Kosten für lediglich zum Builden benötigte Lizenzen jedoch ein klares Argument für die Versionierung der Laufzeitdaten, sowie der Programmdateien dar Dependencies und Tools Mit der Einbindung von Dependencies hat Julien Koenen [8] auf der GDC Europe 09 einen weiteren wichtigen Aspekt angesprochen. Dies geschah zwar vor allem im Hinblick auf die gleichzeitige Entwicklung mehrerer Projekte und die damit verbundene Verwendung unterschiedlicher Versionen von SDKs und Tools. Die zugrunde liegende Problematik lässt sich aber auch in anderen Fällen nachvollziehen. Häufig werden Dependencies über entsprechende Umgebungsvariablen referenziert, was auch beim Cogaen-Projekt der Fall ist. Dies erfordert ein aufwändiges Setup der jeweiligen Workstations, was bei Projektbeginn und auch beim Ersatz von Ausfällen unnötig lange Verzögerungen bewirkt. Das Hauptproblem liegt jedoch in der Umgebungsabhängigkeit des Buildpozesses, wodurch das Endprodukt nicht eindeutig reproduzierbar ist. Die einfache Lösung besteht auch bei diesem Problem darin, sämtliche Dependencies, als auch die verwendeten Pipelinetools in Repositories zu verwalten, die sich so leicht in die jeweilige Projektstruktur integrieren und von dort über relative Pfade referenzieren lassen Projekt Repository Anders als die restlichen Repositories enthält das Projekt Repository selbst praktisch keine Daten, sondern dient in erster Linie der Strukturierung. Dabei werden externe Inhalte in die entsprechenden Verzeichnisse referenziert, wodurch, trotz der Verwendung verschiedener Quellen, nur ein einziger Check-Out ohne weitere Konfiguration nötig ist. Dies lässt sich, durch Mechanismen wie svn:externals oder Multi-Line-Views von Perforce, leicht umsetzen und ermöglicht eine eindeutige Projektumgebung mit minimalem Konfigurationsaufwand der einzelnen Clients.

52 4. Konzeption Weiterverarbeitung der Assets Die Weiterverarbeitung des Contents ins jeweilige Laufzeitformat ist die eigentliche Aufgabe der Asset-Pipeline und stellt dennoch nur einen kleinen Aspekt der Gesamtkonzeption dar, wobei sich verschiedene Möglichkeiten zur Umsetzung anbieten. Heutige Systeme erlauben in vielen Fällen eine On-Demand Konvertierung, entweder im Editor, oder während des Ladevorgangs durch die Engine, aber auch klassische Offline-Pipelines haben längst nicht ausgedient, sondern sind noch immer die einzige Möglichkeit zur Umsetzung realistischer, statischer Beleuchtungslösungen wie Radiosity oder Global Illumination. Zudem erleben sie, durch den wachsenden Markt für Mobile Games, eine Renaissance: die Leistungsfähigkeit entsprechender Geräte ähnelt der von PCs Ende der 90er und so finden die damaligen Technologien wieder Anwendung. Insgesamt orientiert sich die Ausprägung der Pipeline also in erster Linie an den entsprechenden Umgebungsvoraussetzungen und lässt sich bei entsprechender Konzeption, wie sie hier das Ziel darstellt, flexibel an die jeweiligen Möglichkeiten und Erfordernisse anpassen. Die Offline Pipeline kann dabei eine relativ leicht implementierbare Grundlage darstellen, deren Verarbeitungsfunktionen, bei Bedarf, problemlos in die jeweiligen Systeme, wie den Leveleditor oder das Ressourcenmanagement der Engine, umlagern lassen. Gerade eine Integration in die Engine kann aber ohnehin nur als alternatives Modul während der Entwicklung implementiert werden, da sowohl ein Release der entsprechenden Funktionen als auch der editierbaren Quelldaten zu Problemen führt. Diese sind einerseits lizenzrechtlicher Natur, da bei der Verarbeitung möglicherweise Technologien von Drittanbietern zum Einsatz kommen, welche nicht zur Weiterverbreitung freigegeben sind. Gleichzeitig schreiben Konsolenanbieter mitunter vor, die Veränderung von Assets zu unterbinden. Andererseits eröffnet Editierbarkeit der Assets weitreichende Möglichkeiten zur Manipulation, was besonders bei Multiplayer-Spielen zu verhindern ist COLLADA in der Pipeline Das in dieser Konzeption verwendete COLLADA-Format wurde nicht nur zum Datenaustausch, sondern insbesondere zur Weiterverarbeitung in Pipelines entwickelt. Dies zeigt sich nicht nur in der bereits dargestellten Austauschbarkeit der eigentlichen Datenressourcen, sondern auch in den Angebotenen Tools zur Verarbeitung des Formates. Allen voran steht das Conditioner-System: Conditioner sind kleine Funktionsblöcke, die jeweils einzelne, sehr kleine Verarbeitungsschritte vornehmen und in vielfältiger Weise miteinander verknüpft werden können. Mit COLLADA DOM basiert das System auf der

53 4. Konzeption 44 Standardlibrary zum Umgang mit COLLADA und lässt sich durch die einfache Funktionsweise sehr leicht in verschiedene Systeme integrieren: Jeder Conditioner hat ein DOM 25 als Eingangsparameter und führt in dieser Datenstruktur die entsprechenden Änderungen durch. Im Normalfall wird dieses veränderte DOM wieder ausgegeben und kann so vom nächsten Conditioner weiterverarbeitet werden. Einen Sonderfall stellen Output- Conditioner dar, welche am Ende einer solchen Verarbeitungskette (sog. Pipeline) stehen. Diese dienen entweder dazu, das entgegengenommene DOM als COLLADA-File auszugeben, oder es in andere Formate zu konvertieren. Dabei spielt es selbstverständlich keine Rolle, ob die Daten ins Storagesystem geschrieben oder direkt weiterverwendet werden, womit sowohl Offline- als auch Onlineverarbeitung auf das gleiche System zurückgreifen können. Zur einfachen Konfiguration solcher Conditioner-Pipelines (zur Unterscheidung von der Asset Pipeline als Ganzes) steht mit COLLADA Refinery ein einfaches GUI-System zur Verfügung, welches für einfache Offline- Pipelines durchaus ausreicht. Wie in Abbildung 4.1 zu sehen, bietet das auf JAVA basierende Programm einen Node-Editor an, der einen schnellen und intuitiven Aufbau von Conditioner-Pipelines beliebiger Komplexität erlaubt. Der Workflow ähnelt dabei dem verschiedener grafischer Programmierumgebungen oder nodebasierter Compositing-Programme und stellt sowohl für Programmierer als auch Artists keine größere Herausforderung dar. Zur besseren Übersicht beziehungsweise Wiederverwendbarkeit lassen sich Teilpipelines zudem als Makros zusammenfassen und abspeichern, wobei das Format der gleichen XML-Struktur folgt, die auch im, für komplette Conditioner-Pipelines verwendeten, pip-format zum Einsatz kommt. Darüber hinaus ist auch eine Integration in Build-Systeme problemlos möglich, da COLLADA Refinery im Kommandozeilenmodus ausgeführt werden kann. Zum Aufbau einer, zumindest rudimentären, Asset-Pipline ist kein weiterer Entwicklungsaufwand nötig, abgesehen von den entsprechenden Conditionern. Die Flexibbilität des Systems ermöglicht darüber hinaus eine schrittweise Weiterentwicklung bis zu einer integrierten Lösung mit Echtzeitanbindung an das Spiel, egal ob über den Leveleditor oder direkt im Ressourcenmanagement der Engine Automatisierte und ausgelagerte Verarbeitung Bei einer Online-Pipeline, welche sämtliche Änderungen in Echtzeit in die Engine überträgt, erfolgt die Konvertierung, zumindest für die Entwicklungsplattform, ohnehin automatisch, sogar eine parallele Anbindung an mehrere Zielplattformen ist dabei möglich. Ein solches, beispielsweise in der CryEngine 3 umgesetztes System, kann jedoch niemals die einzige Lösung zur Integration von Assets darstellen, allein da Entwicklungsversionen von Consolen 25 Document Object Model

54 4. Konzeption 45 Abbildung 4.1: Der Node-Editor von COLLADA Refinery. Auch Verzweigungen von Pipelines sind möglich; im Beispiel werden sämtliche Meshes mit Hilfe eines Makros trianguliert und parallel die statischen Kollisionsobjekte als CSL-Script ausgegeben. zu teuer sind, um diese für jeden Entwicklerarbeitsplatz zur Verfügung zu stellen. Eine parallel, oder auch ausschließlich betriebene Offline-Pipeline, birgt jedoch grundsätzlich das Risiko, dass Änderungen an den Quelldaten vergessen werden und eine Übersetzung ins Laufzeitformat nicht, oder erst verspätet, stattfindet. Aus diesem Grunde ist es sinnvoll, die Laufzeitdaten automatisiert mit der aktuellen Version der Intermediate Assets zu synchronisieren, wobei die hierzu geschaffene Infrastruktur gleichzeitig dazu genutzt werden kann, diese teilweise aufwändigen Berechnungen von den Workstations der Entwickler auszulagern Continuous Integration Das im Extreme Programming angewandte Konzept der Continuous Integration kann eben diesem Zweck dienen. Entsprechende Systeme, wie beispielsweise die Open-Source-Lösung CruiseControl, reagieren auf Änderun-

55 4. Konzeption 46 gen in einem Source-Repository und kompilieren das Projekt automatisch neu. Anschließende, automatische Tests dienen in der Softwareentwicklung der ständigen Überprüfung der Programmqualität und das Konzept geht normalerweise mit verschiedenen weiteren Techniken und Richtlinien zur Verbesserung der Codequalität einher. Die dabei zugrunde liegenden Systeme lassen sich jedoch leicht für die automatische Synchronisierung zwischen Intermediate Assets und Laufzeitdaten adaptieren. Der Vorteil solcher fertigen Lösungen liegt dabei nicht nur im verringerten Entwicklungsaufwand und der erprobten Stabilität sondern auch im Angebot verschiedener praktischer Tools. So bietet CruiseControl, neben einem ohnehin notwendigen Frontend zur Remoteadministration, beispielsweise eine Hintergrundapplikation für Clients an, welche zur Anzeige von Statusnachrichten dient, also des erfolgreichen Builds oder entsprechender Fehlermeldungen. Gerade solche Komfortfunktionen können sehr praktisch sein. Sie finden sich bei Eigenentwicklungen aber typischerweise ganz am Ende der Prioritätenlisten und werden somit nur in seltenen Fällen wirklich umgesetzt Zentrale Buildsysteme Nicht nur die zentrale Automatisierung der Pipelineprozesse erfordert die Einrichtung von dedizierten Buildsystemen, sondern auch für lokale Tests kann die entsprechende Infrastruktur sinnvoll genutzt werden. Vergleichbar mit einer Renderfarm lassen sich aufwändige Berechnungen vom Arbeitsplatz auslagern, was es ermöglicht, während der entstehenden Wartezeiten weitere Aufgaben zu erledigen. Mitunter können die Prozesse auch auf mehrere Rechner aufgeteilt werden. Dies ist bei der Vorberechnung von Beleuchtungsdaten praktisch immer der Fall, aber auch Preprocessing-Schritte der statischen Szenenverwalung oder die Generierung von Navigationsmeshes für die KI erscheinen hierzu geeignet. Die Iterationszeiten lassen sich durch eine solche Aufteilung in jedem Fall, teils drastisch, verkürzen. Das Hauptproblem stellt dabei die Remotesteuerung des Systems und der manuelle Job-Submit dar. Systeme zur Verwaltung von Renderfarmen sind üblicherweise speziell auf bestimmte Renderer zugeschnitten und lassen sich nicht auf beliebige Build-Tools adaptieren. Besonders die Bereitstellung der Quelldaten gestaltet sich jedoch schwierig. Da es sich, zumindest im Falle von lokalen Tests, um Änderungen in der jeweils persönlichen Working-Copy des Projektes handelt, können die Quelldaten nicht dem Repository entnommen werden. Gleichzeitig ist wegen der Vielzahl von verknüpften Dateien ein Upload kaum praktikabel. Der Buildserver benötigt also entweder Zugriff auf den Workspace des Clients, oder dieser muss gespiegelt werden. Da verschiedene Tools, speziell manche Renderer, beim Netzwerkzugriff auf Ressourcen jedoch Probleme verursachen, ist weder die Auslagerung des Workspaces auf eine Netzwerkressource, noch der Zugriff des Buildservers auf

56 4. Konzeption 47 die lokalen Daten des Clients eine ideale Lösung. Darüber hinaus bietet eine Spiegelung zwei praktische Vorteile: Sie dient einerseits als leichtes Backup, auch der nicht im Repository verwalteten Daten, und andererseits sind beide Systeme unabhängig. Der Arbeitsplatz kann während des Buildprozesses also auch gewartet oder abgeschaltet werden. Die benötigte Eigenentwicklung des Buildservers selbst, lässt sich auf Grund der erforderlichen Remotesteuerung wohl am einfachsten als Webanwendung realisieren. Ob andere, in der Bedienung vielleicht komfortablere, Lösungen deutlich mehr Aufwand erfordern, lässt sich hier, auf Grund der fehlenden Expertise im entsprechenden Fachbereich, jedoch nicht abschätzen und wäre eher in der konkreten Projektplanung zu erörtern Konfiguration, Verwaltung und Überwachung Gerade ein möglichst generisches System, wie das hier angestrebte, erfordert umfangreiche und einfache Möglichkeiten zur Konfiguration. Die Pipelineprozesse selbst stellen dabei, wie bereits erörtert, durch COLLADA Refinery beziehungsweise eine vergleichbare, integrierte Lösung, kein Problem dar und auch beim manuellen Build einzelner Assets lassen sich die erforderlichen Konfigurationen relativ problemlos individuell festlegen. Für den projektweiten beziehungsweise automatischen Build sind hingegen detaillierte Konfigurationen notwendig. Es muss neben der Definition von globalen Einstellungen für Development- und Releaseversionen möglich sein, einzelne Projektteile, Verzeichnisse oder Dateien, ihrem aktuellen Entwicklungsstatus entsprechend, gesondert zu behandeln. Solche Overrides dürfen lediglich bei finalen Builds außer Kraft gesetzt werden, aber auch dann nur, wenn sie zu Entwicklungszwecken dienen und nicht aus gestalterischen Gründen eingesetzt werden Buildsystem Der Markt bietet zwar eine unüberschaubare Anzahl von Build Systemen, bekanntere wie Make, SCons, Ant, Jam etc. stellen jedoch keine einfache Lösung für die im Assetbereich nötige Art der Konfiguration bereit. Zwar lassen sich entsprechende Ergebnisse über die Definition unterschiedlicher Targets erreichen, doch ist dies umständlich und kompliziert, weshalb sich dieses Konzept kaum für Artists ohne Programmier- oder Scriptingkenntnisse eignet. Aus diesem Grunde hat beispielsweise Keengames 26, mit Lace 27, ein eigenes Buildsystem entwickelt, welches Gruppierung und Tagging einzelner Assets zur gesonderten Verarbeitung erlaubt. Dieses Projekt befindet sich jedoch erst im Alphastatus und ist bisher kaum dokumentiert, weshalb an 26 Deutscher Spieleentwickler ( 27 Erhältlich unter

57 4. Konzeption 48 dieser Stelle auf eine weitere Evaluierung verzichtet wurde, lediglich die Erwähnung als möglicher Lösungsansatz erscheint dennoch angebracht. Um dagegen auf klassische Buildsysteme zurückgreifen zu können, erscheint es als gangbarer Weg, die benötigten Overrides in den Quelldaten der Assets selbst zu definieren. Auf diese Weise lassen sich die benötigten Features in die Asset Compiler, bei der Verwendung von COLLADA also entsprechende Conditioner, verlagern. Diese müssen ohnehin selbst entwickelt werden und somit stellt ein Auslesen der Konfiguration während des Builds sicher weniger Aufwand dar, als die Entwicklung eines eigenen Buildsystems. Ausgehend von diesem leicht umsetzbaren Konzept gestaltet sich die Auswahl eines geeigneten Standardsystems wieder sehr viel freier, wobei ein wichtiges Kriterium sicherlich die Verfügbarkeit grafischer Konfigurationstools darstellt Steuerung Wird für die Automatisierung auf ein bestehendes System zur Continuous Integration zurückgegriffen, gestaltet sich die Steuerung zumindest hier unproblematisch. Diese bieten üblicherweise umfangreiche Möglichkeiten des Remotezugriffs und Builds können verschiedene Setups verwalten. Während der Entwicklung kommt am besten eine schnelle Konfiguration mit standardmäßig reduzierten Optimierungs- und Qualitätseinstellungen zum Einsatz, welche durch Commits im Sourcerepository ausgelöst wird. Auf diese Weise können Änderungen und vor allem neue Assets schnell im Laufzeitformat bereitgestellt werden. Eine zweite Stufe sollten scheduled Builds darstellen, die je nach erforderlichem Zeitaufwand, jede Nacht oder wöchentlich durchgeführt werden können. Wenn dabei Optimierungen in normalem Maße durchgeführt werden und auch Content-Packages erstellt werden, lässt sich anhand dieser Builds das finale Laufzeitverhalten abschätzen und mögliche Performanceprobleme frühzeitig aufdecken. Auch wenn nicht zwingend notwendig, bietet es sich an, die Qualitätseinstellungen, beispielsweise von Lightmaps, den finalen anzunähern. Dadurch wird, über einzeln, zu Testzwecken kompilierten Levels hinaus, ein Bild vom finalen Look des Projektes ermöglicht, was zumindest der Motivation des Teams zuträglich ist. Ebenso wie die finalen, sollten auch diese regelmäßigen Builds vollständige Rebuilds darstellen. Auf diese Weise lassen sich die, bei ansonsten ausreichenden, inkrementellen Builds, mitunter auftretenden, Inkonsistenzen vermeiden und es wird ein hundertprozentiges Abbild des aktuellen Versionsstandes durch die Laufzeitdaten sichergestellt. Finale Builds werden, im Gegensatz zu den beiden vorangegangen, stets manuell ausgelöst und erzeugen im Idealfall ein vollständiges Installationsmedium. Dabei sollten alle zur Entwicklung eingesetzten Overrides von Konfigurationen (und nur diese) durch finale Einstellungen ersetzt werden, also

58 4. Konzeption 49 vollständige Optimierung, finale Rendering- und Kompressionsqualität und so weiter. Andere Erfordernisse ergeben sich beim manuellen Build einzelner Assets zu Testzwecken. Die Quellen hierfür finden sich nicht zwingend im Repository wieder, beziehungsweise müssen die entsprechenden Einstellungen vor einem Commit erst ermittelt werden. Geht man davon aus, dass, von Defaultwerten abweichende, Konfigurationen in den Assets selbst festgehalten werden, vereinfacht dies jedoch auch die hier benötigten Tools zur Konfiguration. Grundsätzlich lassen sich so die gleichen Einstellungen wie beim automatischen Buildsystem verwenden, lediglich eine Auswahl der benötigten Assets ist zusätzlich erforderlich. In diesem Zusammenhang lässt sich zudem das Konzept der assetgebundenen Overrides weiterführen. Die Flexibilität lässt sich deutlich erhöhen, indem Overrides an die verwendeten Defaulteinstellungen und die Art des Builds geknüpft werden, also in Abhängigkeit von Development-, Release-, automatischem oder manuellem Build, unterschiedliche Einzelkonfigurationen greifen können.

59 Kapitel 5 Projektarbeit Die Masterarbeit sieht ein begleitendes, praktisches Projekt vor, welches dazu dient, die Anwendbarkeit der entwickelten Konzepte zu überprüfen. Das sehr weitreichende Gebiet der Asset-Pipelines für 3D-Spiele ermöglicht dabei in der vorgesehenen Projektdauer nicht die Implementierung eines vollständigen Systems. Eine Beschränkung auf bestimmte Teilbereiche gestaltet sich darüber hinaus ebenfalls sehr schwierig. Der konkrete Fall von Cogaen bietet praktisch keinerlei Rahmenbedingungen oder grundlegende Ansätze einer Pipeline, welche sich ausbauen ließen, sondern erfordert eine komplette Neukonzeption. In Anbetracht dieser Situation kann die Projektarbeit lediglich einen Proof of Concept mit minimaler Funktionalität darstellen, bei dem ein Hauptaugenmerk auf der Identifikation eventueller Schwierigkeiten bei der Umsetzung liegt. 5.1 Konzentration auf funktionale Schwerpunkte Die Bestandteile der hier vorgestellten Konzeption einer Asset-Pipeline lassen sich im Wesentlichen in zwei Teilbereiche unterteilen: Die zur Funktion unbedingt notwendigen, und jene, die primär zur Vereinfachung oder Beschleunigung des Workflows dienen. Zu den wirklich benötigten Bereichen zählen lediglich die Tools für Erstellung und Export der Assets, die Weiterverarbeitung und die Anbindung an die Engine, alle weiteren werden bei der hier beschriebenen Umsetzung ausgespart, denn nicht allein der reine Entwicklungsaufwand lässt keine vollständige Implementierung in der gegebenen Zeit zu, auch die Interdisziplinarität stellt, zumindest für ein Einzelprojekt, ein großes Problem dar. Unter diesen Voraussetzungen muss also eine Problemstellung gefunden werden, welche die Implementierung einer, zwar funktional sehr eingeschränkten, aber in ihren Grundzügen dennoch funktionierenden Pipeline ermöglicht. 50

60 5. Projektarbeit Contenterstellung und Export Das Konzept sieht grundsätzlich vor, die zentralen Funktionen zur Bearbeitung von Assets und der Levelerstellung in das verwendete DCC-Tool zu integrieren, anstatt diese in einem dedizierten Leveleditor umzusetzen. An der FH-Hagenberg kommt hierzu nur Maya in Frage, das aber auch generell eine gute Wahl für ein solches Vorhaben darstellt. Um die Anforderungen einer Machbarkeitsstudie für weitreichende Erweiterungen zu erfüllen, reicht dabei nicht die Entwicklung einfacher MEL- oder Pythonscripts aus, sondern es sollte auf die zur Plug-In-Entwicklung bereitgestellte C++ API zurückgegriffen werden, was unter entsprechenden Voraussetzungen auch eine Anpassung des erhältlichen COLLADA-Exporters erfordert. Neben der Entwicklung eigener Szenennodes, Shader oder Geometrietypen, für deren Behandlung der verwendete Exporter erweitert werden muss, bietet die Maya API auch die Möglichkeit zur Implementierung von Tools, welche lediglich der Bearbeitung von Szenenelementen dienen, jedoch nicht exportiert werden und somit kein gutes Beispiel darstellen würden Weiterverarbeitung Die Weiterverarbeitung erfolgt mit Hilfe von COLLADA Refinery durch entsprechende Conditioner. Dabei stehen Beispiele für verschiedene Standardanwendungen wie die Triangulierung von Meshes oder auch das Packen aller benötigten Daten zur Verfügung, welche dementsprechend nicht nachimplementiert werden sollten. In jedem Fall wird jedoch ein Conditioner zum Export für die Engine benötigt, wobei dieser schnell eine unerwünschte Komplexität erreichen kann, sofern er Unterstützung für Meshdaten oder Animationen bietet. Da hierbei ein Großteil des Entwicklungsaufwandes in die fehlerfreie und vollständige Unterstützung des entsprechenden Formates fließen müsste, erscheint beispielsweise der Export einer reinen Leveldefinition, welche lediglich die Positionen der platzierten Objekte umfasst weitaus zielführender: Hierbei müssen lediglich die Transformationsdaten bestimmter Objekte innerhalb des DOM ermittelt und exportiert werden, was für eine grundlegende Einschätzung der verwendeten APIs ausreichen sollte Engineanbindung Der Entwicklungsstand von Cogaen während des Projektzeitraumes lässt größere Investitionen in die Engineanbindung wenig sinnvoll erscheinen: Beim Ressourcenmanagement stehen weitreichende Neustrukturierungen an, wichtige Systeme, wie Ogre3d oder PhysX, waren ohnehin eher als Übergangslösungen konzipiert und sollen in absehbarer Zeit, durch die in Entwicklung befindlichen Module CBero beziehungsweise PhysiKCHs, ersetzt werden. Ein

61 5. Projektarbeit 52 datenbasiertes System zur Definition komplexerer Assets, wie beispielsweise Levels, existiert nicht und müsste komplett neu entwickelt werden, um die anfangs (in Abschnitt ) beschriebene, scriptbasierte Notlösung zu ersetzen. Dieses Unterfangen hätte jedoch für sich alleine genommen den Umfang eines Semesterprojektes und setzt zudem vertiefte Kenntnisse in der Planung von Softwarearchitekturen voraus. Aus diese Gründen erscheint es hier als pragmatischste und sicherste Lösung, auf das beschriebene System aus den Sommersemester 2008 zurückzugreifen und sich auf die Generierung von CSL-Scrips zu beschränken. 5.2 Beschreibung des Projektes Auf Basis der zuvor beschriebenen Anforderungen, erscheint die Implementierung einer Pipeline zur Erstellung und Verarbeitung von analytischen Kollisionskörpern am sinnvollsten. Im Gegensatz zu Meshes werden solche parametrisch beschriebenen Körper, wie Quader, Kugeln, Zylinder von Maya und anderen DCC-Tools typischerweise nicht unterstützt. Sie kommen jedoch häufig bei Echtzeit Physiksimulationen und damit in Spielen zum Einsatz, da sie gegenüber Kollisionsmeshes deutliche Preformancevorteile bieten. Das anfangs beschriebene Vorgehen, solche Quader durch die entsprechende Skalierung von Polygonwürfeln zu platzieren, erweist sich in der Anwendung als sehr umständlich und ungenau, weshalb sich eine Unterstützung entsprechender Körper und geeignete Tools zur Platzierung in jedem Fall als praktisch erweisen sollten. Die dazu implementierten Szenenelemente erfordern gleichzeitig eine Anpassung des verwendeten COLLADA-Exporters, wohingegen eine Erweiterung des Formates selbst nicht notwendig ist, da die entsprechenden Elemente durch das Physik-Profil von COLLADA abgedeckt sind. In der anschließenden Weiterverarbeitung durch Conditiner müssen, wie gefordert, keine Geometrie- oder Animationsdaten konvertiert werden. Es genügt stattdessen das Auslesen von Position, Ausrichtung und Dimensionen der Kollisionskörper, welche schließlich als CSL-Script exportiert und von der Engine eingelesen werden können Maya Plug-In für Kollisionskörper Die Integration der analytischen Kollisionskörper erfolgt mittels der Maya API in C++. Zwar stellt das, relativ neue, Python-Binding praktisch den gleichen Funktionsumfang bereit, jedoch bietet C++ wegen des Geschwindigkeitsvorteils, zumindest im Hinblick auf komplexere Integrationen, das realistischere Anwendungsbeispiel.

62 5. Projektarbeit Maya im Überblick Die Beschreibung des implementierten Plug-Ins erfordert zunächst einige Grundlagen über die Architektur von Maya: Der Dependency Graph (DG) stellt die zentrale Datenstruktur von Maya dar. Alle Daten werden dabei als Attribute der verschiedenen Nodes dieses Graphen verwaltet, und lassen sich, ihres Typs entsprechend, in praktisch beliebiger Weise verknüpfen, wobei die Nodes entweder als reine Container für Daten (beispielsweise verschiedene Einstellungen) dienen, oder entsprechende Eingangsattribute verarbeiten und die Ergebnisse als Ausgangsattribute zur Verfügung stellen. Dieses Prinzip gilt dabei nicht nur für Basisdatentypen, sondern auch Meshdaten und ähnliches werden als Attribute verwaltet und lassen sich entsprechend verknüpfen. Neben dem DG verwaltet Maya zudem den hierarchischen DAG (Directed Acyclic Graph), welcher die Elemente der 3D-Szene enthält. Die hier enthaltenen DAG-Nodes sind zwar ebenfalls Teil des DG und lassen sich mit dessen Elementen verknüpfen, befinden sich aber zudem in der hierarchischen Baumstruktur der Szene und unterliegen so der Vererbung von Transformationen. Dabei besitzen die tatsächlich sichtbaren Shape-Nodes (Meshes, NURBS, Lichter etc.) keine eigenen Transformationsattribute, sondern haben stets mindestens ein Transform-Node als Parent (im Falle von mehreren Parents entspricht dies einer mehrfachen Instanziierung in der Szene) Implementierung des Plug-Ins Das Plug-In basiert im Wesentlichen auf dem DAG-Node gapphysicsshape, welcher, wie der Name andeutet, ein Shape-Node darstellt. Dieser Node stellt über ein Enum-Attribut (welches wie in C++ eine Zuordnung zwischen Namen und Ganzzahlen erlaubt) eine Auswahl von verschiedenen analytischen Grundkörpern und auch Kollisionsmeshes dar, wobei derzeit nur Boxen hinreichend implementiert sind. Daneben enthält der Node sämtliche, zur Beschreibung der Körper, notwendigen Attribute, wie die lokalen Koordinaten des Mittelpunktes, Rotation, Größe, Radius (bei Kugeln), etc. Da allein hiermit jedoch kaum ein Vorteil gegenüber der erwähnten Platzierung durch entsprechende Polygonobjekte gegeben wäre, wurde zudem ein entsprechender Manipulator zur Platzierung und Ausrichtung implementiert. Manipulators sind in Maya Helferobjekte, die temporär in der 3D-Szene angezeigt werden, um Attribute mit Hilfe von graphischen Anfassern zu verändern. Einfache Beispiele sind die in Abbildung 5.1 sichtbaren Move-, Rotateund Scalewerkzeuge, jedoch lassen sich auch nodespezifische Manipulators umsetzen. Solche speziellen Manipulators lassen sich in beide Richtungen mit beliebigen Attributen des entsprechenden Nodes verknüpfen. Auf diese Weise lassen sich nicht nur Eigenschaften des aktiven Objektes verändern, sondern

63 5. Projektarbeit 54 Abbildung 5.1: Move-, Rotate- und Scalewerkzeuge in Maya. Diese sind konzeptionell als Manipulators für Transform-Nodes (im Object-Mode) beziehungsweise Tweak-Nodes (im Component-Mode) zu betrachten. es ist auch möglich, die Manipulators an die Position oder andere Zustände des verbundenen Nodes anzupassen. Die Umsetzung des Box-Manipulators orientiert sich dabei am Box-Tool von ImageModeler 1, bei welchem Quader über ihre Eckpunkte positioniert werden: Die einzelnen Eckpunkte der Box werden nacheinander positioniert und fixiert, wobei die noch freien Punkte stets so ausgerichtet werden, dass die Quaderform erhalten bleibt. Durch die Sperrung der bereits positionierten Punkte, schränken sich dabei die Freiheitsgrade des gerade bearbeiteten Punktes zunehmend ein, bis Größe, Position und Ausrichtung der Box schließlich eindeutig definiert sind und sich somit auch nicht-fixierte Punkte nicht mehr bewegen lassen. In Verbindung mit den entsprechenden Snapping-Funktionen (snap to Vertex) erlaubt dies eine intuitive und schnelle Ausrichtung der Kollisionsobjekte an die sichtbare Levelgeometrie Anpassung des COLLADA-Exporters Da der verwendete OpenCOLLADA 2 -Exporter als Open-Source Projekt vorliegt, gestaltet sich die Anpassung relativ einfach. Beim parsen der Maya- Szene müssen lediglich die richtigen Nodes herausgefiltert und entsprechend weiterverarbeitet werden, wobei sich die verwendeten Klassen und Datenstrukturen an den bereits vorhandenen orientieren können. Als gute Referenz haben sich hierbei Light-Nodes erwiesen, welche ebenfalls geometrielose Shapes darstellen, und auch im COLLADA-Format sehr ähnlich wie Physic-Shapes abgebildet werden. Die einzige, vor allem zeitliche Herausforderung, stellte dabei, die, generell noch fehlende, COLLADA Physics Unterstützung von OpenCOLLADA dar, welche, zumindest in rudimentärem Umfang, implementiert werden musste. Somit war es an dieser Stelle zwar nicht notwendig, eigene Daten ins Format zu integrieren, doch 1 Bild-Basiertes Modeling-Tool von Autodesk ( 2 Mehr Informationen unter