So funktioniert Designdokumentation, Teil 2
comment
Feature

So funktioniert Designdokumentation, Teil 2


Das sogenannte DDD, das »Detaillierte Designdokument«, bildet die Grundlage jeder professionellen Spielentwicklung. Welche Informationen muss es bereitstellen, welche Fragen beantworten?

Making Games

@ Facebook

Making Games

@ Twitter

Nachdem wir uns im ersten Teil dieser kurzen Reihe über Designdokumentation mit formalen Aspekten beschäftigt haben, geht es diesmal um die konkreten Inhalte eines typischen Designdokuments für Computerspiele. Die Ansichten, wie differenziert Inhalte in einem Designdokument definiert werden sollen, gehen im Einzelfall weit auseinander. Die folgenden Beispiele verdeutlichen, welche Gefahren bei der Missinterpretation von Designdokumentation auf Entwickler lauern.

Zwei abschreckende Beispiele
Designer Nr. 1, nennen wir ihn der Einfachheit halber den »Visionär«, steht dem gesamten Team sehr nah, manche sagen auch, auf den Füßen. Er hat jeden Tag neue Ideen, die das Spiel nach vorne bringen sollen und teilt diese den anderen bevorzugt im persönlichen Monolog mit.
Ein Designdokument existiert. Zumindest wird das vermutet. Gesehen, geschweige denn gelesen, hat es noch niemand. Dabei lagern auf dem PC des Visionärs zwei halbseitige .txt Dokumente, die er bei Gelegenheit fortführen will. Da ist es, sein »Designdokument«.
Designer Nr. 2 vom Typus »Theoretiker« ist da ganz anders. Er hat alles genau geplant. Sein Designdokument erblickte nach monatelanger einsamer Forschungsarbeit das Licht der Welt. Es ist ebenso umfangreich wie unübersichtlich. Ein Mitarbeiter, der es ausdrucken wollte, musste fünfmal Papier nachfüllen und schließlich die Druckerpatronen wechseln. Niemand hat es geschafft, das monumentale Werk des Theoretikers ganz zu lesen, aber alle sprechen in Ehrfurcht davon. Es leistet wertvolle Dienste als Sichtschutz, Fußschemel und Monitorsockel.
Diese abschreckenden Beispiele sind natürlich ein wenig übergespitzt, weisen aber im Kern auf die fundamentale Herausforderung für Designer hin: Ein DDD besitzt nur dann einen Nutzen, wenn die Menschen, die mit ihm arbeiten, darin finden, was sie suchen. Ein oberflächliches Designdokument ist ebenso wertlos wie ein überbordender Paragraphendschungel.

Concept Art für Anno 1404. Der final designte Raubritter, nach dessen Vorbild dann in der Produktionsphase ein animiertes 3D-Modell erstellt wird (Illustration: Ingo Römmling).

Die perfekte Dokumentation
Je nachdem wie ein Entwicklerteam und seine Umgebung strukturiert sind und um welche Art von Spiel es sich handelt, können Inhalte und Aufbau des DDD stark variieren. Wie im ersten Teil dieser Artikelserie (Making Games Magazin 04/08) bereits ausführlich erläutert, kommt es darauf an, die Ziele der Produktion, die Eigenheiten des Spiels und die Bedürfnisse der Teammitglieder genau zu kennen und die Dokumentation in enger Absprache zu planen.
Es gibt keine allgemeingültige Methode zur Erstellung der perfekten Dokumentation. Das bedeutet im Umkehrschluss aber nicht, dass Designdokumentation beliebig ist. Im Folgenden finden sich Themenbereiche und inhaltliche Fragen, die jedes Designdokument auf angemessene Weise klären sollte.

Der allgemeine Aufbau
Der grundlegende Aufbau des DDD kann in sieben große Blöcke unterteilt werden. Auch wenn der Aufbau des Designdokuments von dieser Einteilung im Einzelnen abweichen sollte, die Inhalte für die diese Blöcke stehen, müssen im DDD ausreichend erfasst werden, wenn es vollständig sein soll. Man unterscheidet:

  • Grundlagen
  • Spielregeln
  • Spielinhalte
  • Interface
  • Grafik
  • Sound
  • Tools

Auszug aus dem Grafik-Styleguide von Anno 1404. Ein Beispiel für die Darstellung von Spielinhalten (hier Zivilisationsstufen) in Designdokumenten.

Je nach Spiel können diese Blöcke unterschiedlich stark ausgeprägt sein. Es gibt z.B. Spiele mit einfachen Spielregeln, aber dafür zahllosen Spielinhalten (Assets). Dann gibt es Titel mit sehr komplexen Regeln aber relativ wenigen Inhalten. Ein gutes Designdokument trägt diesen Unterschieden Rechnung und passt den Ausarbeitungsgrad der einzelnen Designblöcke den jeweiligen Erfordernissen an.

Grundlagen
Als Grundlagen eines Spiels werden alle Rahmendaten sowie strategische und spieltheoretische Aspekte bezeichnet. Viele dieser Punkte können bereits vor der Erstellung des DDD in einem Grobkonzept behandelt worden sein, so etwa die Frage nach dem Genre, der Plattform, der Engine, den Hardware-Voraussetzungen, der Zielgruppe und der so genannten USPs (»Unique Selling Propositions«, also die wichtigsten originären Eigenschaften des Spiels, mit denen es am Markt platziert werden soll). Bei der Fortsetzung einer Spielserie oder einem Franchise Produkt (z.B. einer Filmadaption) kommt noch die so genannte Brand-DNA hinzu, die die unverrückbaren Eckpfeiler der jeweiligen Marke genau definiert.
Zentrale Bedeutung für die Grundlagen hat vor allem das so genannte »Mission Statement«. Es definiert in klaren Worten die Vision des Spiels: Welche Ziele werden angestrebt? Um was für ein Spiel handelt es sich? Was ist das Besondere daran? Je eindeutiger das »Mission Statement« verfasst ist, desto einfacher lassen sich die sechs folgenden Designblöcke davon ableiten. Um es zu vertiefen, empfiehlt es sich, Spielflussbeschreibungen aus Spielersicht oder aus Perspektive der zentralen Spielfigur zu erstellen. So lassen sich emotionale Aspekte und Stimmungen deutlicher herausarbeiten.
Ein weiterer grundlegender Aspekt, der in Designdokumenten manchmal vernachlässigt wird, ist die theoretische Basis des Spiels. Lässt sich der Spielverlauf in Phasen unterteilen? Wie verläuft die Lernkurve des Spielers? Welche Spielertypen werden wie angesprochen? Wie kommt im Spiel der so genannte »Gameflow« auf? Und ganz wichtig: In welchem Verhältnis stehen Herausforderungen und Belohnungen zueinander?

Auszug aus dem Inselguide der Designdokumentation von Anno 1404. Da Inseln zu den wichtigsten Assets gehören, werden sie erst konzipiert, bevor sie gebaut werden.

Spielregeln
Die Beschreibung der Spielregeln umfasst alle im Spiel vorkommenden Features. Sie klärt Funktionsumfang und Ablauf eines Features (Merkmal des Spiels), nicht die einzelnen Assets (Inhalt des Spiels).
Ein Beispiel: Wenn eine Spielfigur Ausrüstungsgegenstände anlegen kann, sollte in den Spielregeln u. a. erfasst werden, welche Wirkungen diese Gegenstände besitzen (Modifikation von Eigenschaften der Spielfigur, Veränderung des optischen Erscheinungsbildes etc.) und nicht welche einzelnen Ausrüstungsgegenstände im Spiel vorkommen können (rote Weste, gelbe Weste, karierte Weste etc.).
Der Grund für diese Unterscheidung: Spielregeln sind komplexer als die Assets und benötigen daher eine andere Form der Dokumentation (z.B. Flowcharts, Diagramme etc.). Sie sind die Grundlage auf der die einzelnen Assets basieren. Während letztere naturgemäß häufig aktualisiert werden, sind die Spielregeln stabiler und benötigen weniger Anpassungen.
Wichtige Punkte die innerhalb des Spielregeln-Blocks behandelt werden sollten, sind die Spielphysik, die Spielsteuerung, verschiedene Spielmodi und KI (Künstliche Intelligenz) von Spielgegnern und Spielumgebung: Wie finden Einheiten ihren Weg? Können sich bewegte Objekte durchdringen oder gibt es eine Kollisionsabfrage? Gibt es Tag- und Nachtwechsel in der Spielwelt? Kann sich das Wetter ändern? Welche Bewegungen und Aktionen kann ein Spielercharakter vollführen? Können Computerspielgegner dasselbe wie ihre menschlichen Gegenüber? Wie reagieren sie auf Aktionen des Spielers?
Diese Punkte sind für das Spielerlebnis einerseits und die tägliche Arbeit der Programmierer andererseits relevant. Es ist ratsam, bei der Spezifikation der Regeln Spezialisten aus den Reihen der Programmierer einzubeziehen, ansonsten kann es bei der Umsetzung zu ungewollten Überraschungen kommen, zum Beispiel weil logische Probleme, unklare Ziele oder technische Limitationen nicht ausreichend bedacht wurden.

Auszug aus dem Artbook von Anno 1404. Jedes zu erstellende Asset wird im Artbook genau beschrieben, damit externe Grafiker das entsprechende Concept Artwork erstellen können.

Spielinhalte
Die Spielinhalte umfassen all die Assets, die von Grafikern, Textern, Level- und Gamedesignern erstellt werden müssen, um das Spiel zum Leben zu erwecken und die Regeln mit Inhalt zu füllen.
Je nach Genre und Spieltyp kann es sich dabei um Spielfiguren, Avatare, Einheiten, Gebäude, Gegner, Gegenstände, Ausrüstung, Vegetationselemente oder einzelne Level, Szenarien und Missionen sowie Storytexte, Dialoge, Rätsel oder auch Aufträge handeln.
Dieser Bereich der Designdokumentation wird naturgemäß am häufigsten angepasst und verändert. Daher empfiehlt es sich eine übersichtliche und anpassungsfähige Plattform zu finden, die dem Spielinhalt und den Bedürfnissen des Entwicklerteams angemessen ist. Es kann sich dabei um einfache Word-Dokumente, Excel-Tabellen, MindMaps oder speziell entwickelte Tools wie Quest- oder Text-Editoren handeln. Letztere haben den Vorteil, dass sie zielgenau auf die Bedürfnisse des Spiels abzustimmen sind und die durch sie gewonnenen Daten direkt ins Spiel eingelesen werden können, ohne dass Konvertierungen nötig werden.

Auszug aus dem Grundlagenbereich des DDD. Auch theoretische Aspekte des Spiels werden hier behandelt. Diese Grafik zeigt das Spielprinzip angelehnt an Staffan Björks und Jussi Holopainens Ansatz der Design Patterns.

Interface
Die Dokumentation des Interface beinhaltet alle Komponenten über die der Spieler mit dem Spiel kommunizieren und es steuern kann. Ein so genannter »Styleguide« hilft dabei, die allen Interface-Elementen des Spiels zugrunde liegenden Gestaltungs- und Designprinzipien zu dokumentieren: Wie sind die einzelnen Menüs miteinander verzahnt? Wie ist der Bildschirm aufgebaut? Welche Eingabegeräte (Maus, Tastatur, Gamepad etc.) gibt es und wie funktionieren sie? Wie reagieren Interface Elemente auf Spieleraktionen? Welche Schrifttypen werden benutzt? Welche Farbsprache wird eingesetzt?
Neben den stilistischen Grundlagen sollte auch die Benutzerführung im Spiel explizit erfasst werden: Gibt es Bildschirmtext? Wie sehen die Tooltipps aus? Gibt es kontextsensitive Mausmodi oder spezielle Tastaturbelegungen? Machen Animationen, Effekte oder andere Feedbacks den Spieler auf Handlungsmöglichkeiten und Probleme aufmerksam und wenn ja, wie?
Hinzu kommen alle konkreten Elemente des Hauptmenüs und jener Menüs und Steuerungselemente, die der Spieler im Spiel selbst vorfindet. Um sie zu klassifizieren, wären als Fließtext ausufernde Beschreibungen nötig, die oftmals mehr Fragen aufwerfen als sie beantworten. Es empfiehlt sich daher auf alternative Darstellungsmethoden zurückzugreifen, etwa Flow-Chart-Diagramme, MockUp-Screens, MindMaps, Director- oder Flash-Movies. Mit diesen Methoden lassen sich komplexe Abläufe im User Interface verständlicher darstellen als mit Funktionsbeschreibungen im Fließtext.
Liegen später grafische Entwürfe oder erste Implementierungen im Spiel vor, ist es von Vorteil, aktuelle Screenshots dieser Elemente dem Designdokument anzufügen und nur noch gewünschte Änderungen am aktuellen Layout und der Funktionsweise als Text zu dokumentieren.

Auszug aus dem Interface Styleguide von Anno 1404. Mit einfachen Grafiken lassen sich komplexe Themen wie etwa die stilistische Ausrichtung des Interface für jeden verständlich darstellen.

Grafik
Die Dokumentation des grafischen Designs erfordert ebenfalls einen so genannten Styleguide. Er legt die künstlerische und technische Ausrichtung aller grafischen Elemente fest und dokumentiert, wie Ziele und Besonderheiten des Spiels grafisch umgesetzt werden: Welche Lichtstimmung soll im Spiel herrschen? Wie viel Polygone sollen einzelne Assets besitzen? Welche Emotionen sollen beim Spielen verstärkt oder vermieden werden?
Neben dem grundlegenden Styleguide werden auch alle konkreten Grafikassets erfasst, die Bestandteil des Spiels sind. Der Teil des DDD, der all diese grafischen Elemente definiert, wird oft als »Artbook« bezeichnet. Hier findet man alle Anforderungen an Figuren, Gegenstände, Gebäude, Vegetations- und Terrainelemente, Effekte, Gegenstände, Icons, Intro, Zwischensequenzen, Hintergrundgrafiken und vieles mehr.

Sound
Der Bereich Sound umfasst alle akustischen Signale, denen man im Spiel begegnet. Meist handelt es sich um Musikstücke und Soundeffekte. Auch im Bereich Sound ist ein Styleguide von unschätzbarem Vorteil: Welche Emotionen soll die Musik transportieren? Welche musikalischen Stile finden Verwendung? Gibt es eher kurze Jingles oder lange Hintergrundstücke?
Das System, mit dem Sound und Musik im Spiel gesteuert werden, gehört ebenfalls zu den Fragen, die in diesem Designblock geklärt werden müssen: Wann wird welche Musik abgespielt? Können Musikstücke ein- und ausgeblendet werden? Soll die Musik flexibel auf das Spielgeschehen reagieren? Welche und wie viele Soundlayer gibt es im Spiel und wie werden sie miteinander verwoben?
Schließlich muss der Soundbereich des Designdokuments noch alle quantitativen Fragen klären: Wie viele Minuten Musik benötigt das Spiel? Wie viele und welche Soundeffekte müssen erstellt werden? Gibt es lokalisierbare Sprachausgabe?

Tools
Der Bereich der Tools ist ein eher technischer Aspekt des DDD und von höchster Wichtigkeit. Er klärt, welches Instrumentarium den Entwicklern der so genannten »Content-Abteilungen« (Leveldesign, Gamedesign, Grafik und Sounddesign) bei der Erstellung von Spielinhalten zur Verfügung steht.
Zunächst sollten hier alle benötigten Tools erfasst und ihre Verknüpfungen innerhalb der Toolchain dargestellt werden, damit klar ist wie Daten ins Spiel kommen und welche wechselseitigen Abhängigkeiten es gibt. Dann sollten die einzelnen Tool-Bausteine beschrieben werden: Gibt es Level-Editoren? Einen Text-Editor? Wie werden verschiedene Sprachversionen erstellt? Welchen Leistungsumfang besitzen die Editoren? Wie bedient man sie?
Zuletzt sollten auch alle grundlegenden Anforderungen an neu zu erstellende Tools und Verbesserungswünsche zu bereits existierenden Tools erfasst werden, die seitens der Nutzer absehbar sind. Diese Anforderungen müssen in Folge von den Tool-Programmierern zusammen mit den Nutzern diskutiert und bewertet werden. Was davon ist für dieses Spiel umsetzbar? Wie hoch ist der zu erwartende Nutzen?



Verantwortung teilen
Der kurze Überblick über die sieben grundlegenden Designblöcke macht vor allem eines deutlich: Egal wie effizient und knapp die einzelnen Designeinträge auch verfasst werden, ein detailliertes Designdokument zu erstellen ist immer eine Herausforderung. Diese kann von einem einzelnen kaum bewältigt werden. Aus diesem Grund empfiehlt es sich, die Verantwortung für die einzelnen Blöcke und Einträge mit den jeweiligen Spezialisten und Leads zu teilen. Das Artbook kann von einem Asset-Manager verwaltet werden. Die einzelnen Missionen von den Level-Designern, die sie erstellen. Der Grafik-Styleguide sollte vom Art Director entworfen werden, die Toolchain von den leitenden Programmierern. Nur so lässt sich der Arbeitsaufwand bewältigen und nur so schafft man es, das Wissen des Teams effizient zu nutzen und es in das Design einzubinden.
Bei größeren Projekten und komplexen Dokumentationen kann zusätzlich ein spezieller Game Design Editor hilfreich sein, dessen Aufgabenbereich sich insbesondere auf die Aktualisierung und Pflege der Dokumente erstreckt.
Dirk Riegert

Dirk Riegert
ist Creative Director bei Related Designs.

Dirk arbeitet seit 2002 bei Related Designs und hat dort unter anderem an den Strategietiteln »Castle Strike« und »No Mans Land« mitgewirkt. Von 2004 bis 2009 war er als Lead Game Designer für die Konzeption und die Kommunikation der Spielinhalte von »Anno 1701« und »Anno 1404« verantwortlich. Beide Titel gewannen unter anderem den Deutschen Entwicklerpreis in der Kategorie »Bestes Game Design«.