Assetlisten – und warum sie so wichtig sind

Assetlisten sind immer wieder ein Thema bei Produktionen. Mit überragender Mehrheit eigentlich fast immer dann, wenn sie niemand im Team so richtig geführt oder aktuell gehalten hat. Dabei steckt hier wirklich der Teufel im Detail und nicht selten entscheiden gut gepflegte Assetlisten ganz enorm darüber mit, wie gut eine Produktion und vor allem wie stressig oder nicht stressig sie läuft. Aber was sind Assets eigentlich? Wie benennt man sie anständig? Was sind Assetlisten? Und wie führt man sie gut und hält sie aktuell?

Was ist eigentlich ein Asset?

Fangen wir mal ganz vorne an: Was ist überhaupt ein Asset? Assets sind die ganzen einzelnen Elemente aus denen ein Spiel zusammen gesetzt wird. Das können also beispielsweise sein:

• 2D Grafiken oder Animationen, wie beispielsweise
  • Character Artworks
  • Grafiken von Buttons oder sonstigen User Interface Elementen
  • Hintergrund Grafiken
  • 2D Animationen
• 3D Stuff, wie zum Beispiel:
  • Modelle
  • Animationen
• Sound Effekte, Foleys, Musikstücke
• Voice Files
• usw. usf.

In der Regel braucht man für ein Computerspiel einen Riesenhaufen von unterschiedlichsten Assets. Diese werden entweder intern im Unternehmen durch allerhand Teammitglieder selbst erstellt. Oder sie werden teilweise oder ganz outgesourced. Oder sie werden über einen der verschiedenen Assetstores, wie beispielsweise im Unity Assetstore, quasi fertig von der Stange eingekauft. Aber in jedem Fall müssen diese Unmengen an Assets IMMER irgendwie verwaltet werden.

Wieso muss man Assets in Assetlisten verwalten?

Aber wieso muss man Assets überhaupt verwalten? Kann man die nicht einfach, wenn man sie gerade braucht, anfertigen oder kaufen und sie dann direkt in den Build (den aktuellen Stand des Computerspiels) einbauen und gut? Nun, die kurze Antwort ist: Nein. Das kann man auf gar keinen Fall so machen! 😉

Die etwas längere Antwort ist wie folgt: Bei Computerspielen gibt es nicht selten UNMENGEN an Assets. Und neben der Tatsache, dass man quasi allein schon zwangsläufig aufgrund der puren Masse an Assets mit an Sicherheit grenzender Wahrscheinlichkeit irgendwann den Überblick verliert, bringt diese Masse auch noch ein paar andere Herausforderungen mit sich, die wir uns im folgenden anschauen.

Die richtigen Assets

Zunächst ein mal müssen ganz trivial überhaupt die richtigen Assets hergestellt werden. Klingt einfach? Isses in der Praxis aber oft nicht wirklich. Denn welche Assets genau produziert werden müssen und wie die auszusehen haben, muss überhaupt erst mal von jemandem festgelegt werden. Und das sollte dann nicht nur möglichst konsistent mit dem Game Design und der Story sein. Sondern die Assets müssen auch reibungslos mit dem Code und dem Gameplay funktionieren. Wir haben hier also gleich drei relevante Faktoren:

1. Welche Assets werden gebraucht?
2. Welche Anforderungen müssen diese Assets inhaltlich und narrativ erfüllen?
3. Welche Anforderungen müssen diese Assets funktionell erfüllen?

Welche Assets werden gebraucht?

Welche Assets gebraucht werden, ergibt sich in der Regel aus dem Game Design Document. Also jenem Dokument das bis ins Detail festlegt, um was für ein Spiel es sich handelt und wie es funktioniert. Komplizierter wird das ganze dadurch, dass die Entwicklung von Spielen selbst mit der besten Planung immer ein in gewissem Umfang iterativer Prozess ist. Das heißt, man muss Spiele aufgrund ihrer hochkomplexen und interaktiven Natur immer wieder testen. Und dann muss man gegebenenfalls aufgrund der Erkenntnisse Änderungen vornehmen. Und diese Änderungen können dann auch immer wieder Auswirkungen auf die benötigten Assets haben.

Welche Anforderungen müssen Assets inhaltlich und narrativ erfüllen?

Die Assets eines Computerspiels sind quasi die direkte Umsetzung dessen, was Game Designer und Writer im Game Design Document entwickelt haben. Logischerweise sollten diese Assets also so gut wie irgend möglich die Vision des Spiels abbilden. Das Ziel ist, am Ende ein kohärentes Gesamtbild aus Game Design, Narrative und den ganzen vielen Assets zu haben.

Zu diesem Zweck werden für die Assets idealerweise gute Art Descriptions geschrieben. Diese müssen nicht unbedingt lang sein. Sie müssen aber eben alles enthalten, was das jeweilige Asset leisten muss. Wenn der Held ein Schwert braucht, muss das in der Art Description stehen. Wenn er irgendwie shady aussehen soll, auch. Erst dann kommt der ganze Prozess der Asset-Erstellung mit Briefing, Feedback und schließlich Abnahme, der von einem Art Director, Creative Director oder dem Game Designer betreut wird. So wird sichergestellt, dass bei den Assets am Ende auch wirklich das dabei raus kommt, was das Game Design oder das Writing braucht.

Welche Anforderungen müssen Assets funktionell erfüllen?

Auch funktionell und technisch müssen Assets je nach Projekt konkrete Anforderungen erfüllen. An dieser Stelle lohnt sich tatsächlich zu Beginn des Projekts der ein oder andere Call zusammen mit dem Art Director und dem Technical Director (oder den Menschen, die diese Aufgaben im Team übernehmen), um eine konkrete Liste an Anforderungen zusammen zu schustern, sehr.

Hierbei spielen – ohne ansatzweise Anspruch auf Vollständigkeit zu erheben – Fragen eine Rolle, wie:

• Welches Dateiformat müssen die Assets haben?
• Welche „Auflösung“ dürfen sie maximal haben, wie groß dürfen die Dateien maximal sein?
• Müssen Animationen beispielsweise in bestimmte Abfolgen zerteilt sein, damit sie optimal genutzt werden können?
• Audio Files Stereo oder Mono?
• Welche Techniken, Tools und Methoden dürfen verwendet werden?
• usw. usf.

Das richtige Asset zur richtigen Zeit

Und wäre das nicht alles genug, muss auch noch sicher gestellt werden, dass die richtigen Assets zum richtigen Zeitpunkt X fertig sind. Denn ab einer gar nicht so großen Menge an Assets, die eigentlich nahezu jedes Projekt erreicht, müssen die Assets zeitversetzt produziert werden. Denn eine bestimmte Menge an Artists kann eben nur eine bestimmte Menge an Assets zur gleichen Zeit bauen. Und dazu kommt, dass die Assets idealerweise auch zeitversetzt geliefert werden sollten. Denn auch eine bestimmte Menge an Programmierer:innen kann eben nur eine gewisse Anzahl an Assets zur gleichen Zeit in das Computerspiel integrieren.

Zudem müssen viele Assets und die verschiedenen Assettypen auch zuweilen in einer bestimmten Reihenfolge produziert oder eingebaut werden. Denn man kann natürlich nichts animieren, von dem noch gar kein geriggtes Modell existiert.

Der Status der Assets im Produktions Prozess

Abschließend dienen die Assetlisten auch dazu, über die gesamte Produktion hinweg den Überblick über den jeweiligen Status der Assets zu behalten. Sprich: was wurde bereits angefertigt? Was steckt noch mitten im Feedback Prozess? An wem hängt gerade was? Und was fehlt noch komplett? Ein absolut nicht zu unterschätzender Faktor! Denn in der Praxis gibt man als Art Director, Creative Director oder Game Designer gerne mal Hunderte Assets in Auftrag. Für alle oder viele davon schreibt man Art Descriptions, man bekommt Zwischenschritte, gibt (mehrfach) Feedback und muss sie irgendwann final abnehmen. Und am Ende muss man auch irgendwie sicherstellen, dass auch wirklich jedes einzelne Asset produziert wurde und inhaltlich wie technisch funktioniert, und nicht manche vergessen wurden oder irgendwo in einer Feedback-Schleife verreckt sind.

Und wer jetzt sagt, er kann das alles leisten ohne von Anfang an ordentliche Assetlisten zu schreiben: Go for it. Ich lache so lange… 😉

Wie funktioniert das jetzt also mit den Assetlisten?

Das wichtigste ist hier wie bei so vielem anderen vor allem: Anfangen!

Assetlisten von Anfang an mit führen

Der beste Tipp, den ich im Bereich Assetlisten geben kann ist, sie direkt von Anfang an mit zu führen. Deswegen bin ich auch ein großer Fan davon, dass der oder die Game Designer:in – schon bei der Erstellung des Game Design Documents gleich auch sofort die Assetlisten mit anlegt. Und immer wenn er oder sie dann im Design Prozess quasi ein Asset einführt, weil zum Beispiel ein Character eingeführt wurde, trägt er oder sie es direkt in die Liste ein.

Diese Einträge müssen nicht von Anfang an alle Informationen und Beschreibungen enthalten. Es ist nur essentiell DASS die Assets gleich bei Aufkommen auch direkt in die Assetliste eingetragen werden. Denn erstens besteht so die VIEL geringere Gefahr, dass Assets vergessen werden – was echt so richtig Mist sein kann, wenn es passiert. Und zweitens hat man so substantiell mehr Zeit Fehler noch rechtzeitig zu entdecken, sollten doch mal Assets vergessen worden sein. Außerdem hat man so von Anfang an einen transparenten und im Idealfall immer aktuellen Überblick über den Scope, also über den Umfang und das Ausmaß an zu produzierenden oder einzukaufenden Assets.

Wer führt die Assetlisten?

Auch das war schon Bestandteil langer, tiefer und auch mal hässlicher Diskussionen in Teams. Und auch das meist nachdem die Listen nicht richtig geführt worden sind und so zu Problemen geführt haben. Ich persönlich bin wie gesagt ein großer Fan davon, dass der oder die Game Designer:in direkt von Anfang an die Listen anlegt und auch zu großen Teilen langfristig verwaltet. Ganz einfach aus dem Grund, weil im Game Design oder im Writing diese Assets auch eingeführt werden. Und hier entsteht auch die Vision dazu, wie sie aussehen sollen und was sie leisten sollen. Die Assetlisten sollten also idealerweise direkter Bestandteil des Game Design Documents sein.

Aber nicht nur die Game Designer:in ist für top aktuelle und gut gepflegte Assetlisten zuständig. Auch die entsprechenden Leads der anderen Departments sind hier gefragt. Bei visuellen Assets natürlich allen voran der oder die Art Director:in oder der oder die Creative Director:in. Denn das eine sind so die generellen Wünsche des Game Designs. Das andere sind dann wirklich gute Art Descriptions die mit Hinblick auf die Kompetenzen und Möglichkeiten des eigenen Art Teams geschrieben sind und auch die generelle Machbarkeit im Blick haben. Aber auch der oder die Producer:in sowie Technical Director:in oder Lead Programmierer:in sollten regelmäßig einen Blick auf die Assetlisten des Projekts haben. Nicht zuletzt um den Umfang und die Machbarkeit des Projekts im Blick zu behalten… 😉

Wo liegen die Assetlisten?

Assetlisten müssen irgendwo zentral zugänglich für alle Teammitglieder liegen und in einer Tabelle organisiert sein. Das sind im Prinzip die beiden entscheidenden Aspekte. Jede Software, die man dafür nehmen kann, hat so ihre Vor- und Nachteile und das hier erschöpfend mit zu behandeln würde endgültig den Umfang dieses Artikels sprengen. Kurz kann man sagen: Hat man keine gigantischen Mengen an Assets und hat man das Game Design Document wie heute meist üblich in einem Wiki angelegt, macht es Sinn die Listen gleich im Wiki mit zu führen. Hat man gigantische Mengen Assets oder / und kein Wiki für das Game Design Document, bietet sich eine Google Tabelle an. Mein persönlicher Favorit ist derzeit aus diversen Gründen Notion für die Assetlisten. Aber da die meisten meiner Game Design Dokumente in Confluence Wikis liegen und Notion immer kostenpflichtig ist, nutze ich es in der Praxis eher selten.

Welche Assetlisten braucht man und was müssen sie enthalten?

Welche Assetlisten man braucht und was sie enthalten müssen, ist im Detail so unterschiedlich wie die Computerspiele für die sie geführt werden. Man muss sie – wie so vieles im Game Design Document – tatsächlich immer an die Anforderungen des jeweiligen Projekts anpassen. Aber wie schon gesagt: Das wichtigste ist hier wirklich, DASS Assetlisten von Anfang an geführt und aktuell gehalten werden. Der Rest ist dann fast schon Kür 😉

Aber in der Regel braucht man bei Computerspielen mindestens Assetlisten für:

• alle im Spiel vorkommenden Charaktere (Spielfigur, NPCs)
• alle Locations (Orte, wo gespielt wird)
• alle Items (Gegenstände im Spiel)

Und praktisch sind dann oft noch – allein schon um eine gewisse Konsistenz im Design zu erreichen – Asset-Listen für:

• Die User Interface Elemente
• Für alle Sound Effekte
• Für alle sich wiederholenden visuellen Effekte (zum Beispiel der Glow eines zu drückenden Buttons)

Auch welche Informationen eine Assetliste enthalten muss, kommt immer auf das Projekt und die Asset Art an. Sinnvoll sind aber oft zumindest folgende Informationen:

• Die Asset Art (Character, Location, Animation, Sound…)
• Die Asset Beschreibung / die Art Description
• Eventuell die Platzierung / der Einsatzort des Assets im Spiel (Besonders bei Items)
• Ein kleines Bild bei visuellen Assets.
• Die Asset ID, also der einzigartige „Name“ des Assets (siehe unten)

Und das bringt uns auch schon zum letzten Punkt:

Wie benennt man Assets richtig?

Um gute Assetlisten führen zu können, müssen Assets systematisch und konsistent benannt werden. Und zwar von ALLEN im Team und von allen Externen auf die gleiche Weise! Das ist auch wichtig bei der Dateiverwaltung. Weil dann FINDET man die Assets in der Dateiverwaltung oder in Roll Down Menüs auch tatsächlich! …ein nicht zu unterschätzender Vorteil 😉

Darum wie man Assets am besten benennt, sind allerdings schon halbe Glaubenskriege geführt worden. Und man muss klar sagen: Es gibt hier einfach unterschiedliche Möglichkeiten und auch die Benennung der Assets muss immer an die Anforderungen jedes einzelnen Projekts angepasst werden. Was aber unzweifelhaft und unumstößlich wichtig ist, ist DASS Assets systematisch und konsistent mit sogenannten Assetnummern, Assetnamen oder Asset IDs benannt werden! Und dabei müssen folgende Punkte zwingend erfüllt werden:

Zwingende Kriterien für funktionierende Asset IDs

1. Die jeweilige Asset ID darf im gesamten Projekt und gegebenenfalls im gesamten Unternehmen, nur genau ein einziges Mal vorkommen. Auch wenn man gegebenenfalls das Asset später verwerfen sollte, dann wird damit auch die Asset ID verworfen! Und sie wird nie nie nie wieder nicht erneut verwendet! Die Assetnummer gilt von nun an als „verbrannt“.
2. Die Asset IDs dürfen keine Sonderzeichen wie Umlaute oder Punkte enthalten (außer Unterstriche). Diese können von manchen Menschen nicht ohne weiteres geschrieben werden und sie können auch im Code Probleme verursachen.
3. Da Teams mittlerweile öfter international als nicht sind, sollten Asset IDs immer auf englisch benannt werden (außer Eigennamen wie beispielsweise „Berlin“)
4. Einzelne Worte eines Teils der AssetID „trennt“ man am besten (meiner Meinung nach) mit der Pascal case Schreibweise also quasi so: „PascalCaseSchreibweise“.
5. Und verschiedene Teile der Asset ID trennt man mit Unterstrich. Also beispielsweise: „Character_Gandalf_WalkingAnimation“

Und Premium ist jetzt noch, wenn man bereits beim Anschauen der ID mit etwas Hintergrundwissen weiß, um welches Asset es sich dabei genau handelt. Wie man das aber am besten erreicht, ist – ihr ahnt es schon 😉 – umstritten.

Und nicht zuletzt deswegen wird es ab hier jetzt schlicht Geschmacksache. Denn während beispielsweise Menschen, die ich sehr schätze ABSOLUT auf komplett ausgeschriebene Wörter in den Asset IDs schwören (z.B. „LordOfTheRings_Character_Gandalf_AnimationWalking“) und Abkürzungen regelrecht verteufeln, mag ich persönlich die kürzeren AssetIDs mit Abkürzungen (z.B. „LOTR_CH_Gandalf_AN_Walking“) lieber und nehme dafür auch das etwas größere Risiko für Missverständnisse in Kauf.

Was ist also eine gute Asset ID Naming Syntax?

Auch hier gilt wie bei den Assetlisten selbst: Hauptsache es GIBT eine klar definierte, systematische und einheitliche Asset ID Naming Syntax, die jeder im Projekt und jeder Externe wirklich und immer und absolut nutzt! WIE die dann wirklich aussieht, ist dann auch fast schon wieder Kür.

Aber Geschmack hin oder her gibt es meines Erachtens eine wirklich gute Asset ID Naming Syntax, die einfach immer funktioniert:

Asset naming syntax

Erstens alle Regeln oben beachten und dann die Asset ID wie folgt zusammen setzen:

1. ([Lizenz / Produkt]_ Nur falls nötig (!) , also zum Beispiel: LordOfTheRings )
2. ([Welt / Areal]_ → Nur falls nötig (!) , also zum Beispiel: Hobbiton oder Mordor )
3. [Asset Typ]_ → zum Beispiel: Character oder NPC oder Animation oder Sound
4. [Asset Name]_ → zum Beispiel: Frodo oder Gandalf oder WalkingAnimation oder SuccessSound
5. [Number]→ nur wenn nicht anders möglich, weil es beispielsweise 3 nahezu identische Success Sounds gibt am Ende noch dran, zum Beispiel: _01 oder _02

Und das sieht dann zum Beispiel so aus:

LordOfTheRings_Hobbiton_Character_Frodo

Oder aber wenn es sich um die Animation eines Characters handelt zum Beispiel so:

LordOfTheRings_Hobbiton_Character_Frodo_Animation_Walking

Und bei allem Respekt für meine Lieblingsprogger, die das gerne ausgeschrieben mögen und die das auch so bekommen, wenn ich mit ihnen zusammen arbeite. Ich persönlich kürze (wenn ich nicht mit ihnen arbeite 😉 ) das ganze dann wie folgt ab und hinterlege an zentraler Stelle im GDD die Legende für die korrekten Abkürzungen:

LOTR_Hobbiton_CH_Frodo_AN_Walking

There and back again oder auch: Muss das echt sein?

Ja. Das muss wirklich, wirklich, sowas von WIRKLICH echt sein! Was hab ich schon Produktionen in die Grütze gehen, Leute sich die Haare raufen, Teams sich im übelsten Crunch an die Gurgel gehen sehen, weil Assets gefehlt haben, unbrauchbar waren, vollkommen unnötigerweise produziert wurden, verschwunden sind, weil sie wegen mehrfach benutzter Asset IDs überschrieben wurden oder Assets die nicht mehr rechtzeitig fertig wurden. In jedem Fall habe ich in jeder Produktion, wo die Assets nicht richtig mit ordentlichen Assetlisten organisiert wurden, fast immer so viel Geld sinnlos abfackeln, so viel Waste entstehen und so viel unnötige Nerven den Bach runter gehen sehen.

Das braucht einfach kein Mensch!

Das ist wie generell bei einer sinnvollen Planung und Organisation einer Produktion: Macht man direkt am Anfang einfach ein bisschen was richtig und ordentlich, spart es hinten raus so unglaublich viel Zeit, Arbeit, Geld und Nerven. Und wie gesagt: Wenn man so ziemlich direkt am Anfang einfach mal überhaupt definiert, wie Assets generell benannt werden sollen und von Anfang an Assetlisten zur Not irgendwie führt, dann hat man tatsächlich schon 90% richtig gemacht!