Game Design Document Vorlage: Eine Seite statt 40 Seiten

Du brauchst eine Game Design Document Vorlage, die auf eine Seite passt und erst dann wächst, wenn das Spiel es verdient. Starte mit sieben Blöcken: Pitch, Core Loop, Spielerverben, Welt, Systeme, Umfang und offene Fragen. Fülle sie an einem Abend aus. Streiche alles, was du diesen Monat nicht in einem Prototyp testen kannst. Der Rest dieses Beitrags ist die Vorlage selbst, dazu die Teile, die die meisten Anleitungen auslassen.

Warum die meisten Game Design Documents die zweite Woche nicht überleben

Stell dir das 40-seitige GDD vor. Schönes Deckblatt, ein Inhaltsverzeichnis, ein Lore-Kapitel, das niemand bestellt hat. In der zweiten Woche ist der Prototyp abgedriftet, und das Dokument ist ein Fossil.

Das ist der eigentliche Fehler. Nicht fehlende Kapitel, sondern eine Datei, die aufhört, wahr zu sein. Ein GDD ist ein Arbeitswerkzeug, eher ein Changelog als eine Bibel. Wenn Dokument und Build sich widersprechen, verliert das Dokument, und irgendwann öffnet es niemand mehr.

Die Frage lautet also nicht "Was muss ein Game Design Document enthalten?", sondern "Was ist das kleinste Dokument, das ich tatsächlich ehrlich halte?"

Die einseitige Game Design Document Vorlage

Kopier diese Gliederung. Jeder Block bekommt zwei bis fünf Zeilen, beim ersten Durchgang nie mehr.

1. Pitch. Ein Satz, den ein Fremder weitererzählen kann. "Eine Koop-Hafenstadt, in der die Flut jede Nacht die Karte neu schreibt."

2. Core Loop. Was der Spieler immer wieder tut, in unter einer Minute. Zeichne ihn als Kreis aus Verben.

3. Spielerverben. Fünf bis acht Aktionen. Keine Features, sondern Verben: klettern, handeln, verstecken, forken, reparieren.

4. Welt. Ort, Stimmung, drei Regeln, die immer gelten. Wetter zählt als Regel.

5. Systeme. Die zwei oder drei Mechaniken, die die Verben spannend machen. Wirtschaft, Schleichen, Crafting, was auch immer den Loop trägt.

6. Umfang. Was erscheint, was gestrichen wird, was ein Stretch-Ziel ist. Neben jedem Punkt ein Datum.

7. Offene Fragen. Die ehrliche Liste dessen, was du noch nicht weißt. Dieser Block ist der wertvollste auf der Seite.

Auffällig fehlt: Monetarisierung, Marketingplan, ein Kapitel zur Figurenbiografie. Die gehören in eigene Dateien, geschrieben dann, wenn der Prototyp den Loop bewiesen hat. Die meisten veröffentlichten Vorlagen fangen genau damit an, und genau deshalb werden diese Dokumente nie fertig.

Wenn ein Team Freigaben braucht, ist eine längere Struktur sinnvoll. Der GitBook-Leitfaden zum Schreiben eines Game Design Documents beschreibt die klassische Kapitelliste. Sein Rat, mit einer einseitigen Version zu starten und Details nach den Prototypen zu ergänzen, ist der richtige Instinkt.

Was ein Core-Loop-Abschnitt wirklich sagen sollte

Lass Adjektive weg. Schreib den Loop als Satz mit einer Uhr darin.

40 Sekunden Schrott sammeln -> Bergung zum Pier bringen -> gegen ein Upgrade tauschen -> Flut verschiebt sich, Karte ändert sich -> wiederholen

Lies es laut vor. Wenn ein Schritt tot wirkt, hast du deine erste Prototyp-Aufgabe gefunden. Wenn jeder Schritt gut klingt, du aber nicht sagen kannst, warum der Spieler zurückkommt, fehlt dem Loop ein Grund. Schreib das als offene Frage auf, statt es in Prosa zu vergraben.

Ein Test, den ich mag: Der Loop-Satz muss in eine einzige Textzeile passen. Braucht er einen Absatz, sind es zwei Loops, und du entwirfst zwei Spiele.

Welche Abschnitte kannst du ohne Bedauern streichen?

Sei gnadenlos. Ein Solo- oder Zweierprojekt kann am ersten Tag meist diese Teile weglassen:

• Vollständige Figurenbiografien. Behalte Name, Wunsch und Schwäche. Mehr schreibst du, wenn die Figur im Build auftaucht.

• Detaillierte Levelbeschreibungen. Beschreibe Leveregeln, keine Räume.

• Plattform- und Monetarisierungskapitel. Parken, bis der Loop funktioniert.

• Art Bible. Drei Referenzbilder und eine Palette. Mehr nicht.

Anders ist es bei einem Jam-Spiel mit 72 Stunden Zeit: Pitch, Loop und Verben sind dann dein ganzes Dokument. Die volle Liste lohnt sich, wenn du einen Publisher hast, einen Konsolen-Zertifizierungsweg oder Mitarbeitende, die dich um Mitternacht nicht fragen können.

Die Unity-Vorlage für ein Game Design Document als PDF ist eine gute Referenz dafür, wie Mechaniken und Objektverhalten aufgeschrieben werden, sobald ein Team dabei ist. Lies sie als Katalog, nicht als Checkliste.

Wo bewahrst du das Dokument auf?

Dort, wo du es täglich bearbeitest. Das klingt trivial, bis man sieht, wie viele GDDs in einer PDF leben, die niemand vergleichen kann.

Nimm ein Tool mit Überschriften, einer Datenbank für Aufgaben und Versionsverlauf. Eine notizbasierte App mit Datenbank funktioniert gut, weil sich offene Fragen und Umfangsliste als verfolgte Einträge führen lassen, statt als Stichpunkte, die verrotten.

Markdown im Repository ist die andere gute Antwort. Es liegt neben dem Code, lässt sich sauber vergleichen, und beim Pull Request vergisst niemand, es zu aktualisieren. Der Nachteil: Nicht-technische Teammitglieder fassen es nicht an.

Egal, wofür du dich entscheidest: Setz die Einseitenversion nach oben und verlinke auf tiefere Dateien. Die Seite ist die Karte. Die Dateien sind das Gebiet.

Verändert deine Engine, was du aufschreibst?

Ein bisschen, ja. Die Engine entscheidet, welche Verben billig und welche teuer sind. Deshalb sollten Systeme- und Umfangsblock das klar benennen.

Bei einer großen 3D-Engine mit umfangreicher Asset-Pipeline braucht der Umfang eine Zeile pro Asset-Kategorie, denn Content ist der Ort, an dem Zeitpläne sterben.

Wenn du eine Open-Source-Engine ohne Lizenzrechnung willst, wird dein Umfangsblock einfacher: keine Lizenzzeile, dafür eine ehrliche Notiz, welche Features du selbst baust.

Und ist das Spiel 2D mit engen Mechaniken, trägt der Loop-Abschnitt fast alles. Kleine, lesbare Dokumente passen zu kleinen, lesbaren Spielen.

Es geht nicht darum, hier einen Sieger zu küren. Die Zeile "Engine und Werkzeuge" ist keine Wegwerfzeile. Sie sollte auflisten, was die Engine leicht macht, was sie schmerzhaft macht und was du nicht bauen willst.

Wie schreibst du ein GDD für eine Welt, die sich selbst generiert?

Genau hier klaffen fast alle Vorlagen eine Lücke. Sie gehen davon aus, dass du jeden Baum von Hand platzierst.

Wird eine Welt aus einem Prompt erzeugt, ändert sich die Form des Dokuments. Du beschreibst keine Räume mehr, sondern Randbedingungen: Was in jeder Welt gelten muss, die die Engine erzeugen kann, und was variieren darf.

Ergänze die Einseitenversion um zwei Blöcke:

• Weltbedingungen. Die Regeln, die nie brechen dürfen. "Jede Siedlung hat Wasser in zwei Gehminuten." "Keine Questorte in Sackgassen."

• Prompt-Seeds. Die exakten Prompts, die du verwendet hast, als Teil des Dokuments gespeichert.

So sieht ein Seed in der Praxis aus:

ein nebliger Hafenort bei Ebbe, ein Leuchtturm, schmale Treppen, Seilbrücken zwischen Dächern, noch niemand zu sehen

Speicher den Prompt, speicher, was zurückkam, und notiere, was du forken würdest. Der Prompt ist gleichzeitig deine Spezifikation und dein Changelog. Forke ihn, ändere eine Sache, schau, was passiert, und schreib dann das Delta ins Dokument. Diese Gewohnheit macht aus einer generierten Welt etwas, über das du nachdenken kannst, und deinem Team gibt sie etwas Konkretes zum Kritisieren statt eines Gefühls.

Eine Warnung: Die Qualität der Generierung schwankt stark zwischen Tools, und manche Funktionen sind branchenweit noch in der Beta. Notiere Version und Datum neben jedem Seed, damit du weißt, ob ein Ergebnis wiederholbar ist oder nur ein glücklicher Wurf.

Ein schneller Test des Loops, bevor du mehr schreibst

So würde ich an einem Abend mit einer frischen Idee vorgehen.

1. Schreib die Einseitenversion in 30 Minuten. Bearbeite sie danach nicht mehr.

2. Mach aus Pitch und drei Weltregeln einen Prompt und generiere einen ersten Durchgang des Raums.

3. Geh den Core Loop in diesem Raum durch, von Hand oder in einem groben Prototyp.

4. Markiere jeden Schritt, der sich tot anfühlte. Die kommen in die offenen Fragen.

5. Streich ein Verb. Immer ein Verb.

Den Schnitt überspringen die Leute am ehesten. Ein Designdokument, das nur wächst, ist eine Wunschliste. Ein gestrichenes Verb zwingt die übrigen, mehr zu tragen, und zeigt meist, welches System wirklich Arbeit leistet.

Wenn du beim Schneiden hängst, lies den Loop-Satz noch einmal laut und frag dich, welches Verb du am wenigsten vermissen würdest. Die Antwort ist fast immer ein Verb, das du aus Gewohnheit eingebaut hast und nie wirklich benutzt.

Wie hältst du das Dokument nach der zweiten Woche lebendig?

Drei Gewohnheiten, keine davon heroisch.

Datiere jede offene Frage. Ist eine Frage älter als drei Wochen und noch offen, beantworte sie oder gib zu, dass du ihr ausweichst.

Aktualisiere das Dokument in derselben Sitzung wie den Build. Nicht später. Später entsteht das Fossil. Eine Zwei-Zeilen-Änderung am Ende einer Session kostet eine Minute.

Führe eine Liste "verworfene Ideen" am Ende. Sie verhindert, dass du jeden Monat dieselbe Mechanik neu diskutierst, und es motiviert erstaunlich, zu sehen, wie viel du durch Nein-Sagen geschafft hast.

Wenn jemand neu ins Projekt kommt, gib ihm zuerst die Einseitenversion und beobachte, wo er stolpert. Jede verwirrte Frage ist eine fehlende Zeile im Dokument.

Was würden wir tatsächlich nutzen?

Allein oder zu zweit reichen die siebenblockige Einseitenversion und eine Liste mit Prompt-Seeds für den ersten Monat. Mit einem Team hältst du die Einseitenversion als Eingangstür und ergänzt getrennte Dateien für Systeme und Content, sobald der Prototyp sie rechtfertigt. Hast du einen Publisher, gib ihm die lange Version, behalte aber die Einseitenversion als die, der du vertraust.

Öffne heute Abend eine leere Seite und schreib den Pitch. Ein Satz. Dann den Loop, mit einer Uhr darauf. Setz das Datum daneben, dann siehst du beim nächsten Öffnen, wie lange die Idee schon liegt. Wenn du das in einer halben Stunde nicht schaffst, ist die Idee noch ein Traum. Das zu wissen, bevor du einen Monat investierst, ist nützlich.