huayuehua15-netizen/aaa-game-gdd

3A 级游戏开发文档（GDD）技能

Pfadkonvention: Alle scripts/, references/, assets/ in dieser Datei sind relativ zum Verzeichnis dieser SKILL.md. Führen Sie python scripts/new_gdd.py erst aus, nachdem Sie dieses Verzeichnis gefunden haben (Cursor/Codex installiert es via install.ps1 unter <Projekt>/skills/game-dev/aaa-game-gdd/). Wenn Sie unsicher sind, ermitteln Sie den absoluten Pfad dieser SKILL.md und rufen Sie das Skript mit absolutem Pfad auf; im Projektstammverzeichnis führt ein relativer Pfad zu einem „file-not-found“-Fehler.

Was dieses Skill tut

Verwandeln Sie „Ich habe eine Spielidee“ in ein vollständiges Set von Dokumenten, mit dem Ihr Team direkt entwickeln kann, um ein Steam-veröffentlichungsfähiges, AAA-Qualitätsspiel zu erstellen. Das Kernprodukt ist ein strukturierter, quantifizierbarer, überprüfbarer Satz von chinesischen Markdown-Dokumenten (GDD) – keine vage Konzeptskizze.

Jedes produzierte Dokument muss drei eiserne Regeln erfüllen:

1. Entwickelbar: Entwickler müssen nach dem Lesen des Dokuments keine Fragen stellen wie „Was genau soll ich machen? Wie groß? Welcher Standard?“ Alles Quantifizierbare wird mit Werten festgelegt (Polygonanzahl, Frames, Dauer, Auflösung, Frequenz, Verzögerung, Auslösebedingungen).
2. Überprüfbar: Jedes Asset, jedes System, jede Szene hat eine „Definition of Done“-Checkliste; nach der Fertigstellung kann Punkt für Punkt abgehakt werden.
3. Konsistent: Alle Dokumente teilen dieselben Vision Pillars, Art Bible, Benennungskonventionen und Performance-Budgets; Dokumente referenzieren sich gegenseitig mit Nummern – Widersprüche sind verboten.

Dokumentenlandkarte (references bei Bedarf lesen)

Lesen Sie nicht alle Referenzdokumente auf einmal. Bestimmen Sie zuerst anhand der Tabelle, welche Art von Dokument der Benutzer benötigt, und lesen Sie nur das entsprechende Referenzdokument. Jede Reference ist wie folgt aufgebaut: Welches Problem wird gelöst → Wann schreiben → Kapitelstruktur → Wie jedes Kapitel schreiben (mit quantitativen Standards) → Gute/schlechte Beispiele → Definition of Done-Checkliste.

Dokument	Wann diese Reference lesen	Entsprechende Vorlage (assets/templates)
00 Dokumentationssystem-Übersicht	Neues Projekt starten, Dokumentenliste und Phasenplan festlegen	README.md
01 Vision & Pitch	Projekt hat gerade eine Idee, braucht eine einseitige Zusammenfassung, für externe Präsentationen	01-vision-pitch.md
02 Art Bible	Kunststil festlegen, Team-Ästhetik vereinheitlichen, Kunst-Anforderungen ausgeben	02-art-bible.md
03 Szenen & Level	Szenenbeschreibung, Level-Ablauf, Bewegungslinien, Begegnungen, Umgebungs-Erzählung	03-scene-level.md, scene-sheet.md, level-sheet.md
04 Spielsysteme	Kernzyklus, Kampf, Fortschritt, Wirtschaft, Werte-Tabellen entwerfen	04-gameplay-systems.md, system-sheet.md
05 Story & Dialoge	Story-Outline, Kapitel-Beats, Verzweigungen, Dialog-Skripte, Sprecher-Synchronisation	05-narrative-dialogue.md, dialogue-sheet.md
06 Interaktion & UI/UX	Steuerung, Interaktionsmatrix, Spielgefühl, HUD, Menüs, Barrierefreiheit festlegen	06-interaction-uiux.md
07 Charakter-Spezifikationen	Setting, Aussehen, Bewegungsset, KI, Werte für Helden/Feinde/NPCs	07-character-spec.md, character-sheet.md
08 Gegenstands-Modelling-Spezifikationen	Modellierung, Texturen, LODs, Benennung, Lieferung von Gegenständen/Waffen/Umgebungs-Assets	08-prop-modeling.md, prop-sheet.md
09 Animations-Spezifikationen	3D-Skelettanimation, Animations-State-Machine, Zwischensequenzen, 2D-Frame-Animation	09-animation-spec.md, animation-sheet.md
10 Audio-Design	Musik, Soundeffekte, Synchronisation, dynamische Musik, Bus-Lautstärke	10-audio-spec.md
11 Technik & Performance	Engine-Auswahl, Render-Pipeline, FPS/Speicher/Paket-Budget, Plattform	11-tech-performance.md
12 AAA-Qualität & Steam-Abnahme	Phasen-Gates, QA-Plan, Steam-Store & Veröffentlichung, AAA-Vergleichsbewertung	12-steam-qa-checklist.md

Arbeitsablauf

Ablauf A: Neues Projekt (von der Idee zum vollständigen Dokumentensystem)

1. Klärung der minimal notwendigen Informationen (in einer Runde Fragen an den Benutzer, maximal 4 Fragen): Spieltyp & Kernmechanik in einem Satz, Engine (Unity/Unreal/Godot/unentschieden), Plattform & Ziel-FPS (PC 60fps? Steam Deck?), Kunststil-Tendenz. Nach der Befragung kann sofort begonnen werden; fragen Sie nicht wiederholt nach Vollständigkeit. Unbekannte Punkte werden im Dokument explizit mit 【Bestätigung ausstehend】 markiert.
2. Scaffolding ausführen: python scripts/new_gdd.py init --name "Spielname" --out <Ausgabeverzeichnis> --engine <im 1. Schritt bestätigte Engine>, generiert den gesamten GDD-Dokumentenbaum. --engine muss die im 1. Schritt erfragte Antwort verwenden, nicht einfach unity – dies bestimmt tatsächlich die Achsen, Kollisionsbenennung, Navigation und Daten-Asset-Konventionen im Dokument.
3. Dokumente phasenweise schreiben (siehe „Phasen-Gates“ unten), zuerst die entsprechende Reference lesen, dann die Vorlage ausfüllen. Reihenfolge: 01 Vision → 02 Art Bible + 11 Technisches Budget → 04 Kernspielmechanik → 07/08/09/06 Spezifikationen → 03/05 Inhalte → 12 Abnahme.
4. Jede Szene/jeden Charakter/jeden Gegenstand/jede Animation/jeden Dialog/jedes System mit scripts/new_gdd.py sheet als eigenständige Einzelseite generieren, im entsprechenden Unterverzeichnis des GDD ablegen; das Kerndokument enthält nur die Index-Tabelle, nicht hunderte Assets in einer Datei stapeln.
5. Qualitäts-Gates durchlaufen: Nach jeder Phase mit der Gate-Tabelle aus 12-steam-qa-checklist.md Punkt für Punkt prüfen; ohne Bestehen wird die nächste Phase nicht begonnen.

Ablauf B: Einzelnes Dokument (Benutzer benötigt nur eine bestimmte Dokumentenart)

Zweck klären → entsprechende Reference lesen → entsprechende Vorlage kopieren und ausfüllen → mit der „Definition of Done“ am Ende des Kapitels selbst prüfen → ausliefern. Wenn der Benutzer nur „Schreib mir eine Szene“ sagt, fragen Sie zuerst nach Szenenname/Position im Ablauf/Kernereignis (in einem Rutsch), dann direkt eine vollständige scene-sheet erstellen, nicht nur eine leere Vorlage liefern.

Szene vs. Level: Standardmäßig nur das vom Benutzer Angeforderte ausgeben. In references/03 heißt es „Szene ist Raum, Level ist Zeit, getrennt schreiben“ – das bezieht sich auf die Aufgabenverteilung, wenn beide benötigt werden, nicht, dass zu jeder Szene automatisch ein Level-Blatt erstellt werden muss.

Die Aufteilung ist hart:

• Szenen-Einzelseite (SC_) = Was dieser Raum bietet: Gelände, Sichtlinien, Deckung, Höhenunterschiede, Fluchtwege, versteckbare Punkte, räumliche Einschränkungen für Feinde (§7) sowie Triggerzonen TZ_ (§4).
• Level-Einzelseite (LV_) = In welcher Reihenfolge erlebt der Spieler was: Beat-Tabelle (mit EV_-Ereignisnummern), Rhythmus, Konsequenzen der Begegnungen, Checkpoints.

Daher:

• Benutzer will nur Szene → nur scene-sheet.md schreiben, keine Reihenfolge; falls wirklich kein Level-Blatt erstellt wird, erst in §7 „Erlebnisreihenfolge (kurz)“ eine Zeile ergänzen.
• Benutzer will Level-Ablauf oder Szene mit mehreren Phasen-Rhythmen → dann level-sheet.md erstellen, beide über TZ_ ↔ EV_ referenzieren.
• Nicht eigenständig zwei Dokumente ausgeben, nur weil 03 „getrennt schreiben“ sagt – das würde eine einfache Anfrage um das 2-3-fache aufblähen.

Vor dem Ausfüllen zuerst das Beispiel lesen – jede Art von Einzelseite hat ein vollständiges Beispiel. Lesen Sie direkt das für den Typ, den Sie schreiben:

Einzelseiten-Typ	Beispiel	Woran orientieren
Szene (linear/Horror)	assets/examples/SC_01_外科楼二层走廊_示例.md	§7 Raumangebot = Sichtlinien blockiert & „Erst erblicken, dann treffen“; §10 eher Wahrnehmung & Rhythmus
Szene (offen/BOSS)	assets/examples/SC_07_断桥瞭望台_示例.md	§7 Raumangebot = Distanz einstellbar / Sichtlinie unterbrochen / Risiko abschätzbar; §10 eher Kampf-Lösbarkeit
Level	assets/examples/LV_01_走廊初遇_示例.md	Wie Beat-Tabelle mit TZ_ abgeglichen wird; wie Intensitätskurve & Lehrimpulse ohne Popups funktionieren
Charakter (Feind)	assets/examples/EN_01_缝合者_示例.md	Warum §6 State-Machine+Geschwindigkeitsdifferenz „entkommen können“ erfordert; wie §7 Kampfdauer berechnet wird
Gegenstand	assets/examples/PR_017_缺轮轮椅_示例.md	§5 Technische Spezifikationswerte; wie §7 DoD „absichtlich nicht gemacht“ formuliert wird
Animation	assets/examples/AN_EN01_Slash_01_示例.md	§2 Dreiteiliges Frame-Intervall; §3 Ereignis-Placeholder (Vorwarn-Ton ist Fairness-Grundlage)
Dialog/Zwischensequenz	assets/examples/DL_07_护士长录音_示例.md	Wie Dialog-ID/Dauer/Untertitel-Compliance/Unterbrechung+Weiterlaufen definiert werden
System	assets/examples/SYS_04_抓取挣脱_示例.md	§4 Parametertabelle muss „Design-Intention“ enthalten; §5 Grenzfälle lückenlos

Alle Beispiele müssen diese Granularität erreichen (jeder Punkt hat konkrete Zahlen, Nummern, zuweisbare Aufgaben). Hinweis: Die ankreuzbaren Optionen in den Beispielen sind Validierungsaufzeichnungen nach Fertigstellung (mit tatsächlich gemessenen Polygonzahlen, Prüfdatum, verworfenen Designentscheidungen), nicht das Ausfüllformat vor Arbeitsbeginn; in der v0.1-Phase lassen Sie leere Felder leer, erfinden Sie keine Zahlen, die „wie gemessen“ aussehen. §10 Designrisiken & zu validierende Annahmen ist der einzige Abschnitt, der keine Zahlen haben darf (und auch nicht haben sollte).

Ablauf C: Überprüfung vorhandener Dokumente/Ideen

Nach der „AAA-10-Dimensions-Bewertungstabelle“ in 12-steam-qa-checklist.md jede Dimension bewerten (1-10 Punkte, mit Belegen), blockierende Fehler für die Veröffentlichung auflisten, Liste fehlender Dokumente, Änderungsvorschläge nach Schweregrad sortiert. Die Bewertung muss auf Dokumentenzitate oder fehlende Punkte verweisen; leere Bewertungen sind verboten.

Phasen-Gates (Stage Gates)

Phase	Erforderliche Dokumente	Gate (ohne Bestehen keine nächste Phase)
Konzept	01 Vision, 04 Kernspielmechanik-Skelett	Kernspaß spielbar auf Papier/Graybox-Prototyp validiert; 3 Kern-Pillars vom gesamten Team akzeptiert
Vertikaler Slice	02, 06, 11 + mindestens 1 Muster-Einzelseite pro Kategorie (Szene/Charakter/Gegenstand/Animation/Dialog)	10-15 Min. Ablauf erreicht endgültige Qualitätserwartung; alle Kernsysteme laufen; Performance-Budget eingehalten
Massenproduktion	Alle Kerndokumente + alle Asset-Einzelseiten	Jede Asset-Einzelseite direkt zuweisbar; Kapazität & Meilensteine planbar
Alpha	Sämtliche Inhalte	Feature Complete: Von Anfang bis Ende durchspielbar, keine Platzhalter-Systeme
Beta	Wie Alpha + 12 Abnahmetabelle	Content Complete; null S/A-Level-Bugs; gesamten Ablauf ×3 Konfigurationen durchgespielt
RC/Veröffentlichung	Alle Steam-Checkliste-Punkte aus 12 abgehakt	Store-Seite, Deck-Validierung, Lokalisierung, Altersfreigabe, Speicherkompatibilität alle bestanden

Scaffolding-Skript

# Vollständigen GDD-Dokumentenbaum initialisieren (erstellt <Spielname>_GDD/ im Ausgabeverzeichnis)
python scripts/new_gdd.py init --name "Spielname" --out "D:/MeinSpiel" --engine unity
#   --engine: unity | unreal | godot | agnostic (Standard)
#             ★ Dies ist keine Dekoration: Die Auswahl schreibt tatsächlich das Austauschformat/die Achsen/Kollisionsbenennung/Navigation/Daten-Assets/LOD-Konventionen der Engine
#   --genre: optional, Spieltyp-Beschreibung, wird in das Vision-Dokument geschrieben
#   --dimension: 3d (Standard) | 2d (erstellt zusätzlich sprites/ tilesets/ Unterverzeichnisse)

# Einzelseite für ein einzelnes Objekt generieren (automatisch in entsprechendes Unterverzeichnis)
python scripts/new_gdd.py sheet --type scene --name "Verlassenes Krankenhaus" --out "D:/MeinSpiel/Spielname_GDD"
#   --type: scene | level | character | prop | animation | dialogue | system | sprite | tileset
#   --subtype: character verwendet player/enemy/npc (CH/EN/NPC); prop verwendet item/weapon (PR/WP)
#   Beispiel: sheet --type character --subtype enemy --name "Nähmaschine" → characters/EN_01_Naehmaschine.md
#   Beispiel: sheet --type sprite --name "HeroIdle" → sprites/SPR_01_HeroIdle.md

init unterstützt auch --dimension 2d: Erstellt zusätzlich sprites/, tilesets/ Unterverzeichnisse (für 2D-Projekte).

Das Skript ersetzt automatisch die Platzhalter {{GAME_NAME}}, {{DATE}}, {{ENGINE}}. Falls das Skript nicht verfügbar ist, Vorlagen manuell aus assets/templates/ kopieren.

Allgemeine Schreibregeln

• Dokumentenkopf: Jedes Dokument beginnt fest mit: Dokument-ID, Version, Status (Entwurf/in Überprüfung/gesperrt), letztes Aktualisierungsdatum, Verantwortlicher, referenzierte Dokument-IDs. Asset-Einzelseiten benötigen zusätzlich den Ressourcennamen innerhalb der Engine (z. B. SM_Prop_HospitalWheelchair_01).
• Quantifizierung zuerst: Vermeiden Sie nicht überprüfbare Beschreibungen wie „gutes Spielgefühl“, „wunderschöne Grafik“, „starker Feind“. Schreiben Sie „Vom Tastendruck bis zur Schadensauslösung 8 Frames (0.13s@60fps)“, „Feind HP 120, voll verstärkter Spieler DPS 45, erwartete Kampfdauer 35-45s“.
• Unsicherheit markieren: Unbekannte Werte schreiben Sie als 【Bestätigung ausstehend: Grund/Verantwortlicher/Frist】; erfinden Sie keine Zahlen und tun Sie so, als wären sie sicher; Branchenerfahrungswerte können direkt übernommen und im Dokument als „Branchenstandard, nach erstem Test anpassen“ vermerkt werden.
• Text & Grafik-Anforderungen: Szenen, Level, UI müssen mit Layout-Skizzen versehen sein (ASCII-Grundrisse, Mermaid-Ablauf-/Zustandsdiagramme oder Verweise auf Konzeptzeichnungsnummern); Zustandsautomaten, Dialogbäume, Menüabläufe mit Mermaid zeichnen; Parameter und Listen in Tabellen darstellen.
• Jede Seite muss DoD haben: Am Ende eine „Definition of Done“-Checkliste (ankreuzbare - [ ]), die das einzige Kriterium für die Abnahmeprüfung ist.
• Sprache: Chinesischer Fließtext; Eigennamen, Engine-APIs, Ressourcennamen auf Englisch belassen; Dialogskripte reservieren gleichzeitig Felder für Englisch/andere Sprachen.
• Dokumentänderungen versionieren: Änderungen an gesperrten Dokumenten im Änderungsprotokoll am Ende mit Version, Datum und geändertem Inhalt vermerken.

Lieferanforderungen

• Das Ergebnis sind Markdown-Dateien im Benutzerprojektverzeichnis (Scaffolding-Verzeichnis + ausgefüllte Dokumente), keine Gliederung im Chat.
• Nach jeder Lieferung den Benutzer darauf hinweisen: Welches Dokument als nächstes geschrieben werden sollte, welche 【Bestätigung ausstehend】-Punkte er entscheiden muss.
• Die Dokumentqualität wird daran gemessen, dass „ein neu hinzukommender externer Artist/Programmierer, der nur die entsprechende Einzelseite liest, selbstständig ein qualifiziertes Asset erstellen kann“.