End-to-End Game Production Pipeline

Was macht End-to-End Game Production Pipeline?

Führe eine Idee zu einem kompilierbaren Build + Release-Plan. Jede Phase hat festgelegte Artefakte, feste Pfade und ausführbare Gates – Phasen dürfen nicht übersprungen werden.

Die folgenden Rollen sind optionale Aufgabenteilung: Nur verwenden, wenn die aktuelle Umgebung Delegierung unterstützt; andernfalls direkt vom aktuellen Assistenten ausgeführt. Wähle den Arbeitsumfang basierend auf der tatsächlichen Autorisierung des Benutzers und der Projektphase aus. Das Status-Skript prüft nur Dokumententitel und TODOs, es prüft nicht automatisch Ressourcen, echte Builds oder Gerätevalidierung; diese müssen separat ausgeführt und die Ergebnisse dokumentiert werden.

Die fünf Produktionsphasen, G1–G5 Meilensteine, Sprint-Zyklen und Teamgrößenanpassung findest du in references/production-cycle.md. Die sieben Phasen in der folgenden Tabelle sind Artefakt-Untergates und entsprechen nicht 1:1 den Produktionsmeilensteinen.

Phasen & Artefakte

Phase	Ausgabe	Verantwortliche Rolle
brief	docs/00-brief.md Projektkarte	Produzent (du selbst)
gdd	docs/01-gdd.md	game-narrative-designer
tech	docs/02-tech.md	cocos-engineer, unity-engineer oder godot-engineer
art	docs/03-art.md + docs/art-style-bible.md + finale Grafiken + assets/manifest.json	game-art-director
audio	docs/04-audio.md + finales Audio	game-audio-designer
qa	docs/05-qa.md	game-qa-engineer
release	docs/06-release.md	game-release-operator

Das Grundgerüst befindet sich im Plugin unter templates/docs/. Kopiere es in das Projekt-docs/ und fülle es aus. Das Gate gibt nicht frei, bevor alle [TODO] im Grundgerüst ausgefüllt sind.

Tools (Plugin-eigen, direkt mit Python aufrufbar)

Skript-Verzeichnis = scripts/ im Plugin-Root. Wenn der absolute Pfad unsicher ist, führe zuerst codex plugin list aus, um den Plugin-Pfad zu finden.

Zweck	Befehl
Status initialisieren	python scripts/omni_state.py init --root . --engine godot --platforms web,android
Phasenfortschritt anzeigen	python scripts/omni_state.py status --root .
Einzelne Phase validieren	python scripts/omni_state.py check --root . --stage gdd
Phase vorrücken (mit Gate)	python scripts/omni_state.py advance --root .
Platzhalter-Grafiken generieren (nur zur Pipeline-Verifikation)	python scripts/gen_placeholder_art.py --manifest assets/manifest.json --root .
Roadmap erstellen	Kopiere templates/docs/07-production-roadmap.md nach docs/
Sprint-Planung & Review	Kopiere templates/docs/08-sprint-review.md, dokumentiere integrierte Version, Tests und Feedback pro Sprint
Gate-Review	Kopiere templates/docs/09-milestones.md, dokumentiere G1–G5 und Post-Launch-Betriebs-Reviews
Finale Bildnachbearbeitung	python scripts/process_art.py --in raw/x.png --out assets/art/x.png --size 256x64 --key-color "#FFFFFF" --check-nine --nine-slice 24
AI-Animation Frames schneiden	python scripts/split_sprite_sheet.py --input raw/sheet.png --cols 4 --rows 2 --fps 12 --loop --out-dir assets/animation/run --backup-dir doc/temp/run-frames
AI-Bild / GIF	python scripts/gen_ai_image.py --prompt "single game icon" --format png --out assets/art/icon.png --backup-dir doc/temp --dry-run
AI-Soundeffekt	python scripts/gen_ai_audio.py sfx --prompt "short sci-fi pickup" --duration 1 --out assets/audio/pickup.mp3
AI-Musik	python scripts/gen_ai_audio.py music --prompt "gentle space exploration" --duration 30 --instrumental --out assets/audio/main.mp3
BGM generieren (chiptune)	python scripts/gen_music.py --style upbeat --out assets/audio/bgm_main.wav --tempo 132 --bars 16
Soundeffekt synthetisieren	python scripts/gen_sfx.py --preset hit --out assets/audio/sfx_hit.wav
Audiokompression berechnen	python scripts/compress_audio.py --dir assets/audio --check
Atlas packen	python scripts/pack_atlas.py --input assets/art/ui --out-sheet assets/art/ui_atlas.png --out-data assets/art/ui_atlas.json
Ressourcenmanifest validieren	python scripts/validate_assets.py --manifest assets/manifest.json --root .
Finaler Pre-Release-Check	python scripts/validate_assets.py --manifest assets/manifest.json --final --strict-license
Build prüfen/validieren	python scripts/build_check.py --project . → --run für tatsächlichen Build hinzufügen

Ausführungsreihenfolge

0. Projekt-Skeleton bereitstellen

cp -r <plugin>/templates/godot4/* .        # oder unity / cocos3
mkdir -p docs assets/art assets/audio doc/temp
cp <plugin>/templates/docs/*.md docs/
cp <plugin>/templates/assets-manifest.json assets/manifest.json
python scripts/omni_state.py init --root . --engine godot --platforms web,android
python scripts/omni_state.py checkpoint --root . --task "Projektstart" --next "Brief schreiben"

Lies vor Arbeitsbeginn .omni/active.md (falls vorhanden): Es enthält die aktuelle Aufgabe und Blockaden aus der letzten Sitzung und ist zuverlässiger als der Chat-Verlauf nach einem Kontextwechsel.

Die drei Vorlagen haben unterschiedliche Reifegrade. Informiere den Benutzer explizit:

Vorlage	Status	Erforderliche manuelle Schritte
godot4	Direkt ausführbar (Import + Hauptszene getestet)	Keine
unity	Kann geöffnet werden, Szene muss generiert werden	Menü Tools ▸ Omni ▸ Create Main Scene
cocos3	Code & Konfiguration bereit	Neue Szene erstellen → GameRoot an Canvas hängen → Startszene festlegen

1. Projektinitiierung & Konzept (G1)

Kläre fünf Dinge: Kernspielerlebnis, Plattformpriorität, MVP-Umfang, Monetarisierung & Compliance, vorhandene Assets & Engine. Fülle docs/00-brief.md und docs/01-gdd.md aus, dokumentiere zu validierende Annahmen und die Go/No-Go-Entscheidung. Budget und Meilensteine basierend auf Teamgröße schätzen und Unsicherheiten kennzeichnen.

2. GDD

Beauftrage game-narrative-designer. Anforderungen: Werte als konkrete Zahlen angeben, jede Anforderung muss testbar sein, separate Liste „Anforderungen an die Engine-Fähigkeiten". Nach dem Ausfüllen advance ausführen.

3. Pre-Production & Vertical Slice (G2)

Beauftrage je nach Engine cocos-engineer, unity-engineer oder godot-engineer. Anforderungen: Zuerst Profiling-Daten liefern, dann Optimierungen vorschlagen; plattformspezifische Build-Konfigurationen müssen bis auf Texturformat und Asset-Bündelungsstrategie konkret sein. Frühzeitig einen spielbaren Prototypen implementieren, um die Kernschleife zu validieren.

4. Art (Finale Asset-Produktion)

Beauftrage game-art-director zur Erstellung von docs/03-art.md und assets/manifest.json. Führe dann gemäß der Fähigkeit game-art-production aus:

1. Zuerst Style Bible erstellen docs/art-style-bible.md: Ein fester, stilprägender Text + Farbpalette + Verbote
2. Asset-für-Asset generieren: Nutze die Bildtools der aktuellen Sitzung oder konfigurierte AI-Bild-APIs; generiere bei Bedarf Varianten; fordere transparenten Hintergrund an, falls nötig; befolge die Projekt-Bild-Backup-Regeln. Animationen gemäß game-animation-production als GIF oder Sprite-Sheet generieren und Frame-Schnitt prüfen.
3. Nachbearbeitung auf Spezifikation:

python scripts/process_art.py --in raw/btn_raw.png --out assets/art/ui/ui_btn_primary.png \
  --size 256x64 --mode fit --key-color "#FFFFFF" --key-tolerance 14 \
  --nine-slice 24 --check-nine

4. Im Manifest eintragen: tier: "final" + source + license + commercial_ok + ai_generated
5. Finalprüfung: validate_assets.py --final --strict-license

Erstelle vor G2 einen vollständigen, aber inhaltlich kleinen Vertical Slice, der Code, Design, Art und Audio in der Zielengine integriert. Teste Bildqualität, Asset-Pipeline, Build und Performance im echten Durchlauf. Plane keine Serienproduktion basierend auf einem Demo, bevor der Slice nicht die Reproduzierbarkeit und akzeptable Kosten der Lösung nachweist. Das Status-Skript im Plugin prüft nur Dokumente, nicht dieses Gate.

5. Audio-Produktion

Beauftrage game-audio-designer zur Erstellung von docs/04-audio.md. Wähle dann gemäß der Fähigkeit game-audio-production eine Route:

• Route A (AI-generiert): Bevorzugt die aktuell verfügbaren Audio-Generierungstools nutzen; oder gen_ai_audio.py mit ElevenLabs-API verwenden (Details in game-audio-production). API-Schlüssel, Berechtigungen, Abrechnung und Lizenzierung müssen vorher geklärt sein.
• Route B (8-bit, offline, kostenlos):

python scripts/gen_music.py --style upbeat --out assets/audio/bgm_main.wav --tempo 132 --bars 16
python scripts/gen_sfx.py --list
python scripts/gen_sfx.py --preset hit --out assets/audio/sfx_hit.wav

• Muss komprimieren: python scripts/compress_audio.py --dir assets/audio --bitrate 96k; falls ffmpeg fehlt, gemäß Skript-Hinweis Engine-seitige Import-Kompression verwenden (Godot QOA / Unity Vorbis / Cocos mp3-ogg)
• Plattformunterschiede dokumentieren: Mini-Programme benötigen Benutzerinteraktion vor der Wiedergabe, iOS-Stummschalter, Web-Autoplay-Richtlinien

Massenproduktion (G3) & Sprint-Zyklus

Erst nach bestandener G2 auf Basis der tatsächlichen Produktivität des Vertical Slices die Massenproduktion planen. Fülle docs/07-production-roadmap.md aus; wähle pro Sprint ein validierbares Ziel aus den Backlogs von Design, Programmierung, Art und Audio; dokumentiere mit docs/08-sprint-review.md Umfang, Verantwortliche, integrierten Build, Tests, Feedback und Retrospektive. Die Zykluslänge richtet sich nach der Teamfähigkeit, typischerweise 2–4 Wochen, bei kleinen Teams auch kürzer. Jeder Sprint endet mit einem Review eines tatsächlich spielbaren Builds; fehlgeschlagene oder nicht integrierte Arbeit deutlich kennzeichnen.

6. Test & Polishing (G4 / G5)

Beauftrage game-qa-engineer mit einem Testplan. Nach Alpha: Beta mit Inhaltslock, standardmäßig keine neuen Features; falls doch nötig, Auswirkungen auf Zeitplan, Testumfang und Gates dokumentieren und neu bewerten. Vor Gold muss ein echter Build ausgeführt werden, und ein Blick auf das Bild geworfen werden:

python scripts/build_check.py --project .                            # Zuerst Befehl prüfen
python scripts/build_check.py --project . --run --capture g4-beta     # Build + Start + Screenshot
python scripts/omni_state.py check --root . --stage qa --evidence     # Dokumente + Beweise gemeinsam validieren
python scripts/omni_state.py advance --root . --to release            # Ohne Beweise wird abgewiesen

Screenshots landen in docs/qa/evidence/<Name>/, receipt.json protokolliert die SHA256 der abgedeckten Dateien. Jede spätere Änderung lässt diese Beweise als veraltet erscheinen – veraltete Screenshots zählen nicht als Beweis, erneut aufnehmen.

Erfolgreiche Analyse bedeutet nicht, dass es läuft; Laufen bedeutet nicht, dass es richtig aussieht: Überlappender Text, überlaufende Panels, fehlende Elemente – das sieht man erst im Bild. Unity und Cocos haben keine integrierte unbeaufsichtigte Screenshot-Funktion; das Skript gibt ehrlich NOT ASSESSED zurück. Verwende in diesem Fall --capture-cmd mit einem Befehl oder sage klar, dass kein Bild angesehen wurde – nicht als bestanden werten. Falls ein Vorrücken dennoch nötig ist, kann --no-evidence verwendet werden, aber bei der Auslieferung muss explizit erwähnt werden, dass kein Bildschirmfoto vorliegt.

Bei fehlgeschlagenem Build das Log unverändert an den zuständigen Engine-Entwickler weitergeben; keine Spekulationen anstellen. Tatsächliche Tests, Plattformkompatibilität und Kandidaten-Build-Nachweise dokumentieren; die verantwortlichen Reviewer zur Bestätigung von Gold/Release einladen. Das advance-Skript wird Alpha, Beta, Gold oder die Release-Signatur nicht automatisch passieren lassen.

Verwende docs/09-milestones.md, um für G1–G5 Verantwortliche, Beweispfade und Entscheidungen zu dokumentieren. Alpha = Feature-Complete, Beta = Content-Lock, Gold = Release-Kandidat für Zielplattform bestanden; diese Status müssen manuell basierend auf echten Beweisen bestätigt werden, nicht aus der Dokumentationsphase abgeleitet.

7. Release & Betrieb

Beauftrage game-release-operator mit der Erstellung von docs/06-release.md. Alle Plattformzahlen mit dem Hinweis „Stand offiziell, zuletzt geprüft am [Datum]“ und einem Prüf-Einstiegspunkt versehen.

Nach dem Release: Live-Probleme, Crash/ Geschäftskennzahlen, Spielerfeedback und Hotfix-Status dokumentieren, zurück ins nächste Sprint-Backlog und in die Roadmap schreiben. Bei Bedarf nächste Sprint-Runde starten; done bedeutet nur Abschluss der aktuellen Artefakte, nicht Ende des Betriebs.

Bei der Übergabe an den Benutzer

## Aktuelle Phase
Phase + Gate-Status aus state.json

## Erstellte Artefakte
Liste aus docs/ und assets/, Anzahl der noch als placeholder markierten Elemente

## Build & Beweise
Ergebnis von build_check: Erfolg / Fehlschlag / Nicht ausgeführt; ob Screenshots vorhanden sind, welche Dateien abgedeckt werden, ob sie veraltet sind

## Unerledigte echte Lücken
Klar kommunizieren, was noch von Menschen erledigt werden muss

Eiserne Regeln

1. Keine Phasen überspringen: advance blockiert, nicht umgehen; Umgehen bedeutet unzuverlässige Auslieferung
2. Dokumente sind nicht das Ziel: Nach der tech-Phase müssen tatsächlich Code- und Ressourcendateien erstellt werden; nur Dokumente abzugeben gilt nicht als abgeschlossen
3. Build muss wirklich laufen: Ohne Build-Ergebnis in der qa-Phase ist release nicht erlaubt; das Status-Skript fängt dies nicht automatisch ab, manuelle Prüfung erforderlich
4. Entwurf zählt nicht als fertig: Ressourcen mit tier: "draft" dürfen nicht in den Release; der --final-Check blockiert. Bei der Übergabe muss klar sein, wie viele Drafts noch vorhanden sind
5. Zahlen mit Quellenangabe: Größenbeschränkungen, Engine-Fähigkeiten immer mit Versionsnummer und Überprüfungsmethode versehen
6. Jeder Sprint liefert einen spielbaren Build: Anzahl erledigter Aufgaben ersetzt nicht Build, Test und Review
7. Gates basieren auf Review-Beweisen: omni_state.py prüft nur Dokumententitel und TODOs; kann automatisch weder Gameplay, Build, Gerät noch Release-Genehmigung validieren
8. Artefakte vor Erzählungen: Wenn eine beauftragte Rolle behauptet, eine Datei geschrieben zu haben, prüfe die Existenz an diesem Pfad. Existiert sie nicht, ist die Phase FEHLGESCHLAGEN – nicht vorrücken, nicht als abgeschlossen zusammenfassen. Ein flüssiger Satz „Ich werde …“ ist kein Beweis; die Datei auf der Festplatte ist es.
9. Nach QA muss ein Screenshot existieren: Ohne verwendbaren Screenshot in docs/qa/evidence/ ist release nicht erlaubt; advance blockiert. NOT ASSESSED ist kein Bestehen

Was diese Pipeline nicht kann

• 3D-Modelle & Skelettanimationen: Diese Pipeline konzentriert sich auf 2D; AI-generierte Einzelbilder erfordern Prüfung und ggf. Nachbearbeitung.
• AI-Musik & Soundeffekte: Erfordert aktuell verfügbare Generierungstools oder externe Dienste mit Berechtigungen; prozedurale Synthese ist nicht gleich AI-Generierung.
• Kommerzielle Schriftarten: Nur OFL-Open-Source-Schriftarten sind erlaubt; kommerzielle Schriftarten muss der Benutzer selbst lizenzieren
• Für dich signieren, einreichen, prüfen: Kann nur Checklisten und Zeitpläne liefern, nicht das Backend für dich bedienen
• Echte Gerätekompatibilität: Erfordert physische Geräte
• Code-Freiheit von Bugs garantieren: Build bestanden ≠ Funktion korrekt; Funktion korrekt ≠ macht Spaß