huayuehua15-netizen/aaa-game-gdd

Compétence GDD pour jeux de qualité AAA (Game Design Document)

Convention de chemin : Tous les chemins scripts/, references/, assets/ dans ce fichier sont relatifs au répertoire contenant ce SKILL.md. Avant d'exécuter python scripts/new_gdd.py, assurez-vous d'être dans ce répertoire (Cursor/Codex l'installe via install.ps1 dans <projet>/skills/game-dev/aaa-game-gdd/). En cas de doute, trouvez d'abord le chemin absolu de ce SKILL.md, puis appelez le script avec ce chemin absolu ; utiliser un chemin relatif depuis la racine du projet générera une erreur "fichier non trouvé".

Que fait cette compétence

Transformer « J'ai une idée de jeu » en une documentation complète qui permet à une équipe de développer directement un jeu publiable sur Steam, comparable aux titres AAA. Le livrable principal est un ensemble structuré, quantifiable et vérifiable de documents Markdown en chinois (GDD), et non un simple document de conception vague.

Chaque document produit doit respecter trois règles absolues :

1. Développable : Le développeur n'a pas besoin de demander « quoi faire exactement, à quelle échelle, à quel standard ». Tout ce qui est quantifiable doit être spécifié avec des valeurs numériques (nombre de polygones, nombre d'images, durée, résolution, fréquence, délai, conditions de déclenchement).
2. Vérifiable : Chaque actif, chaque système, chaque scène possède une liste de contrôle Definition of Done (DoD) qui permet de cocher chaque critère une fois réalisé.
3. Cohérent : Tous les documents partagent les mêmes piliers de vision, bible artistique, conventions de nommage et budget de performance ; les documents se réfèrent les uns aux autres par des numéros et ne doivent pas se contredire.

Carte des documents (références à lire selon les besoins)

Ne lisez pas tous les documents de référence d'un coup. Identifiez d'abord le type de document dont l'utilisateur a besoin dans le tableau ci-dessous, puis lisez uniquement la référence correspondante. Chaque référence est structurée ainsi : problème résolu → quand l'écrire → structure des sections → comment écrire chaque section (avec standards quantifiables) → exemples bons/mauvais → liste de contrôle DoD.

Document	Quand lire cette référence	Modèle correspondant (assets/templates)
00 Aperçu du système documentaire	Nouveau projet, besoin de déterminer la liste des documents et le planning des phases	README.md
01 Vision et Pitch	Idée de jeu naissante, besoin d'une page pour présenter le jeu, pitch pour une présentation externe	01-vision-pitch.md
02 Bible artistique	Définir le style artistique, unifier l'esthétique de l'équipe, créer des briefs artistiques	02-art-bible.md
03 Scènes et Niveaux	Écrire des descriptions de scènes, des flux de niveaux, des déplacements, des rencontres, une narration environnementale	03-scene-level.md, scene-sheet.md, level-sheet.md
04 Systèmes de gameplay	Concevoir le cycle de base, le combat, la progression, l'économie, les tableaux de valeurs	04-gameplay-systems.md, system-sheet.md
05 Narration et Dialogues	Écrire le synopsis de l'histoire, les beats de chapitre, les embranchements, les scripts de dialogues, le doublage	05-narrative-dialogue.md, dialogue-sheet.md
06 Interaction et UI/UX	Définir les contrôles, la matrice d'interaction, le ressenti du jeu, le HUD, les menus, l'accessibilité	06-interaction-uiux.md
07 Spécifications des personnages	Conception, apparence, ensemble d'actions, IA, valeurs des protagonistes/ennemis/PNJ	07-character-spec.md, character-sheet.md
08 Spécifications de modélisation des objets	Modélisation, textures, LOD, conventions de nommage et livraison des objets/armes/actifs environnementaux	08-prop-modeling.md, prop-sheet.md
09 Spécifications d'animation	Animation squelettique 3D, machine à états d'animation, cinématiques, animation 2D par frames	09-animation-spec.md, animation-sheet.md
10 Conception audio	Musique, effets sonores, doublage, musique dynamique, volume du bus	10-audio-spec.md
11 Technologie et Performance	Choix du moteur, pipeline de rendu, budget de framerate/mémoire/taille du package, plateforme	11-tech-performance.md
12 Qualité AAA et Validation Steam	Jalons de phase, plan de QA, boutique Steam et publication, évaluation comparative AAA	12-steam-qa-checklist.md

Flux de travail

Procédure A : Nouveau projet (de l'idée au système documentaire complet)

1. Clarifier les informations minimales nécessaires (posez toutes les questions à l'utilisateur en une seule fois, maximum 4) : type de jeu et gameplay principal en une phrase, moteur (Unity/Unreal/Godot/non défini), plateforme et framerate cible (PC 60fps ? Steam Deck ?), orientation artistique. Une fois les réponses obtenues, commencez le travail ; ne posez pas de questions supplémentaires pour obtenir des informations complètes. Les éléments inconnus sont marqués explicitement 【À CONFIRMER】 dans les documents.
2. Lancer l'échafaudage : python scripts/new_gdd.py init --name "NomDuJeu" --out <répertoire de sortie> --engine <moteur confirmé à l'étape 1> pour générer l'arborescence complète du GDD. --engine doit utiliser la réponse de l'étape 1, ne mettez pas systématiquement unity — cela déterminera réellement les conventions d'axe, de nommage des collisions, de navigation et de métriques des données dans les documents.
3. Rédiger les documents par ordre de phase (voir « Jalons de phase » ci-dessous), lisez d'abord la référence correspondante, puis remplissez le modèle correspondant. Ordre : 01 Vision → 02 Bible artistique + 11 Budget technique → 04 Gameplay de base → 07/08/09/06 Spécifications → 03/05 Contenu → 12 Validation.
4. Pour chaque scène/personnage/objet/animation/dialogue/système, utilisez python scripts/new_gdd.py sheet pour générer une fiche individuelle, placez-la dans le sous-répertoire correspondant du GDD. Le document principal ne contient qu'une table d'index, n'empilez pas des centaines d'actifs dans un seul fichier.
5. Passer les jalons de qualité : à la fin de chaque phase, utilisez la liste de contrôle des jalons de 12-steam-qa-checklist.md pour vérifier chaque point ; ne passez pas à la phase suivante sans avoir satisfait à tous les critères.

Procédure B : Document unique (l'utilisateur n'a besoin que d'un type de document)

Confirmez l'objet et l'utilisation → Lisez la référence correspondante → Copiez le modèle correspondant et remplissez-le → Vérifiez avec la liste « DoD » à la fin de la référence → Livrez. Si l'utilisateur dit simplement « Aidez-moi à écrire une scène », demandez d'abord le nom de la scène / sa position dans le flux / l'événement clé (posez toutes les questions en une fois), puis produisez directement une fiche de scène complète, ne donnez pas simplement un modèle vide.

Scène vs Niveau : par défaut, ne produisez que le document demandé. references/03 dit « la scène est l'espace, le niveau est le temps, écrivez-les séparément », cela fait référence à la répartition du travail lorsque les deux sont nécessaires, pas à une obligation de produire une fiche de niveau à chaque fois qu'une scène est demandée.

La répartition est stricte :

• Fiche de scène (SC_) = Ce que l'espace offre : terrain, ligne de vue, couverture, dénivelé, issue de secours, cachettes, contraintes spatiales pour les ennemis (§7), et zones de déclenchement TZ_ (§4).
• Fiche de niveau (LV_) = Dans quel ordre le joueur vit quoi : tableau de beats (avec numéros d'événements EV_), rythme, conséquences des rencontres, points de contrôle.

Par conséquent :

• Utilisateur ne veut qu'une scène → n'écrivez que scene-sheet.md, sans ordre ; si vraiment aucune fiche de niveau n'est nécessaire, ajoutez une ligne dans §7 « Ordre de déroulement (simplifié) ».
• Utilisateur veut le flux du niveau, ou la scène a un rythme multi-phase → alors produisez également level-sheet.md, les deux se réfèrent l'un à l'autre via TZ_ ↔ EV_.
• Ne produisez pas automatiquement deux documents juste parce que 03 mentionne « écrivez-les séparément », cela ferait passer une simple demande à 2-3 fois plus de travail.

Lisez d'abord un exemple avant de remplir — chaque type de fiche a un exemple complet. Lisez directement l'exemple correspondant au type que vous allez écrire :

Type de fiche	Exemple	Ce qu'il faut surtout imiter
Scène (linéaire/horreur)	assets/examples/SC_01_外科楼二层走廊_示例.md	§7 Approvisionnement spatial = occlusion de la ligne de vue et « voir avant de toucher » ; §10 Axé sur la perception et le rythme
Scène (ouverte/BOSS)	assets/examples/SC_07_断桥瞭望台_示例.md	§7 Approvisionnement spatial = distance ajustable / interruption de ligne de vue / risque calculable ; §10 Axé sur la résolvabilité du combat
Niveau	assets/examples/LV_01_走廊初遇_示例.md	Comment le tableau de beats se recoupe avec TZ_ ; comment la courbe d'intensité et les points d'apprentissage sont intégrés sans pop-up
Personnage (ennemi)	assets/examples/EN_01_缝合者_示例.md	Pourquoi la machine à états §6 + différence de vitesse nécessite d'écrire « on peut s'échapper » ; comment la durée de combat §7 est calculée
Objet	assets/examples/PR_017_缺轮轮椅_示例.md	Valeurs des spécifications techniques §5 ; comment écrire « intentionnellement non fait » dans §7 DoD
Animation	assets/examples/AN_EN01_Slash_01_示例.md	Intervalle de frames en trois parties §2 ; points de déclenchement d'événements §3 (le son d'avertissement est le minimum d'équité)
Dialogue/Cinématique	assets/examples/DL_07_护士长录音_示例.md	Comment définir l'ID de réplique / durée / sous-titres conformes / interruption et reprise
Système	assets/examples/SYS_04_抓取挣脱_示例.md	§4 Le tableau de paramètres doit inclure « intention de conception » ; §5 Les cas limites ne doivent pas être oubliés

Tous les exemples doivent atteindre ce niveau de granularité (chaque élément a un nombre spécifique, un numéro, un contenu assignable). Note : les cases à cocher dans les exemples sont des enregistrements de validation après achèvement (nombre de polygones réel mesuré, date de révision, décisions de conception annulées), pas le format de remplissage avant le début du travail ; à l'étape v0.1, laissez les champs vides le cas échéant, n'inventez pas de chiffres qui semblent réels. §10 Risques de conception et hypothèses à valider est la seule section où il est permis et attendu qu'il n'y ait pas de chiffres.

Procédure C : Audit de documents/idées existants

Utilisez le « Tableau d'évaluation des dix dimensions AAA » de 12-steam-qa-checklist.md pour noter chaque dimension (1-10, avec preuves), listez les défauts bloquants pour la publication, les documents manquants, et les suggestions de modification classées par gravité. Les notes doivent citer le texte original du document ou les éléments manquants ; les évaluations vagues sont interdites.

Jalons de phase (Stage Gates)

Phase	Documents obligatoires	Jalon (ne pas passer sans le franchir)
Concept	01 Vision, 04 Structure de base du gameplay	Le plaisir central est validé sur papier / par prototype boîte grise ; les 3 piliers centraux sont approuvés par tous
Tranche verticale	02, 06, 11 + au moins 1 fiche exemple par catégorie (scène/personnage/objet/animation/dialogue)	Le flux de 10-15 minutes atteint la qualité finale attendue ; tous les systèmes centraux fonctionnent ; le budget de performance est respecté
Production	Tous les documents essentiels + toutes les fiches d'actifs	Chaque fiche d'actif peut être directement assignée ; la capacité et les jalons peuvent être planifiés
Alpha	Tout le contenu	Feature Complete : le jeu peut être terminé du début à la fin, sans système factice
Bêta	Idem + 12 Tableau de validation	Content Complete ; zéro bug S/A ; parcours complet × 3 configurations
RC/Publication	Tous les points de la liste Steam dans 12 sont cochés	Page boutique, validation Steam Deck, localisation, classification, compatibilité des sauvegardes : tout est OK

Script d'échafaudage

# Initialiser l'arborescence complète du GDD (crée <NomDuJeu>_GDD/ dans le répertoire de sortie)
python scripts/new_gdd.py init --name "NomDuJeu" --out "D:/MonJeu" --engine unity
#   --engine : unity | unreal | godot | agnostic (par défaut)
#             ★ Ce n'est pas décoratif : le choix détermine réellement le format d'échange, les conventions d'axe, le nommage des collisions, la navigation, les métriques des données et le LOD dans les documents
#   --genre : optionnel, description du type de jeu, sera écrite dans le document de vision
#   --dimension : 3d (par défaut) | 2d (crée en plus les sous-répertoires sprites/ et tilesets/)

# Générer une fiche individuelle pour un objet (placée automatiquement dans le sous-répertoire correspondant)
python scripts/new_gdd.py sheet --type scene --name "Hôpital abandonné" --out "D:/MonJeu/NomDuJeu_GDD"
#   --type : scene | level | character | prop | animation | dialogue | system | sprite | tileset
#   --subtype : pour character, utiliser player/enemy/npc (CH/EN/NPC) ; pour prop, utiliser item/weapon (PR/WP)
#   Exemple : sheet --type character --subtype enemy --name "Le Fronceur" → characters/EN_01_LeFronceur.md
#   Exemple : sheet --type sprite --name "HeroIdle" → sprites/SPR_01_HeroIdle.md

init supporte aussi --dimension 2d : crée en plus les sous-répertoires sprites/ et tilesets/ (pour les projets 2D).

Le script remplace automatiquement les espaces réservés {{GAME_NAME}}, {{DATE}}, {{ENGINE}}. Si le script n'est pas disponible, copiez manuellement les modèles depuis assets/templates/.

Règles générales d'écriture

• En-tête du document : Chaque document commence par : numéro de document, version, état (brouillon / en révision / verrouillé), date de dernière mise à jour, responsable, numéros des documents associés. Pour les fiches d'actifs, ajoutez le nom de la ressource dans le moteur (ex. SM_Prop_HospitalWheelchair_01).
• Quantification prioritaire : Interdiction des descriptions non vérifiables comme « bon ressenti », « belle image », « ennemi puissant ». Écrivez plutôt : « 8 frames entre l'appui sur attaque et l'activation du jugement (0.13 s à 60 ips) », « PV ennemi 120, DPS du joueur optimisé 45, durée de combat attendue 35-45 s ».
• Marquez l'incertitude : Pour les valeurs inconnues, écrivez 【À CONFIRMER : raison/responsable/délai】. N'inventez pas de chiffres pour faire semblant d'être certain ; les valeurs issues de l'expérience du secteur peuvent être utilisées directement, marquées « Valeur par défaut du secteur, à ajuster après le premier test ».
• Exigences graphiques : Les scènes, niveaux et UI doivent être accompagnés de schémas de disposition (plan ASCII, diagramme de flux/état Mermaid, ou référence à un numéro de concept art) ; les machines à états, les arbres de dialogue, les flux de menus doivent être représentés avec Mermaid ; les paramètres et listes doivent être dans des tableaux.
• Chaque document doit avoir un DoD : À la fin du document, incluez une liste de contrôle DoD (cases à cocher - [ ]). C'est le seul critère de validation pour la livraison.
• Langue : Texte principal en chinois ; les noms propres, API du moteur, noms de ressources conservés en anglais ; les scripts de dialogues doivent également inclure des champs réservés pour l'anglais/autres langues.
• Modifications des documents versionnées : Après verrouillage, les modifications doivent être enregistrées dans un journal des versions à la fin du document (version, date, ce qui a changé).

Exigences de livraison

• Le livrable est constitué de fichiers Markdown placés dans le répertoire du projet de l'utilisateur (arborescence d'échafaudage + documents remplis), pas d'un plan dans le chat.
• Après chaque livraison, indiquez à l'utilisateur : quel document rédiger ensuite, sur quels 【À CONFIRMER】 il doit prendre une décision.
• La qualité du document est testée selon le critère suivant : « Un artiste / programmeur extérieur fraîchement arrivé peut, en lisant uniquement la fiche correspondante, produire un actif de qualité acceptable de manière indépendante. »