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?

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.

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

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.