Game-Design-Dokument-Generator

Was ein Game-Design-Dokument ist und warum eine Seite reicht

Ein Game-Design-Dokument, kurz GDD, beschreibt ein Spiel schriftlich für alle, die daran arbeiten: was es ist, wie es sich spielt, wie es aussieht und klingt und was es bewusst weglässt. Ein festes Format gibt es nicht. Studios haben mit einem einzelnen Blatt gearbeitet und mit Bibeln von fast 80 Seiten, und die langen waren meist veraltet, bevor das Spiel erschien.

Für ein erstes Spiel schlägt eine Seite fünfzig. Stone Librande warb auf der GDC 2010 für einseitige Designs, weil die meisten nach der ersten Seite aufhören zu lesen. Und ein langes Dokument, geschrieben, bevor irgendetwas spielbar ist, beschreibt ein Spiel, das niemand getestet hat. Eine Seite zwingt zu den Entscheidungen, die zählen: ein Pitch in einem Satz, ein Loop, ein Weg zu gewinnen und einer zu verlieren und eine erste Version, die klein genug ist, um fertig zu werden.

Dieser Generator füllt die Seite für dich. Jeder Abschnitt wird einzeln gezogen, aber aus Listen, die für ein bestimmtes Genre geschrieben sind. Ein Horror-Dokument bekommt also nie einen Farm-Loop und ein Rennspiel nie eine Sprungtaste. Pinne die Abschnitte an, die dir gefallen, misch den Rest neu und kopiere das Ergebnis als Markdown.

Die Abschnitte eines einseitigen GDD, mit Beispielen

Jeder Abschnitt beantwortet eine Frage, die sich beim Bauen des Spiels stellt. Hier steht, wofür jeder da ist, ausgefüllt für einen kleinen Plattformer.

Das kopierte Dokument endet mit zwei offenen Fragen für den ersten Playtest und einer kurzen Liste dessen, was nicht hineinkommt. Die meisten Vorlagen lassen beides weg, dabei sind es die zwei Teile, auf die du beim Bauen am häufigsten zeigen wirst.

• Pitch: ein Satz mit Genre, Tätigkeit, Ziel und Kniff. Beispiel: Ein Plattformer, in dem du eine Laterne durch einen dunklen Wald trägst, um jeden Schrein zu entzünden, aber die Flamme brennt herunter, während du läufst.
• Core Loop: die 30-Sekunden-Wiederholung als Kette von Verben mit Pfeilen. Steckt keine Belohnung darin, gibt es keinen Grund für eine weitere Runde. Beispiel: Laufen und springen → Münzen einsammeln → den nächsten Checkpoint erreichen → wiederholen.
• Ziel und Sieg: wann eine Runde gut endet, mit einer Zahl. Beispiel: Erreiche das Ziel am Ende jedes der drei Level.
• Niederlage: was schiefgehen kann und was es kostet. Ein schneller Neustart hält Spieler bei der Stange. Beispiel: Ein Sturz in eine Grube schickt dich zum letzten Checkpoint zurück.
• Steuerung: jede Aktion für Desktop und für Touch. Ein Design, das sechs Tasten braucht, überlebt keinen Handybildschirm. Beispiel: A/D zum Laufen, Leertaste zum Springen; auf Touch Pfeile unten links und eine Sprungtaste unten rechts.
• Grafikstil: Kamera, Stil und eine Regel für Lesbarkeit. Beispiel: Seitenansicht, Pixelart im 16-Pixel-Raster; die Spielfigur ist das Hellste im Bild.
• Musik und Klang: der Musikstil und die zwei, drei Geräusche, die Rückmeldung geben. Beispiel: flotter Chiptune, ein aufsteigender Ton bei jedem Sprung und ein heller Klang für Münzen.
• Erste spielbare Version: der kleinste Build, der den Loop beweist. Beispiel: ein Level von etwa zwei Minuten mit Laufen, Springen, einer Gefahr und einem Ausgang, dazu Gewinn- und Neustart-Bildschirm.

Typische Fehler mit GDD-Vorlagen

Die meisten Probleme mit Game-Design-Dokumenten entstehen, wenn man sie als Pflichtübung statt als Werkzeug für Entscheidungen behandelt. Diese Fehler tauchen bei ersten Spielen am häufigsten auf.

• Jede Überschrift einer 40-seitigen Vorlage ausfüllen, für ein Spiel, das an einem Wochenende entstehen könnte. Lösch jeden Abschnitt, den dein Spiel nicht braucht.
• Spaß beschreiben statt Regeln. „Der Kampf fühlt sich wuchtig an“ lässt sich nicht bauen, „drei Treffer beenden den Lauf“ schon.
• Keine Liste dessen, was nicht hineinkommt. Ohne sie landet jede gute Idee im Spiel, und die erste spielbare Version kommt nie.
• Touch vergessen. Wenn das Spiel im Handybrowser laufen könnte, plane die Touch-Steuerung auf Seite eins, nicht nach der ersten Version.
• Die Seite für fertig halten. Der erste Playtest ändert sie; datiere jede Version und notiere, was sich geändert hat und warum.

Wann die Seite wachsen darf

Sobald eine spielbare Version zeigt, dass der Core Loop Spaß macht, darf das Dokument auf etwa 3 bis 10 Seiten wachsen. Ergänze, was der Prototyp dich gelehrt hat: Tuning-Werte wie Laufgeschwindigkeit und Spawnraten, eine Inhaltsliste mit Stückzahlen, Progression, Barrierefreiheit und für jedes Asset Herkunft und Lizenz.

Erweitere es nur um das, was den Playtest überstanden hat. Ideen, die noch niemand gespielt hat, gehören zu den offenen Fragen, nicht in ein neues Kapitel.

Vom Dokument zur spielbaren Version

Ein Game-Design-Dokument ist eine Liste von Wetten, bis jemand das Spiel spielt. Am schnellsten entscheidest du sie, indem du die erste spielbare Version baust und testest.

Der Bau-Button unter dem Dokument schickt die ganze Seite als Prompt an den Oryn-Composer. Oryn stellt ein paar Planungsfragen, macht aus deinen Antworten ein ausführlicheres Design-Dokument, das du freigibst, und baut dann ein echtes Godot-4-Projekt, das du im Browser spielst und exportieren kannst. Gebaut wird erst, wenn du den Plan freigegeben hast.

Mehr Hintergrund: Lies den vollständigen Leitfaden zu Game-Design-Dokumenten. Dort findest du eine leere Vorlage, eine ausführliche Vorlage, ein ausgefülltes Beispiel und sieben echte GDDs von Doom bis BioShock. Fehlt dir noch die Idee selbst, hilft der Spielideen-Generator; für die Figuren deiner Welt gibt es den NPC-Generator. Was nach der ersten spielbaren Version kommt, erklärt der Leitfaden Wie man ein Videospiel macht.

So funktioniert es

1. Genre wählen

   Wähl einen Genre-Chip. Jeder Abschnitt stammt aus Listen für dieses Genre, deshalb passen die Teile zusammen.

2. Mischen und anpinnen

   Misch, bis ein Abschnitt zu deiner Idee passt, und pinne ihn dann an. Angepinnte Abschnitte bleiben, wenn du den Rest neu mischst.

3. Die Seite kopieren

   Kopiere das Markdown und füge es in Notion, Google Docs oder eine Datei in deinem Repository ein. Passe die Zahlen an, bis sie dein Spiel beschreiben.

4. Die erste Version bauen

   Schick die Seite an Oryn, beantworte die Planungsfragen und spiel die erste Version im Browser.

Fragen