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.

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.

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.).

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.

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.