NextAgentX/pipeline-production-jeu

Pipeline de production de jeu de bout en bout

Faites passer une idée jusqu'à un artefact compilable + un plan de publication. Chaque étape a des artefacts, des chemins et des portes d'étape exécutables fixes ; le saut d'étape n'est pas autorisé.

Les rôles suivants sont optionnels : à utiliser uniquement lorsque l'environnement actuel les prend en charge et que la délégation est autorisée ; sinon, l'assistant actuel les exécute directement. Choisissez le périmètre de travail en fonction de l'autorisation réelle de l'utilisateur et de la phase du projet. Les scripts d'état vérifient uniquement les titres de documents et les TODO, ils ne vérifient pas automatiquement les ressources, la construction réelle ou la validation sur appareil réel ; celles-ci doivent être exécutées séparément et les résultats enregistrés.

Les cinq phases de production, jalons G1–G5, cycles Sprint et ajustements de taille d'équipe sont décrits dans references/production-cycle.md. Le tableau des sept phases ci-dessous correspond aux sous-portes d'étape des artefacts de documents, et non aux jalons de production.

Phases et artefacts

Phase	Livrable	Rôle responsable
brief	docs/00-brief.md Fiche de projet	Producteur (vous-même)
gdd	docs/01-gdd.md	game-narrative-designer
tech	docs/02-tech.md	cocos-engineer, unity-engineer ou godot-engineer
art	docs/03-art.md + docs/art-style-bible.md + Art final + assets/manifest.json	game-art-director
audio	docs/04-audio.md + Audio final	game-audio-designer
qa	docs/05-qa.md	game-qa-engineer
release	docs/06-release.md	game-release-operator

Les squelettes se trouvent tous dans templates/docs/ du plugin, copiez-les dans docs/ du projet puis remplissez-les. Si les [TODO] dans le squelette ne sont pas remplis, la porte d'étape ne laisse pas passer.

Outils (intégrés au plugin, appelez-les directement avec python)

Le répertoire des scripts = scripts/ à la racine de ce plugin. Si le chemin absolu est incertain, faites d'abord codex plugin list pour trouver le chemin du plugin.

Utilisation	Commande
Initialiser l'état	python scripts/omni_state.py init --root . --engine godot --platforms web,android
Voir l'avancement des phases	python scripts/omni_state.py status --root .
Valider une seule phase	python scripts/omni_state.py check --root . --stage gdd
Avancer une phase (avec porte d'étape)	python scripts/omni_state.py advance --root .
Générer des artworks de substitution (validation du pipeline uniquement)	python scripts/gen_placeholder_art.py --manifest assets/manifest.json --root .
Feuille de route de production	Copier templates/docs/07-production-roadmap.md dans docs/
Planification et rétrospective Sprint	Copier templates/docs/08-sprint-review.md, enregistrer la version intégrée, les tests et les retours à chaque cycle
Revue de porte d'étape	Copier templates/docs/09-milestones.md, enregistrer les revues G1–G5 et post-lancement
Post-traitement d'art final	python scripts/process_art.py --in raw/x.png --out assets/art/x.png --size 256x64 --key-color "#FFFFFF" --check-nine --nine-slice 24
Découpage d'animations IA en frames	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
Image / GIF IA	python scripts/gen_ai_image.py --prompt "single game icon" --format png --out assets/art/icon.png --backup-dir doc/temp --dry-run
Effet sonore IA	python scripts/gen_ai_audio.py sfx --prompt "short sci-fi pickup" --duration 1 --out assets/audio/pickup.mp3
Musique IA	python scripts/gen_ai_audio.py music --prompt "gentle space exploration" --duration 30 --instrumental --out assets/audio/main.mp3
Générer BGM (chiptune)	python scripts/gen_music.py --style upbeat --out assets/audio/bgm_main.wav --tempo 132 --bars 16
Synthétiser un effet sonore	python scripts/gen_sfx.py --preset hit --out assets/audio/sfx_hit.wav
Estimation de compression audio	python scripts/compress_audio.py --dir assets/audio --check
Empaqueter un atlas	python scripts/pack_atlas.py --input assets/art/ui --out-sheet assets/art/ui_atlas.png --out-data assets/art/ui_atlas.json
Valider la liste des ressources	python scripts/validate_assets.py --manifest assets/manifest.json --root .
Inspection finale avant publication	python scripts/validate_assets.py --manifest assets/manifest.json --final --strict-license
Vérification/validation du build	python scripts/build_check.py --project . → ajoutez --run pour un build réel

Ordre d'exécution

0. Mettre en place le squelette du projet

cp -r <plugin>/templates/godot4/* .        # ou 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 "Lancement" --next "Écrire le brief"

Avant de commencer, lisez .omni/active.md (s'il existe) : il contient la tâche en cours et les blocages de la session précédente, plus fiable que la conversation après une compression ou un changement de session.

Les trois modèles ont des niveaux de maturité différents, vous devez en informer honnêtement l'utilisateur :

Modèle	Statut	Étapes manuelles nécessaires
godot4	Exécutable directement (importation testée + scène principale fonctionnelle)	Aucune
unity	Ouvrable, la scène doit être générée	Menu Tools ▸ Omni ▸ Create Main Scene
cocos3	Code et configuration prêts	Créer une scène → attacher GameRoot au Canvas → définir la scène de démarrage

1. Lancement et concept (G1)

Clarifiez cinq choses : expérience de base, priorité de plateforme, périmètre MVP, monétisation et conformité, ressources existantes et moteur. Remplir docs/00-brief.md et docs/01-gdd.md, enregistrer les hypothèses à vérifier et la décision Go / No-Go. Estimer le budget et les jalons en fonction de la taille de l'équipe et indiquer les incertitudes.

2. gdd

Déléguer à game-narrative-designer. Exigences : donner des valeurs numériques spécifiques, chaque élément doit être vérifiable, lister séparément les « exigences pour les capacités du moteur ». Remplir puis advance.

3. Pré-production et vertical slice (G2)

Déléguer à cocos-engineer, unity-engineer ou godot-engineer selon le moteur. Exigences : d'abord fournir les données de profilage, puis les optimisations ; les configurations de build par plateforme doivent être spécifiques, jusqu'au format de texture et à la stratégie de partitionnement. Implémenter un prototype jouable tôt pour valider le cœur du cycle de jeu.

4. art (mise en place des ressources finales)

Déléguer à game-art-director pour produire docs/03-art.md et assets/manifest.json, puis exécuter selon la compétence game-art-production :

1. D'abord créer la bible de style docs/art-style-bible.md : un texte d'ancrage de style fixe + palette + éléments interdits
2. Générer les ressources une par une : utiliser l'outil d'image de la session en cours ou l'API d'image IA configurée, générer des variantes si nécessaire ; demander une sortie transparente si un fond transparent est requis, respecter les règles de sauvegarde d'images du projet. Les animations suivent la compétence game-animation-production pour générer des GIF ou des feuilles de sprites et vérifier le découpage.
3. Post-traiter selon les spécifications :

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. Enregistrer dans le manifest : tier: "final" + source + license + commercial_ok + ai_generated
5. Inspection finale : validate_assets.py --final --strict-license

Avant G2, réalisez une vertical slice complète mais de petite envergure, intégrant la programmation, le game design, l'art et l'audio dans le moteur cible ; testez concrètement la qualité visuelle, le pipeline de ressources, la construction et les performances. Ne planifiez pas la production en série basée sur une démo avant que la tranche n'ait prouvé la répétabilité de la solution et l'acceptabilité des coûts. Les scripts d'état dans le plugin vérifient uniquement les documents, ils ne valideront pas cette porte à votre place.

5. Production audio

Déléguer à game-audio-designer pour produire docs/04-audio.md, puis choisir une voie selon la compétence game-audio-production :

• Voie A (Génération IA) : privilégier les outils de génération audio actuellement disponibles ; ou utiliser gen_ai_audio.py avec l'API ElevenLabs, voir game-audio-production. Les clés de service, autorisations, facturation et licences doivent être clairement établies à l'avance.
• Voie B (8-bit, hors ligne, zéro coût) :

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

• Compression obligatoire : python scripts/compress_audio.py --dir assets/audio --bitrate 96k ; sans ffmpeg, utiliser la compression à l'importation du moteur selon les instructions du script (Godot QOA / Unity Vorbis / Cocos mp3-ogg)
• Noter les différences de plateforme : les mini-jeux nécessitent une lecture après interaction, bouton silencieux iOS, stratégie de lecture automatique Web

Production en masse (G3) et cycles Sprint

Ne planifier la production en masse qu'après avoir passé G2, sur la base de la capacité de production réelle de la vertical slice. Remplir docs/07-production-roadmap.md ; à chaque cycle, sélectionner un objectif vérifiable dans le backlog de game design, programmation, art ou audio, utiliser docs/08-sprint-review.md pour enregistrer le périmètre, le responsable, le build intégré, les tests, les retours et la rétrospective. La durée du cycle est à définir selon la capacité de l'équipe, généralement 2 à 4 semaines, plus courte pour les petites équipes. Chaque cycle se termine par une revue d'une version jouable réelle ; le travail non intégré ou échoué est clairement marqué.

6. Tests et polissage (G4 / G5)

Déléguer à game-qa-engineer pour produire le plan de test. Après Alpha, passer en Beta avec un contenu verrouillé, par défaut arrêter l'ajout de fonctionnalités ; si une fonctionnalité doit vraiment être ajoutée, enregistrer son impact sur le calendrier, le périmètre des tests et les portes d'étape, et réévaluer. Avant de préparer le Gold, il faut impérativement exécuter un build réel, et jeter un œil à l'écran :

python scripts/build_check.py --project .                            # d'abord voir la commande
python scripts/build_check.py --project . --run --capture g4-beta     # build + lancement + capture d'écran
python scripts/omni_state.py check --root . --stage qa --evidence     # validation document + preuve
python scripts/omni_state.py advance --root . --to release            # sans preuve, sera bloqué

Les captures d'écran sont placées dans docs/qa/evidence/<nom>/, receipt.json enregistre le sha256 des fichiers couverts. Toute modification ultérieure rendra cette preuve expirée — une capture expirée ne compte pas comme preuve, refaites la capture.

Analyser ne signifie pas que ça tourne, et tourner ne signifie pas que ça s'affiche correctement : texte qui dépasse, panneaux qui débordent, éléments qui n'apparaissent pas, on ne le voit qu'en regardant l'écran. Unity et Cocos n'ont pas de capacité intégrée de capture d'écran sans surveillance, le script retournera honnêtement NOT ASSESSED ; dans ce cas, utilisez --capture-cmd pour donner une commande, ou dites clairement "n'a pas vu l'écran", ne le considérez pas comme un succès. Si vous devez vraiment avancer sans preuve, utilisez --no-evidence, mais au moment de la livraison, vous devez indiquer que vous n'avez pas vu l'écran.

Si le build échoue, remettez le journal à l'ingénieur moteur concerné tel quel, ne devinez pas. Enregistrez les tests réels, la compatibilité des plateformes et les preuves des candidats à la publication, invitez les responsables à une revue avant de confirmer Gold / Release. Le advance documentaire ne valide pas automatiquement Alpha, Beta, Gold ou la signature de la publication.

Utilisez docs/09-milestones.md pour enregistrer les responsables, les chemins de preuve et les décisions pour G1–G5. Alpha = fonctionnalité complète, Beta = contenu verrouillé, Gold = candidat à la publication sur la plateforme cible approuvé par la revue ; ces statuts doivent être confirmés manuellement sur la base de preuves réelles, ils ne peuvent pas être déduits de la phase documentaire.

7. Publication et exploitation

Déléguer à game-release-operator pour produire docs/06-release.md. Tous les chiffres de plateforme doivent être accompagnés de « à confirmer avec les sources officielles les plus récentes » et d'un point d'entrée pour la vérification.

Après la publication, enregistrer les problèmes en ligne, les indicateurs de crash/métier, les retours des joueurs et l'état des correctifs, reporter dans le backlog de la prochaine version et la feuille de route. Lancer le prochain cycle Sprint si nécessaire ; done ne signifie que la fin des artefacts de ce cycle, pas l'arrêt de l'exploitation.

Lors de la livraison à l'utilisateur

## Phase actuelle
phase dans state.json + statut de la porte d'étape

## Artefacts produits
Liste des docs/ et assets/, indiquer le nombre de placeholders restants

## Build et preuves
Résultat du build_check : succès / échec / non exécuté ; y a-t-il des captures d'écran, quels fichiers couvrent-elles, sont-elles expirées

## Lacunes réelles non comblées
Expliquer clairement ce qui nécessite encore une intervention humaine

Règles absolues

1. Ne pas sauter de phase : advance bloquera, ne contournez pas ; contourner rend la livraison non fiable
2. Le document n'est pas une fin : après la phase tech, il faut réellement produire du code et des fichiers de ressources ; livrer seulement un document ne compte pas comme terminé
3. Le build doit être réellement exécuté : sans résultat de build en phase qa, n'entrez pas en release ; les scripts d'état ne bloqueront pas automatiquement, nécessite une vérification manuelle
4. Draft n'est pas terminé : les ressources avec tier: "draft" ne peuvent pas entrer en publication ; l'inspection --final bloquera. Au moment de la livraison, vous devez indiquer combien de draft il reste
5. Les chiffres doivent avoir une source : la limite de taille du package, les capacités du moteur, tout doit être accompagné de la version et du mode de vérification
6. Chaque Sprint doit livrer une version jouable : le nombre de tâches terminées ne remplace pas le build, les tests et la revue
7. Les portes d'étape se basent sur les preuves de la revue : omni_state.py ne vérifie que les titres de documents et les TODO, il ne peut pas valider automatiquement le gameplay, le build, le matériel ou l'approbation de publication
8. Les artefacts priment sur le récit : si un rôle délégué prétend avoir écrit un fichier, vérifiez que ce chemin existe. S'il n'existe pas, c'est PHASE FAILED — n'avancez pas, ne résumez pas comme terminé. Un discours fluide « je vais... » n'est pas une preuve, les fichiers sur le disque le sont
9. Après qa, des captures d'écran sont obligatoires : sans capture utilisable dans docs/qa/evidence/, n'entrez pas en release ; advance bloquera. NOT ASSESSED n'est pas un succès

Ce que ce pipeline ne peut pas faire

• Modèles 3D et animations squelettiques : cette chaîne se concentre sur la 2D ; les résultats d'images IA générées frame par frame doivent être vérifiés et peuvent nécessiter des retouches.
• Musique et effets sonores IA : nécessite un outil de génération actuellement disponible ou un service externe avec autorisation ; la synthèse procédurale n'équivaut pas à la génération IA.
• Polices commerciales : seules les polices open source OFL peuvent être utilisées, les polices commerciales nécessitent que l'utilisateur achète lui-même la licence
• Signer, mettre en ligne, passer les examens à votre place : peut seulement fournir une liste et un calendrier, ne peut pas cliquer sur le panneau d'administration à votre place
• Validation de compatibilité sur appareil réel : nécessite un appareil réel
• Garantir que le code est sans bug : le build réussi ≠ fonctionnalité correcte, fonctionnalité correcte ≠ amusant