Making Games Report - So funktioniert Designdokumentation

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.

Dirk Riegert, Creative Director bei Related Designs: »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.«

Den vollständigen Artikel lesen Sie in einem Special auf makinggames.de

Teil 2 der Artikelreihe »Designdokumentation« finden Sie morgen an dieser Stelle.

Jedes Wochenende präsentieren wir Ihnen ausgewählte Making-Of-Artikel, Reportagen sowie Interviews aus unserem Schwestermagazin Making Games und lassen Sie hinter die Kulissen der Spielebranche blicken.
Und wer könnte besser über die großen und kleinen Geheimnisse der Spieleentwicklung schreiben als die Entwickler selbst? Genau das machen sie jede Ausgabe im Making Games Magazin und jeden Tag auf makinggames.de.

Dieser Artikel erschien in Ausgabe 04/2008 des Making Games Magazins.

zu den Kommentaren (3)

Kommentare(3)
Kommentar-Regeln von GameStar
Bitte lies unsere Kommentar-Regeln, bevor Du einen Kommentar verfasst.

Nur angemeldete Benutzer können kommentieren und bewerten.