Game-Design-Document-Vorlage: Das lebendige GDD, mit dem echte Studios arbeiten

Was eine Game-Design-Document-Vorlage ist

Ein Game Design Document, kurz GDD, hält fest, was ein Spiel ist und wie es funktioniert. Darin stehen der Pitch, die Design Pillars, die im Streitfall entscheiden, der Core Loop, ein Brief für jedes zentrale Feature, die Zahlen zu Scope und Economy sowie ein Log aller Entscheidungen samt Begründung.

Früher war das GDD eine monolithische Bibel von hundert Seiten, in der Tradition von Deus Ex oder GTA. Dieses Modell ist praktisch tot. In einem Shipping-Team liest niemand hundert Seiten, und sobald sich der Build bewegt, stimmt das Dokument nicht mehr. An seine Stelle ist ein lebendiger Hub getreten. Indies arbeiten heute in einem gemeinsamen Workspace, der GDD, Aufgaben und Assets zusammenhält; mittelgroße Studios verknüpfen ihre Designseiten mit Engineering-Tickets, sodass jede Änderung an einer Mechanik automatisch die betroffenen Epics markiert.

Der Test ist einfach: Ein GDD ist ein Hub, in dem das Team arbeitet, nicht ein Dokument, mit dem das Team arbeitet. Sobald es vom Build abweicht, ist es gescheitert.

Game-Design-Document-Beispiel: wie echte Studios es strukturieren

Die brauchbaren Beispiele sind strukturell, nicht prosaisch. Larian hat Baldur's Gate 3 mit systemischen Artefakten statt Absätzen geplant – etwa mit Logikmatrizen dafür, wie jede D&D-Klasse auf jede Szene wirkt, weil Prosa so viele Wechselwirkungen schlicht nicht abbilden kann. miHoYo verfolgt bei Zenless Zone Zero ein Character-First-Design: Persönlichkeit und visuelle Identität werden zuerst geschrieben und festgezurrt, das Kampfsystem entsteht passend dazu. Der Design-Hub hält also fest, welche Richtung führt. Die Lehre daraus: Mechaniken sind visuell. Ein Core-Loop-Diagramm und eine Scope Matrix leisten mehr als eine Seite Beschreibung.

Was in ein GDD gehört

Die Autocomplete-Varianten taugen als Checkliste. Eine vollständige Vorlage deckt ab:

• Vision und Pillars. Das spielbare Versprechen, die Verantwortlichen, die Plattform-Constraints und drei bis fünf Design Pillars, die als Tiebreaker greifen, sobald Feature-Ideen zu driften beginnen. Pillars klären Streit, sie sind keine Deko.
• Core Loop. Ein Diagramm dazu, was die Spielerin tut, wie diese Aktion den Spielzustand verändert, wie der Zustand in die nächste Schleife übergeht und wie die Konsequenz sichtbar wird. Ersetzt die generischen Knoten durch die tatsächlichen Verben eures Spiels.
• Feature Briefs. Eine Karte pro zentraler Mechanik, jeweils mit Spielerversprechen, Abhängigkeiten, Logik und knapper Zusammenfassung – damit ein Feature baubar ist und nicht vage bleibt.
• Scope Matrix. Die strukturierte Quelle der Wahrheit dafür, was drin ist und was draußen, jeder Eintrag verknüpft mit einer Entscheidung oder einem Beleg.
• Decision Log und Doc-Sync-Status. Ein Verzeichnis der getroffenen Entscheidungen und der Frage, ob das Dokument noch zum Build passt. Das Design synchron zu halten ist sichtbare Arbeit, keine stille Verwaltung.

Game-Design-Document-Vorlage: kostenloses ALLO-Canvas

Bei ALLO registrieren und die kostenlosen Vorlagen nutzen

Die Vorlage öffnet sich als Karte eines lebendigen Hubs, die zeigt, wie aus dem Pitch der Build wird und wo Drift auffällt. Die Pillars sind als Tiebreaker angepinnt, der Core Loop ist ein Diagramm, das ihr mit euren eigenen Verben füllt, die Feature Briefs liegen als Karten daneben, ergänzt um Scope Matrix und Decision Log. Referenz-URLs bleiben direkt an der Arbeit angeheftet, sodass Belege später nicht mühsam gesucht werden müssen. Da es ein Canvas ist, kann das gesamte Team gleichzeitig darin arbeiten – genau darin liegt der Sinn eines lebendigen Hubs, statt einer Datei, die exportiert wird und dann veraltet.

GDD-Vorlage für Notion, Google Docs und One-Pager

Wer sein GDD in Notion oder Google Docs führt, kann dieselbe Struktur nutzen: Pillars, Loop, Feature Briefs, Scope, Decision Log. Was diese Tools nicht gut können: visuelle Artefakte wie Loop-Diagramme und Scope Matrizen direkt neben Text und Aufgaben halten – oder nachgelagerte Arbeit markieren, wenn sich ein Design ändert. Ein One-Page-GDD ist ein guter Startpunkt für ein kleines Spiel oder einen Game Jam, und die ALLO-Vorlage lässt sich darauf zusammenfalten: Die Vision-Seite allein ist bereits ein brauchbares One-Page-GDD, die weiteren Abschnitte wachsen mit dem Projekt.

FAQ

Was ist ein Game Design Document? Die gemeinsame Aufzeichnung dessen, was ein Spiel ist und wie es funktioniert: Pitch, Pillars, Core Loop, Feature Briefs, Scope, Economy und Entscheidungen. Moderne Teams führen es als lebendigen Hub, in dem sie arbeiten, nicht als statisches Dokument.

Ist das hundertseitige GDD tot? Für die meisten Teams: ja. Die monolithische Bibel ist zu träge zum Lesen und driftet sofort vom Build weg. Studios haben sie durch einen gemeinsamen Workspace ersetzt, der Design, Aufgaben und Assets zusammenhält.

Was gehört in ein GDD? Vision und Pillars, ein Core-Loop-Diagramm, ein Feature Brief pro Mechanik, eine an Entscheidungen gekoppelte Scope Matrix und ein Decision Log mit Doc-Sync-Status.

Was ist ein One-Page-GDD? Eine einseitige Fassung mit Pitch, Pillars, Core Loop und Constraints, genutzt für kleine Spiele und Game Jams. Der natürliche Startpunkt, aus dem ein volles GDD wächst.

Kann ich Notion oder Google Docs für ein GDD nutzen? Für den Text: ja. Die Grenze: Dokument-Tools halten visuelle Artefakte nicht neben dem Design und markieren nicht, welche Arbeit eine Änderung auslöst. Deshalb verlagern Teams den Hub auf ein Canvas.

---
Eine Game-Design-Document-Vorlage ist die Struktur, mit der ein Team die Design-Wahrheit eines Spiels an einem Ort hält: Vision und Pillars, Core Loop, Feature Briefs, Scope Matrix, Economy-Zahlen und Decision Log. Moderne Studios führen das nicht mehr als starres, hundertseitiges Dokument, sondern als lebendigen Hub, in dem das Team arbeitet – so verdrahtet, dass die Änderung einer Mechanik die betroffene Arbeit sofort markiert. Die kostenlose ALLO-Vorlage unten ist genau dieser Hub, bereit zum Kopieren.