Das Dokument schreiben, das der nächste Build benötigt
Ein Game Design Document sollte erklären, was gebaut wird, was entfällt und woran sich erkennen lässt, ob der Prototyp funktioniert. Für die KI-unterstützte Entwicklung sind konkrete Regeln, Steuerung, Umfangsgrenzen und Abnahmeprüfungen besonders nützlich. Ein langer Handlungsabriss kann nicht klären, ob ein eingesammelter Gegenstand doppelt gezählt werden darf oder was Neustart zurücksetzen muss.
Dieser Leitfaden verwendet durchgehend ein Lehrbeispiel: Rain Route, ein kleines Lieferspiel mit einem Roboter. GDD, Prompts, Änderung und Tests beziehen sich alle auf dasselbe vorgeschlagene Spiel. Es ist weder ein tatsächlich generiertes Projekt noch ein Bericht über eine Nutzererfahrung. Der Workflow zeigt, wie Entscheidungen mit der Umsetzung verbunden werden, ohne zu behaupten, dass der vorgeschlagene Build bereits existiert.
Dieses ausgefüllte Mini-GDD kopieren
Rain Route, Designversion 0.1.
Pitch: Ein Roboter trägt Erinnerungspakete in Draufsicht über einen verregneten Häuserblock.
Spielende und Plattform: Eine Person spielt mit Tastatur im Desktop-Browser. Eine erste Sitzung von ungefähr fünf Minuten ist ein Designziel, kein gemessenes Ergebnis.
Versprechen und Säulen: Ruhige Navigation, gut erkennbare Ziele und kleine Routenentscheidungen. Klare Rückmeldungen haben Vorrang vor zusätzlichen Systemen.
Kernschleife: Ein Paket am Depot aufnehmen, zur passenden nummerierten Haustür gehen, es zustellen und für das nächste Paket zurückkehren. Drei Zustellungen führen zum Sieg.
Steuerung und Kamera: Feste Kamera in Draufsicht. WASD oder Pfeiltasten bewegen die Figur. E nimmt im markierten Interaktionsbereich ein Paket auf oder stellt es zu. R startet nach einem Sieg neu. Anweisungen auf dem Bildschirm anzeigen.
Regeln: Es kann nur ein Paket getragen werden. Zustellungen erfolgen der Reihe nach: Tür 1, 2 und dann 3. E an der falschen Tür zeigt eine Meldung, entfernt das Paket aber nicht. Jede korrekte Zustellung erhöht den Zähler einmal. Wiederholtes E darf eine bereits abgeschlossene Zustellung nicht erneut zählen.
Karte und Herausforderung: Ein Häuserblock, ein Depot, drei Türen, eine Pfützenquerung und ein trockener Umweg. In der Pfütze beträgt die Bewegungsgeschwindigkeit die Hälfte des Normalwerts. Kein Lebensverlust, keine Gegner und keine Niederlage durch Zeitablauf.
Rückmeldung: Aktuelles Ziel, getragenes Paket und abgeschlossene Zustellungen anzeigen. Unterschiedliche Türnummern und eine sichtbare Zustellbestätigung verwenden. Regenatmosphäre soll leise bleiben; Stummschaltung anbieten.
Technischer Umfang: Ein Browser-Prototyp ohne Konten, Cloud-Speicherstände, Netzwerkfunktionen, Käufe, zusätzliche Karten oder Freischaltsystem. Neuladen beginnt einen neuen Durchlauf. Einfache eigene Formen verwenden, bis die Spielschleife die Tests besteht.
Sieg und Rücksetzung: Nach der dritten Zustellung ein Siegfenster anzeigen. R setzt Roboter, Paket, Ziel, Zustellzähler und Siegfenster auf den Anfangszustand zurück.
Prüffrage: Kann eine neue Person die erste Zustellung allein mit den sichtbaren Anweisungen abschließen?
Schritt 1: Das GDD in eine Build-Anfrage übersetzen
Verwenden Sie das Dokument als Eingabe, nicht als Beweis der Umsetzung. Prüfen Sie vor dem Absenden Widersprüche zwischen Umfang, Steuerung und Siegbedingung. „Neuladen beginnt einen neuen Durchlauf“ schließt das Versprechen dauerhaft gespeicherter Zustellungen aus; „ein Paket“ schließt eine versteckte Inventarwarteschlange aus. Klären Sie diese Entscheidungen im GDD, statt sie bei der Umsetzung erraten zu lassen. Ein geeigneter erster Prompt lautet:
Erstelle Rain Route anhand der Designversion 0.1. Implementiere zuerst nur Karte, Bewegung, Paketaufnahme am Depot und Zustellung an Tür 1. Halte spätere Türen sichtbar, aber inaktiv. Zeige aktuelles Ziel und Tragezustand an. Verwende einfache eigene Formen. Füge keine Wettereffekte, Freischaltungen, Niederlagentimer oder zusätzlichen Mechaniken hinzu. Erkläre die geänderten Komponenten und wie Aufnahme, Interaktion an der falschen Tür, korrekte Zustellung und wiederholtes E getestet werden.
Begrenzen Sie diese erste Anfrage auf den Zustellungsausschnitt. Das Ergebnis sollte eine vollständige Interaktion prüfbar machen, bevor Sie die Zahl der Ziele erhöhen. Lässt sich die Strecke mit der dokumentierten Steuerung nicht abschließen, korrigieren Sie den Ausschnitt, statt die Karte zu erweitern.
Schritt 2: Anforderungen im selben Spiel mit Tests verknüpfen
Geben Sie wichtigen Regeln kurze Kennungen und behalten Sie sie in Prompt, Notizen und Testprotokoll bei:
| Anforderung | Aktion in Rain Route | Erwartetes Ergebnis |
|---|---|---|
| R1: Höchstens ein Paket | Am Depot zweimal E drücken | Weiterhin ein Paket tragen |
| R2: Nur das richtige Ziel | Mit Paket 1 Tür 2 besuchen | Meldung erscheint; Paket bleibt erhalten |
| R3: Zustellung einmal gezählt | An Tür 1 zustellen, dann wiederholt E drücken | Zähler bleibt bei eins |
| R4: Geordneter Fortschritt | Alle drei Zustellungen abschließen | Ziel wechselt 1 → 2 → 3; Sieg erscheint einmal |
| R5: Verlangsamung in der Pfütze | Dieselbe markierte Strecke innerhalb und außerhalb des Wassers zeitlich messen | Pfützengeschwindigkeit entspricht der vorgegebenen Hälfte |
| R6: Vollständige Rücksetzung | Nach dem Sieg R drücken | Ausgangsposition, leere Hände, null Zustellungen, kein Siegfenster |
Halten Sie tatsächliche Beobachtungen in einem separaten Durchlaufprotokoll mit Build-Version und Umgebung fest. Fügen Sie einen Status wie bestanden, fehlgeschlagen oder blockiert erst nach Ausführung der Aktion hinzu. Schlägt der erste Ausschnitt bei R2 fehl, korrigieren Sie diese Interaktion, bevor Sie drei Zustellungen anfordern. Beschreiben Sie die Eingabefolge so genau, dass eine andere Person den Fehler reproduzieren kann.
Schritt 3: Die Spielschleife erweitern und dann Atmosphäre hinzufügen
Nachdem die erste Zustellung besteht, fordern Sie Türen 2 und 3 sowie Sieg- und Rücksetzzustände an. Führen Sie R1 bis R4 und R6 erneut aus. Fordern Sie danach die Verlangsamung in der Pfütze an und prüfen Sie R5, ohne die Aufnahmelogik zu ändern.
Erst wenn diese Regeln bestehen, sollten Sie Regenbilder und eine leise Geräuschkulisse ergänzen. Prüfen Sie, dass Regen weder Nummern noch Interaktionsmarkierungen verdeckt und die Stummschaltung funktioniert. Macht der Wettereffekt die Karte unlesbar, reduzieren Sie ihn, statt Atmosphäre auf Kosten des dokumentierten Spielversprechens zu akzeptieren.
Schritt 4: Das GDD aktualisieren, wenn Belege eine Entscheidung ändern
Angenommen, ein späterer Spieltest zeigt, dass Spielende das aktuelle Ziel übersehen. Dies ist hier eine hypothetische Beobachtung, kein Ergebnis. Eine gezielte Änderung würde eine deutlichere Zielbeschriftung anfordern und dabei Türreihenfolge und Zustellregeln bewahren. Testen Sie dieselbe Frage zur ersten Zustellung mit einer neuen Person erneut.
Halten Sie die Entscheidung als Version 0.2 fest, nennen Sie den Änderungsgrund und verknüpfen Sie sie mit der betroffenen Anforderung und dem Build. Halten Sie frühere Entscheidungen verfügbar, damit ein altes Testergebnis nicht als Beleg für eine neue Regel missverstanden wird. Eine überarbeitete Anforderung sollte angeben, welche früheren Prüfungen erneut auszuführen sind.
Verletzt eine generierte Änderung eine frühere Anforderung, machen Sie sie rückgängig oder isolieren Sie sie. Melden Sie die fehlgeschlagene Anforderung, genaue Eingabe, erwartetes und tatsächliches Ergebnis. „R3 zählt nach wiederholtem E zweimal“ ist konkreter umsetzbar als „Der Prototyp fühlt sich fehlerhaft an“.
SEELE zwischen Spezifikation und Testprotokoll verwenden
SEELE unterstützt die Spielerstellung in natürlicher Sprache und iterative Änderungen an Spielablauf, Szenen und Assets. Geben Sie das Mini-GDD als Designeingabe an und fordern Sie dann einen begrenzten Umsetzungsausschnitt an. Das nützliche Ergebnis ist ein Build-Kandidat, der mit demselben Dokument verglichen werden kann, kein Ersatz für Designentscheidungen oder ein abgeschlossenes Testprotokoll.
Nennen Sie bei jeder Folgeanfrage die geänderte Anforderung und diejenigen, die stabil bleiben müssen. Die Bitte um eine klarere Zielbeschriftung sollte nicht stillschweigend einen Timer einführen oder Türen umsortieren. Verknüpfen Sie Dokument, Prompt und beobachtetes Ergebnis über die Version, damit eine ausformulierte Beschreibung niemals das tatsächliche Verhalten ersetzt.
Das GDD nutzen, um den Build zu beginnen, nicht aufzuschieben
Ein nützliches GDD verkürzt den Weg zwischen Entscheidung und Prüfung. Rain Route braucht eine klare Aufnahmeregel, Zielreihenfolge und Rücksetzdefinition, bevor ein längerer Handlungsabriss nötig ist. Halten Sie das Dokument kurz, formulieren Sie die Regeln aber so genau, dass eine andere Person denselben Build beurteilen kann.
Kopieren Sie die Spezifikation in SEELE und fordern Sie den ersten Zustellungsausschnitt an. Halten Sie Dokument, funktionierenden Build und Testprotokoll über die Version aufeinander abgestimmt. Erweitern Sie den Umfang erst, wenn die bestehenden Regeln desselben Spiels Umsetzung und Änderung überstehen, und aktualisieren Sie das GDD, wenn Belege eine Entscheidung ändern.
Das Design bis zur spielbaren Prüfung nachverfolgen
Diese Tabelle ordnet die im Artikel vorgeschlagenen Prüfungen. Sie berichtet nicht über einen abgeschlossenen Test.
| GDD-Element | Welche Frage es beantwortet | Beispiel einer Abnahmeprüfung |
|---|---|---|
| Spielende und Eingabe | Wer spielt und wie wird gehandelt? | Eine Person am Desktop kann den Roboter mit der festgelegten Tastatursteuerung bewegen. |
| Ziel und Umfang | Was muss in dieser Version geschehen? | Die Spielfigur kann das angegebene Paket in der definierten Szene zustellen. |
| Regeln und Grenzen | Was geschieht, wenn eine Regel ausgelöst wird? | Eine Zustellung oder Aufnahme wird nur wie im Design festgelegt gezählt. |
| Fehler und Wiederherstellung | Was geschieht, wenn die Aufgabe nicht abgeschlossen werden kann? | Das angegebene Fehler- oder Neustartverhalten führt das Spiel in den dokumentierten Zustand zurück. |
| Änderungsprotokoll | Welche Entscheidung änderte sich und warum? | Beobachtung, geänderte Regel und Ergebnis der erneuten Prüfung festhalten. |
FAQ
Wie lang sollte ein Prototyp-GDD sein?
So kurz wie möglich, aber lang genug, um die nächsten Umsetzungsentscheidungen zu klären. Das ausgefüllte Beispiel legt Umfang, Steuerung, Regeln und Tests ohne umfangreiche Produktionsbibel fest. Ergänzen Sie Abschnitte, wenn sie ändern, was jemand baut oder prüft. Eine fehlende Interaktionsregel ist kostspieliger als eine fehlende Seite Hintergrundgeschichte.
Kann KI das Dokument für mich schreiben?
KI kann Abschnitte entwerfen und Unklarheiten aufdecken, aber Sie müssen die Regeln entscheiden und ihre Machbarkeit prüfen. Bitten Sie sie, widersprüchliche Anforderungen und fehlende Abnahmekriterien zu erkennen. Betrachten Sie ein ausformuliertes Dokument nicht als Bestätigung von Spielspaß, Umsetzungsqualität, Asset-Rechten oder ungeprüften Produktfähigkeiten.
Was ist der Unterschied zwischen GDD und Testprotokoll?
Das GDD beschreibt beabsichtigtes Verhalten und Entscheidungen. Das Testprotokoll hält fest, was in einem bestimmten Build und einer bestimmten Umgebung geschah. Verknüpfen Sie beide, halten Sie sie aber getrennt: Ein erwartetes Bestehen ist kein bestandener Test. Rechtfertigen Beobachtungen eine Regeländerung, aktualisieren Sie das Design ausdrücklich und führen Sie betroffene Prüfungen erneut aus.
Eine Kapitel-Checkliste für ein größeres GDD
Fügen Sie Abschnitte nur hinzu, wenn sie eine Entscheidung für den nächsten Build leiten. Beginnen Sie mit dem Publikum, der Plattform und dem Pitch mit einem Satz. Befolgen Sie die Kernschleife, die Steuerung, den Fortschritt, die Welt oder Erzählung, die künstlerischen und klanglichen Einschränkungen sowie die technischen Anforderungen. Geben Sie für jedes Feature im Umfang seinen Eigentümer, den kleinsten spielbaren Beweis und einen Test an, den das Team wiederholen kann. Verschieben Sie optionale Ideen in einen separaten Backlog.
