Transformer un GDD en plan de production
Un GDD « actionnable » ne se limite pas à décrire le jeu : il doit permettre de produire le jeu. Le plan de production est la traduction du GDD en fonctionnalités priorisées, jalons, tâches, critères d’acceptation et estimations. L’objectif est de rendre le travail planifiable, testable et pilotable (scope, risques, dépendances).
Étape 1 — Lister les fonctionnalités en Must / Should / Could
Commencez par extraire du GDD une liste de fonctionnalités formulées comme des capacités observables (ce que le joueur peut faire/voir/entendre) et non comme des intentions vagues. Classez ensuite en trois niveaux :
- Must : indispensable pour que le jeu soit jouable et corresponde à la promesse minimale.
- Should : améliore fortement l’expérience, mais le jeu reste cohérent sans.
- Could : bonus, polish ou variété ; à faire seulement si le temps le permet.
Règle pratique : si vous ne pouvez pas imaginer une démo jouable sans cette fonctionnalité, c’est probablement un Must.
| Catégorie | Exemples de formulation | Pièges à éviter |
|---|---|---|
| Must | « Le joueur peut se déplacer, sauter, subir des dégâts et mourir » | « Gameplay fun », « sensation fluide » (non testable) |
| Should | « 3 types d’ennemis avec comportements distincts » | Ajouter trop tôt des variantes de contenu |
| Could | « Mode défi chronométré » | Créer des systèmes parallèles qui multiplient les tests |
Étape 2 — Définir les jalons (prototype → vertical slice → contenu complet → polishing)
Les jalons sont des points de contrôle qui valident que le jeu progresse vers un produit jouable et publiable. Pour un petit jeu, utilisez 4 jalons standards :
- Prototype jouable : boucle de gameplay minimale fonctionnelle (sans forcément d’art final).
- Vertical slice : un extrait représentatif « qualité cible » (un niveau/une zone) avec intégration des systèmes clés.
- Contenu complet : tous les niveaux/ennemis/objets prévus sont présents, même si le polish est incomplet.
- Polishing : correction, équilibrage, performance, UX, audio mix, finitions.
Conseil : chaque jalon doit se conclure par une build jouable et une courte liste « OK / KO » basée sur des critères d’acceptation (voir plus bas).
Continuez dans notre application.
Vous pouvez écouter le livre audio écran éteint, recevoir un certificat gratuit pour ce cours et accéder également à 5 000 autres cours en ligne gratuits.
Ou poursuivez votre lecture ci-dessous...
Téléchargez l'application
Étape 3 — Cartographier les dépendances
Les dépendances indiquent l’ordre logique de production. Elles évitent de planifier des tâches impossibles à terminer faute de prérequis. Travaillez à deux niveaux :
- Dépendances système : ex. le combat dépend du système de dégâts, qui dépend des collisions et des hitboxes.
- Dépendances contenu : ex. les niveaux dépendent des tilesets, des règles de spawn et des triggers.
Une méthode simple consiste à créer une liste « A → B » (A doit exister avant B) :
Mouvement → Collisions → Dégâts/HP → Combat → Ennemis → Niveaux → Progression/Score → UI → Audio feedbackAstuce : si une fonctionnalité a plus de 3 dépendances, c’est souvent un signe de complexité à réduire (ou à découper).
Étape 4 — Identifier les risques et prévoir des mesures de réduction
Un plan actionnable inclut les risques majeurs et une réponse concrète. Pour un petit jeu, regroupez-les en trois familles : scope, complexité, content.
| Risque | Symptôme | Mesure de réduction (pratique) |
|---|---|---|
| Scope (trop de fonctionnalités) | Backlog grossit, jalons glissent | Geler les Must, déplacer des Should/Could après le vertical slice, limiter le nombre de niveaux/ennemis |
| Complexité (systèmes difficiles) | Bugs récurrents, intégration lente | Prototyper tôt les points durs, choisir une version « simple d’abord » (IA basique, collisions simples), supprimer les cas rares |
| Content (trop d’assets) | Production artistique/audio devient le goulot | Réutiliser/modulariser, réduire la variété, privilégier des variations paramétriques (couleurs, stats), produire un kit minimal pour le vertical slice |
Exercice rapide : pour chaque risque, écrivez une phrase « Si X arrive, alors on fait Y » (décision pré-acceptée). Exemple : « Si l’IA du boss dépasse 2 jours, on remplace par un pattern de projectiles + dash télégraphié. »
Critères d’acceptation : définir les conditions de “terminé”
Un critère d’acceptation décrit ce qui doit être vrai pour considérer une fonctionnalité comme terminée. Il doit être testable, mesurable ou au minimum observable en jeu. Sans critères, les tâches restent « presque finies » indéfiniment.
Format recommandé
- Contexte : situation de test (niveau, personnage, conditions).
- Action : ce que fait le joueur.
- Résultat attendu : comportement vérifiable.
- Non-régression : ce qui ne doit pas casser (si pertinent).
Vous pouvez les écrire sous forme de checklist :
Fonctionnalité : Dash du joueur (Must) — Terminé si : 1) Le joueur peut déclencher un dash au sol avec une touche dédiée. 2) Le dash dure entre 0,15s et 0,25s (valeur configurable). 3) Pendant le dash, la vitesse horizontale est supérieure à la course normale. 4) Un cooldown empêche de redasher avant X secondes (configurable). 5) Le dash ne traverse pas les murs (collisions respectées). 6) Un feedback visuel et un son se déclenchent à l’activation. 7) Aucun crash ni blocage d’input après 30 dashes consécutifs.Exemples de critères d’acceptation (petit jeu 2D)
| Fonctionnalité | Critères d’acceptation (extraits) |
|---|---|
| Déplacement + saut | Le personnage répond en moins d’une frame aux inputs; saut variable (maintien) fonctionne; collisions sol/murs stables; pas de tremblement sur pentes (si utilisées) |
| Dégâts et invincibilité | À l’impact, HP diminue; invincibilité temporaire empêche les dégâts multiples; feedback (flash/son); mort déclenche écran de fin/respawn |
| UI HUD | HP affiché et mis à jour; score/collectibles affichés; pause fige le gameplay; navigation clavier/manette cohérente |
| Fin de niveau | Atteindre la sortie déclenche transition; temps/score final calculé; retour menu ou niveau suivant; sauvegarde du progrès (si prévu) |
Règle pratique : une fonctionnalité « terminée » doit être jouable dans une build, pas seulement « codée ».
Préparer un backlog : tâches par systèmes + estimation S/M/L
Le backlog est la liste ordonnée des tâches à réaliser. Pour rester simple, regroupez par systèmes (mouvement, combat, UI, niveaux, audio) et estimez en S/M/L. L’estimation n’est pas une promesse : c’est un outil de priorisation.
Définir l’échelle S/M/L
- S (Small) : 0,5 à 1 jour (tâche isolée, faible risque).
- M (Medium) : 1 à 3 jours (intégration ou plusieurs cas).
- L (Large) : 3 à 5 jours (risque, R&D, plusieurs systèmes).
Règle : si une tâche dépasse L, découpez-la en sous-tâches jusqu’à obtenir des items testables.
Structure d’une carte de backlog (modèle)
Chaque item doit contenir :
- ID (ex. MOV-03)
- Description (verbe + objet)
- Priorité (Must/Should/Could)
- Estimation (S/M/L)
- Dépendances
- Critères d’acceptation (checklist courte)
ID: COM-02 Description: Implémenter les dégâts sur hitbox Priorité: Must Estimation: M Dépendances: MOV-02 (collisions), ENT-01 (HP) Acceptation: (1) Un hit réduit HP de N (configurable) (2) Invincibilité X sec (3) Feedback visuel+son (4) Testé sur 3 ennemisLivrable 1 — Modèle de plan de production (copiable)
Utilisez ce modèle tel quel (document ou tableur). Il relie fonctionnalités, jalons, dépendances, risques et critères d’acceptation.
| Section | Contenu attendu | Exemple (résumé) |
|---|---|---|
| Vision de production | Objectif, contraintes, définition du “done” global | Build stable, 5 niveaux, 3 ennemis, 1 boss, menus, audio, 60 FPS cible |
| Fonctionnalités Must/Should/Could | Liste priorisée | Must: mouvement, combat, UI, 5 niveaux; Should: boss; Could: mode défi |
| Jalons | Prototype, vertical slice, contenu complet, polishing + critères de sortie | Vertical slice = 1 niveau complet + 1 ennemi + UI + audio feedback |
| Dépendances | Chaîne d’ordre logique | Mouvement → collisions → dégâts → ennemis → niveaux → UI → audio |
| Risques & mitigations | Top 5 risques + plan B | Scope: réduire niveaux; Complexité: IA simple; Content: kit minimal |
| Backlog | Liste de tâches + estimations + assignation | Voir livrable 2 |
Livrable 2 — Exemple de backlog (petit jeu 2D)
Hypothèse de jeu (pour l’exemple) : platformer 2D court où le joueur traverse 5 niveaux, combat des ennemis simples, collecte des pièces, et affronte un mini-boss. (Les détails de design ne sont pas répétés ici ; on se concentre sur la production.)
Mouvement (MOV)
| ID | Tâche | Prio | Est. | Dépendances |
|---|---|---|---|---|
| MOV-01 | Contrôles gauche/droite + accélération/décélération | Must | M | - |
| MOV-02 | Collisions sol/murs + détection “grounded” | Must | L | MOV-01 |
| MOV-03 | Saut (hauteur variable) + coyote time (optionnel) | Must | M | MOV-02 |
| MOV-04 | Dash (cooldown configurable) + feedback | Should | M | MOV-02 |
| MOV-05 | Points de respawn + repositionnement stable | Must | S | MOV-02 |
Combat & entités (COM/ENT)
| ID | Tâche | Prio | Est. | Dépendances |
|---|---|---|---|---|
| ENT-01 | Composant HP + mort (joueur/ennemi) | Must | M | - |
| COM-01 | Attaque de base (melee ou projectile) + hitbox | Must | L | MOV-02 |
| COM-02 | Dégâts, invincibilité, knockback (si prévu) | Must | M | ENT-01, COM-01 |
| ENM-01 | Ennemi type A : patrouille + contact damage | Must | M | COM-02 |
| ENM-02 | Ennemi type B : distance simple (tir périodique) | Should | M | COM-02 |
| BOS-01 | Mini-boss : 2 patterns + phase de vulnérabilité | Should | L | ENM-01, COM-02 |
UI / Menus (UI)
| ID | Tâche | Prio | Est. | Dépendances |
|---|---|---|---|---|
| UI-01 | HUD : HP + pièces/score | Must | M | ENT-01 |
| UI-02 | Menu pause + reprise + options simples (volume) | Must | M | - |
| UI-03 | Écran fin de niveau (temps/score) + bouton suivant | Must | M | LVL-03 |
| UI-04 | Écran game over + restart | Must | S | ENT-01 |
Niveaux & progression (LVL)
| ID | Tâche | Prio | Est. | Dépendances |
|---|---|---|---|---|
| LVL-01 | Pipeline de niveau : chargement scène + points de spawn | Must | M | MOV-05 |
| LVL-02 | Triggers : sortie de niveau + checkpoints | Must | M | LVL-01 |
| LVL-03 | Objectif de niveau + conditions de victoire | Must | S | LVL-02 |
| LVL-04 | Construire niveau vertical slice (1 niveau complet) | Must | L | LVL-01, ENM-01, UI-01 |
| LVL-05 | Construire niveaux 2 à 5 (itératif) | Must | L | LVL-04 |
| LVL-06 | Placement mini-boss + arène + récompense | Should | M | BOS-01, LVL-05 |
Audio & feedback (AUD/VFX)
| ID | Tâche | Prio | Est. | Dépendances |
|---|---|---|---|---|
| AUD-01 | SFX essentiels : saut, hit, mort, pickup | Must | M | MOV-03, COM-02 |
| AUD-02 | Musique : boucle niveau + boss (intégration) | Should | M | LVL-04, BOS-01 |
| VFX-01 | Feedback visuel : hit flash, impact, pickup | Must | M | COM-02 |
| AUD-03 | Mix simple : volumes relatifs + options | Must | S | UI-02, AUD-01 |
Qualité, intégration, release (QA/REL)
| ID | Tâche | Prio | Est. | Dépendances |
|---|---|---|---|---|
| QA-01 | Checklist tests régression (mouvement/combat/UI) | Must | S | - |
| QA-02 | Stabilité : corriger top 10 bugs bloquants | Must | L | Vertical slice |
| REL-01 | Build finale + paramètres par défaut + versioning | Must | S | QA-02 |
Relier backlog et jalons (exemple d’affectation)
Pour rendre le plan pilotable, associez chaque tâche à un jalon. Exemple :
- Prototype jouable : MOV-01 à MOV-03, ENT-01, COM-01/02, ENM-01 (version simple), UI-01 (minimal), LVL-01/02 (minimal).
- Vertical slice : LVL-04, VFX-01, AUD-01, UI-02, QA-01, amélioration ENM-01.
- Contenu complet : LVL-05, ENM-02, UI-03/04, AUD-02.
- Polishing : QA-02, AUD-03, ajustements difficulté, corrections, optimisation.
Contrôle de scope : si le vertical slice n’est pas atteint à la date prévue, déplacez immédiatement des items Should/Could hors du périmètre (ne touchez pas aux Must nécessaires à la boucle).
