Game Design Document Vorlage, die du wirklich öffnest

Eine gute Game Design Document Vorlage passt zuerst auf eine einzige Seite und wächst erst, wenn das Spiel es verdient. Starte mit fünf Blöcken: Pitch, Design-Säulen, Core Loop, Systemliste und offene Fragen. Alles Weitere, von der Lore bis zu den Level-Notizen, kommt dazu, wenn ein Playtest beweist, dass die Mechanik trägt. Unten findest du die Vorlage, die wir für Tabletop- und Indie-Videospielprojekte nutzen, samt den Stellen, an denen jeder Abschnitt zu veralten beginnt.

Warum sterben die meisten Game Design Documents in Woche drei?

Der häufigste Fehler ist Ehrgeiz. Jemand öffnet eine leere Datei, kopiert eine Gliederung mit zwanzig Abschnitten aus einem Forum und verbringt ein Wochenende damit, Kästchen für Mechaniken zu füllen, die noch niemand ausprobiert hat. In Woche drei hat sich das Spiel weiterbewegt, das Dokument nicht. Niemand öffnet es mehr, und niemand gibt das zu.

Game Dev Beginner benennt das Problem in seinem Leitfaden zu GDDs nüchtern: Große, übermäßig detaillierte Dokumente kosten viel Vorarbeit, sind fast immer veraltet und werden hinderlich, solange sich das Design noch verschiebt. Die Lösung ist Stufung. Zuerst eine Seite, dann etwa zehn Seiten, sobald das Spiel Gestalt annimmt, und die vollständige Fassung erst, wenn tatsächlich Inhalte produziert werden.

Für Tabletop-Designer ist das wichtiger als für Videospielteams. Oft bist du gleichzeitig Autorin oder Autor, Systemverantwortliche oder -verantwortlicher und Playtesterin oder Playtester. Niemand wartet auf eine Spezifikation von dir. Das Dokument hat genau eine Aufgabe: dich davon abzuhalten, dir zwischen Sitzung vier und Sitzung vierzig selbst zu widersprechen.

Wenn du allein arbeitest, lass das 40-seitige Template weg. Du wirst es nicht pflegen. Selbst die Standarddefinition nennt ein GDD ein lebendes Dokument. Niemand erwartet, dass es am ersten Tag fertig ist.

Was gehört in eine Game Design Document Vorlage, die man wirklich öffnet?

Fünf Blöcke decken den ersten Monat fast jedes Projekts ab. Halte jeden so kurz, dass du die ganze Seite in zwei Minuten lesen kannst.

1. Pitch. Zwei Sätze. Wer spielt das Spiel, was tut die Person dabei, und was unterscheidet es von dem nächsten Spiel, das sie schon besitzt?

2. Design-Säulen. Drei oder vier Aussagen, an denen jede spätere Entscheidung gemessen wird. "Jeder Kampf kostet etwas Dauerhaftes" ist eine Säule. "Spaßig und fesselnd" ist keine.

3. Core Loop. Das, was die Spielerin oder der Spieler immer wieder tut. Bei einem Dungeon-Crawl ist das vielleicht erkunden, wählen, riskieren, ausgeben. In einer politischen Kampagne eher Intrige, Hebel, Konsequenz, Nachwirkung.

4. Systemliste. Nur Namen, mit je einer Zeile. Zahlen legst du noch nicht fest.

5. Offene Fragen. Der nützlichste Abschnitt der Seite, und genau den lassen Vorlagen oft weg. Schreib auf, was du nicht weißt, und datiere es.

Ergänze am Ende ein Änderungsprotokoll, auch wenn es nur eine Zeile pro Woche ist. Wenn ein Playtest eine Idee streicht, halte die Streichung und den Grund fest. Sonst probierst du sie in drei Monaten wieder aus.

Wie schreibst du Design-Säulen, die ein Argument verlieren können?

Eine Säule verdient ihren Platz, indem sie etwas ablehnt. Wenn du kein Feature nennen kannst, das die Säule verwerfen würde, ist sie nur Dekoration.

Prüfe jede Säule mit einer Streichliste. Nimm die drei Features, an denen du am meisten hängst, und frag bei jedem, welcher Säule es dient. Ein Feature, das keiner Säule dient, wandert auf die Liste "vielleicht später", und diese Liste darf lang sein. Das ist die schwerste Stunde des ganzen Prozesses, und sie ist mehr wert als jeder Abschnitt einer Vorlage.

Ein Beispiel aus einer Kampagnenwelt, in deren Mitte eine Seuche steht. Säule eins: Knappheit ist sichtbar, deshalb wird jede Heilressource am Tisch mitgeführt. Säule zwei: Fraktionen wollen unterschiedliche Heilmittel, also löst kein einzelnes Mittel alles. Säule drei: Die Karte schrumpft, also wird Reisen im Verlauf der Geschichte teurer. Nun kommt der Vorschlag für einen Zauber der Wiederbelebung. Säule eins lehnt ihn ab. Die Entscheidung dauert zehn Sekunden statt vierzig Minuten Debatte.

Wichtig zu wissen: Säulen sind kein Marketingslogan. Sie sind intern und unverblümt, und manchmal klingen sie leicht unhöflich. Das ist in Ordnung.

Wohin gehört die Lore im GDD, und wo steht sie im Weg?

Die Lore wächst am schnellsten und wird am seltensten gelesen. Die meisten Dokumente vergraben sie ganz unten unter einer Überschrift "Story" oder lassen sie die ganze Datei auffressen. Beides funktioniert nicht.

Teile das Material danach auf, was es tut. Lore, die das Spiel verändert, etwa der Groll einer Fraktion, der eine Quest freischaltet, oder ein Fluch, der eine Klasse prägt, lebt innerhalb der Systeme, die sie betrifft. Lore, die nur Stimmung erzeugt, gehört auf eine eigene Codex-Seite, die man für keine Designentscheidung öffnen muss. Der Test ist einfach: Wenn das Streichen des Absatzes weder eine Mechanik noch einen Wurf oder eine Spielerentscheidung verändert, gehört er in den Codex.

Diese Trennung schützt auch den Kanon. Steht ein Fakt an zwei Stellen, laufen beide auseinander. Wähle für jeden Fakt einen festen Platz und verlinke ihn von überall sonst. Kanon ist ein Versprechen, und jede Inkonsistenz bricht es.

Erzähllastige Spieldesigner ergänzen oft eine kurze Zeitleiste und eine Übersicht "wer weiß was". Beides ist billig. Beides spart ganze Sitzungen Nacharbeit, wenn eine späte Enthüllung richtig sitzen muss.

Welches Tool soll deine Vorlage halten: Notion, Obsidian oder ein einfaches Dokument?

Das Tool ist weniger wichtig als die Frage, ob das Dokument an dem Ort bleibt, an dem du ohnehin arbeitest. Ein Dokument in einem Tab, den du nie öffnest, ist ein totes Dokument.

Notion ist für kleine Teams der Standard, weil Seiten miteinander verlinkt werden, Datenbanken Gegenstände und Fraktionen halten und Mitwirkende kein Setup brauchen. Es gibt fertige Vorlagen, darunter eine GDD-Vorlage für Notion mit Abschnitten für Steuerung, Spielschleife, Leveldesign und Regeln. Der Haken sind die Bindung an einen Anbieter und die Versuchung, Datenbanken für Dinge zu bauen, die keine brauchen.

Obsidian passt zu Solo-Designern, die einfaches Markdown auf der eigenen Festplatte wollen. Backlinks leisten hier echte Arbeit: Verlinkst du eine Fraktion mit jeder Szene, in der sie vorkommt, bekommst du eine Konsistenzprüfung gratis. Das Tool übersteht außerdem das Verschwinden eines Anbieters, was zählt, wenn ein Projekt jahrelang läuft.

GitBook eignet sich, wenn das Dokument öffentlich oder halböffentlich sein soll, etwa für eine Playtest-Gruppe oder eine Crowdfunding-Seite für Unterstützer. Ein einfaches Google Doc reicht für einen Game Jam. Vermeide ein komplexes Rechtemodell, außer ein Verlag verlangt es.

Lege eine Regel fest, egal welches Tool: Das Dokument wird am Ende jedes Playtests aktualisiert, bevor jemand nach Hause geht. Zehn Minuten, ohne Ausnahme.

Was kommt dazu, wenn der Prototyp den Playtest übersteht?

Nach drei oder vier Sitzungen mit echten Spielerinnen und Spielern verdient die Einseiter-Fassung ihre nächste Schicht. Ergänze die Abschnitte in dieser Reihenfolge, und nur dann, wenn der Schmerz auftaucht.

Systemdetails. Zahlen, Tabellen, Randfälle. Schreib sie, sobald du ein System festlegst, nicht vorher. Bei einem Tischrollenspiel gehören hier Aktionsökonomie, Schadensbereiche und Ressourcenkosten hin, zusammen mit dem Regeltext in seiner endgültigen Form. Bei einem Videospiel kommen die Datentabellen hinzu, die Entwicklerinnen und Entwickler lesen werden.

Inhaltslisten. Gegenstände, Gegner, Fraktionen, Orte. Nutze eine Übersicht mit einem Eintrag pro Zeile und einer Spalte für die Säule, der jeder Eintrag dient. Einträge, die keiner Säule dienen, sind Kandidaten für die Streichung.

Oberfläche und Ablauf. Layout des Charakterbogens am Tisch, Bildschirmfluss bei digitalen Spielen. Skizziere das von Hand, bevor du es in Text beschreibst.

Produktionsnotizen. Meilensteine, Umfang, Risiken, was in der ersten Version steckt und was nicht. Wenn du das Ergebnis auf DriveThruRPG oder Itch.io verkaufen willst, beginnen hier auch Seitentext und Preisannahmen.

Ein Pitch- oder Marketingabschnitt gehört in ein separates Dokument für einen anderen Leser. Verlage und Unterstützer wollen Marktkontext und Verkaufsargumente. Deine Playtester wollen Regeln. Wenn du beides mischst, entsteht eine Datei, die keinem der beiden dient.

Kann KI beim Schreiben eines Game Design Documents helfen, und wo hakt es?

Sie hilft bei Entwürfen der langweiligen Teile und scheitert an den Teilen, auf die es ankommt. Bittest du ein Modell, eine Systemliste in eine Übersicht mit Randfällen zu erweitern, bekommst du in einer Minute einen brauchbaren ersten Durchgang. Bittest du es, deine Säulen zu wählen, bekommst du Säulen, die wie bei jedem anderen Spiel klingen. Es ist schnell. Die Entscheidungen brauchen trotzdem einen menschlichen Blick.

Der praktische Einsatz ist die Konsistenzprüfung. Gib ihm den Codex und die Systemliste und frag, wo sich zwei Seiten widersprechen. Werkzeuge, die um eine lange Story-Bibel herum gebaut sind, wie Novelcrafter, sind für diesen Querabgleich gedacht. Behandle die Ausgabe als Liste von Verdächtigen, nicht als Urteil, und prüfe jeden Hinweis gegen deine eigenen Seiten.

Eine feste Regel: Das Modell schreibt nie den Abschnitt mit den offenen Fragen. Diese Seite ist deine ehrliche Liste dessen, was du nicht weißt, und sie abzugeben, verfehlt den Zweck.

Was du weglassen solltest und was du behalten musst

Verzichte auf die volle Vorlage, bis eine Mechanik mindestens drei echte Sitzungen überstanden hat. Verzichte auf den Essay zur Zielgruppe, wenn du nicht fünf konkrete Leute nennen kannst, die spielen würden. Lass detaillierte Monetarisierungsabschnitte weg, solange das Spiel seine Schleife noch nicht gefunden hat. Lass jeden Abschnitt weg, den du dir nicht vorstellen kannst, einer Mitarbeiterin oder einem Mitarbeiter laut vorzulesen.

Behalte die Säulen, die offenen Fragen und das Änderungsprotokoll. Diese drei leisten den größten Teil der Arbeit. Ein Dokument mit nur diesen dreien, wöchentlich aktualisiert, schlägt eine polierte 30-seitige Datei, die seit März niemand mehr geöffnet hat.

Die Vorlage ist ein Versprechen an dein zukünftiges Ich darüber, was du entschieden hast und warum. Halte sie kurz genug, dass du es halten kannst.