So funktioniert Designdokumentation, Teil 1
Feature

So funktioniert Designdokumentation, Teil 1


Das sogenannte DDD, das Detailed Design Document, ist die Bibel der Spieleentwickler. Zumindest in der Theorie. In der Praxis wird das DDD schon mal als »Staubfänger« verspottet. Ein vermeidbares Schicksal.

Making Games

@ Facebook

Making Games

@ Twitter
comment

Die schlechte Nachricht gleich zu Beginn: Game Designer haben es schwer! Es gibt (noch?) keine Sprache, kein Notationssystem, mit dem sie die Regeln eines Spiels allgemeingültig erfassen können. Wo Komponisten ihre Sinfonien auf Notenpapier für jeden Orchestermusiker verständlich festhalten, sind Gamedesigner (oft am Rande des Nervenzusammenbruchs) emsig damit beschäftigt, kryptische Konzepte auf Notizzettel zu kritzeln oder liebevolle Designerprosa in Telefonbuchstärke zu erstellen. Der Lohn solcher Mühen ist nicht selten ein Kommentar der Marke »Wer soll das alles lesen?«; ein ebenso einleuchtender wie niederschmetternder Einwurf.

Was macht Anno aus? Ein Beispiel für den Einsatz einfacher und unmissverständlicher Symbolik.

Kenne deine Leser!
Damit einem traurige Erlebnisse dieser Art erspart bleiben, sollte man sich als Verfasser von Designdokumenten zunächst über die wichtigste Frage klar werden: Wer wird das Designdokument lesen? Unterschiedliche Leser bedeuten unterschiedliche Anforderungen an ein DDD:

  • Designer: Sie wollen Ideen festhalten und miteinander austauschen.
  • Publisher: Er will -- meist in Gestalt des Producers -- überprüfen, ob Design und Produkt übereinstimmen und den Anforderungen gerecht werden.
  • Programmierer: Sie sehen das DDD als Sammlung von Arbeitsaufträgen und Inhalten, die am Ende der Produktion ein fertiges Spiel ergeben sollen.
  • QA und Testing: Sie wollen alle Regeln und Inhalte des Spiels überblicken und überprüfen, ob sie die erforderliche Qualität und Quantität aufweisen.
  • Outsourcing Partner: Sie wollen schnellen Zugriff auf alle für sie relevanten Infos zur Erstellung zusätzlicher Spielinhalte (z.B. Grafiken, Missionen, Musik etc.).


Komponisten haben ihre eigene universelle Zeichensprache. Davon können Game Designer nur träumen.Das sind eine Menge unterschiedlicher Bedürfnisse und Interessen, die ein einzelnes zentrales DDD kaum stillen kann. Es mag daher sinnvoll sein, spezielle Dokumente neben dem eigentlichen DDD anzufertigen. Doch Vorsicht: Mehrere Dokumente bedeuten immer auch die Gefahr, dass nicht alle ausreichend aktualisiert und gepflegt werden. Nichts ist älter als die Zeitung von gestern? Wer immer dieses Sprichwort erfunden hat, kannte verwaiste Designdokumente nicht.
Im Zweifelsfall sollte man sich bei der Erstellung des DDD an den Bedürfnissen der Programmierer orientieren. (siehe Kasten: Was Designer wissen sollten). Sie sind die größte und wichtigste Adressatengruppe der Game Designer; die Berücksichtigung ihrer Bedürfnisse ist für ein vitales Designdokument überlebenswichtig. Es empfiehlt sich also, die Programmierung bei der Strukturierung und Gestaltung des DDD eng einzubinden. So minimiert man die Gefahr, an denen vorbei zu formulieren, die dem Spiel Leben einhauchen.

Pre-Alpha-Screenshot einer orientalischen Hafeninsel in Anno 1404.

Acht Faustregeln
Die folgenden Regeln helfen dabei, ein Designdokument zu erstellen, das nicht als Briefbeschwerer endet.

Ein nützliches DDD muss …

  • … sich kurz fassen
  • … sein Layout vereinheitlichen
  • … Redundanzen vermeiden
  • … Begründungen von Regeln trennen
  • … Bilder, Diagramme und Flowcharts bevorzugen
  • … Imperativ statt Konjunktiv nutzen
  • … ein verbindliches Glossar enthalten
  • … ständig aktualisiert werden


Regel 1: Kurz fassen. Die wichtigste Regel. So banal sie klingt, so schwer ist es sie zu befolgen. Designer neigen meist dazu, sich umständlich oder unverbindlich auszudrücken. Je komplexer das Thema, desto verworrener oft die Sprache. Es empfiehlt sich daher (gerade zu Beginn der Dokumentation) mit den Adressaten eines Eintrags diesen wiederholt zu besprechen und ihn (und die folgenden) anhand der aufkommenden Rückfragen zu optimieren.

Übersichtliche Illustrationen helfen in Designdokumenten dabei, Botschaften für jeden intuitiv verständlich zu machen. Hier illustriert ein Schaubild die Informationsgewichtung im Spielinterface.

Regel 2: Layout vereinheitlichen. Ein Designdokument benötigt einheitliche Strukturen. Gerade wenn mehrere Designer gemeinsam an einem großen Dokument arbeiten, läuft man Gefahr, Leser durch wechselnde Formatierungen und individuelle Schreibstile zu verwirren. Gemeinsam erarbeitete Formatvorlagen, die hin und wieder auf ihre Sinnhaftigkeit geprüft werden, wirken Wunder. Sie erfordern zwar die Selbstdisziplin aller Beteiligten, erleichtern aber die Lektüre ungemein.

Komplexe Sachverhalte können mittels Diagrammen und Flowcharts besser vermittelt werden.

Regel 3: Redundanz vermeiden. Wiederholungen sind der Feind des Designdokuments. Sie minimieren die Lesbarkeit und lenken vom Wesentlichen ab. Hinzu kommt: Was an zwei Stellen genannt wird, muss auch an zwei Stellen aktualisiert werden. Eine klare Priorisierung von Designinhalten und eine eindeutige Zuordnung zu einzelnen Features helfen, Redundanzen vorzubeugen.

Regel 4: Begründungen von Regeln trennen. Es kann wichtig sein zu begründen, weshalb eine bestimmte Designentscheidung getroffen oder verworfen wurde. Diese Begründungen sollten jedoch nicht mit den Regeln eines Features vermischt werden, um Verwirrung zu vermeiden. Für unsere Anno DDDs verwenden wir dazu beispielsweise FAQs, die am Ende jedes Designeintrags die wichtigsten Begründungen, Alternativen oder Problemstellungen mit einer Frage und einer dazugehörigen Antwort erfassen. (siehe Kasten: Anno Standarddesigneintrag)

Regel 5: Bilder sagen mehr als Worte. Fließtext ist immer die schlechteste Lösung. Ist er nicht zu vermeiden, unbedingt auf übersichtliche Formatierungen achten! Ansonsten empfiehlt es sich, bei jeder Gelegenheit auf bessere Instrumente zurückzugreifen, seien es Listen, Tabellen, Diagramme oder Illustrationen. Sie können schneller erfasst werden und helfen dabei komplexe Inhalte anschaulich darzustellen.

Regel 6: Imperativ statt Konjunktiv. Der Konjunktiv hat in einem Regelwerk nichts verloren. Er unterminiert die Aussagekraft des Designs. Die Verbindlichkeit von Regeln, die mit »sollte, könnte, würde« oder »hätte, wäre, wenn« garniert sind, geht gegen Null. Auch Wörter wie »eventuell« und »vielleicht« haben in einem DDD nichts verloren. Das Design wirkt auf Leser sonst unsicher und austauschbar. Stattdessen: Imperativ verwenden! (Und nicht: »Stattdessen könnte man auch den Imperativ verwenden.«)

Pre-Alpha-Screenshot einer Anno-1404-Metropole mit einem im Bau befindlichen Kaiserdom, eine der wichtigsten Neuerungen im Spiel.

Regel 7: Das Glossar nicht vergessen. Jedes Designdokument benötigt ein aktuelles und dem Team vertrautes Glossar. Zwei Namen für ein und dieselbe Sache sind zwar allzu menschlich, aber auch die natürlichen Feinde reibungsloser Kommunikation (Beispiel: »Ist die Grafik vom fliegenden Schloss schon geliefert worden?« »Keine Ahnung, aber gestern ist das schwebende Schloss rein gekommen.« »Hm… ist das dasselbe?«).

Regel 8: Ständige Aktualisierung. Ein Designdokument, das nicht fortlaufend aktualisiert wird, wird unweigerlich nutzlos. Auch wenn es im fortschreitenden Produktionsprozess einen hohen Kraftaufwand bedeutet, ist es unerlässlich, dass das DDD stets die aktuellste Informationsquelle bleibt und nicht vom Flurfunk abgelöst wird. Im Fall des Scheiterns wird das DDD ein Schattendasein als ungeliebtes Mauerblümchen fristen und hilflos dem Chaos beiwohnen, das unweigerlich beginnt sich auszubreiten. Dieser letzte Satz war übrigens schlecht strukturiert und stilistisch schauderhaft -- mit Absicht. Er ist ein typisches Beispiel ausufernder Designerprosa. Für Programmierer wäre ein knappes (aktuelles DDD = Ordnung) > (veraltetes DDD = Chaos) besser gewesen.

Word, Wiki oder was?
Welche Hilfsmittel man einsetzt, um Design zu dokumentieren, hängt vom jeweiligen Projekt und den Leuten, die das Dokument lesen und bearbeiten sollen, ab. Für Anno haben wir uns zum Beispiel frühzeitig für eine Designdokumentation mittels eines firmeninternen Intranets (Wiki) entschlossen. Im Laufe der Jahre hat sich diese Entscheidung insbesondere wegen der Komplexität und des Umfangs der Anno-Reihe sowie der hohen Akzeptanz durch das Team als richtig erwiesen.

Die größten Vorteile des Intranets sind für uns, dass …

  • … übersichtliche Layouts leicht zu erstellen und zu verwalten sind.
  • … Einträge miteinander verlinkt werden können.
  • … jede Version eines Designeintrags jederzeit wieder hergestellt werden kann.
  • … alle Versionen eines Eintrags miteinander verglichen werden können.
  • … Einträge abonniert werden können, so dass man bei Aktualisierungen per Mail benachrichtigt wird.
  • … Einträge wie in Foren von jedem Nutzer kommentiert werden können. … Bilder, Galerien, Musiken und Filme leicht zu integrieren sind.

Was aussieht wie unbeholfenes Gekritzel eines Fünfjährigen ist in Wirklichkeit das Ergebnis eines wilden Brainstormings zwischen Game Design und Programmierung.


Der größte Nachteil des Wikis ist seine Tendenz zu wuchern und dadurch zu einem undurchdringlichen Dickicht zu werden. Diese Eigenschaft hat das Intranet von seinem großen Bruder, dem Internet, geerbt. Nur die Selbstdisziplin der Nutzer und die weiter oben angesprochene Vereinheitlichung des Layouts können diesem schleichenden Drang Einhalt gebieten. Eine erträgliche Pflicht, gemessen an den Vorteilen.
Natürlich können Designdokumente auch auf jede andere erdenkliche Art und Weise verfasst werden, wenn sie die Bedürfnisse ihrer Leser abdecken und den grundlegenden Anforderungen an ein DDD gerecht werden. Ob mit Windows verwaltet oder auf Butterbrotpapier gemalt: Am Ende zählt nur, ob die Verfasser und die Leser des Designdokuments ihr DDD lesen und verstehen, hegen und pflegen. Ist dies der Fall, werden eine reibungslosere Produktion und ein besseres Spiel die Folge sein.
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«.