Cadrage du petit jeu et structure d’un Game Design Document (GDD)

Définir le périmètre d’un petit jeu réalisable

Un « petit jeu » (dans le cadre de ce cours) est un projet volontairement limité, conçu pour être prototypé, testé et finalisé sans multiplier les systèmes. Le cadrage sert à éviter l’effet « boule de neige » : chaque nouvelle idée entraîne des dépendances (UI, animations, niveaux, équilibrage, sauvegarde, etc.). L’objectif est de décider, noir sur blanc, ce qui est inclus et ce qui est exclu.

Paramètres de cadrage à fixer (et à écrire dans le GDD)

• Genre : choisissez un genre simple à boucler (ex. platformer court, puzzle, shooter arena, runner). Évitez les genres qui exigent beaucoup de contenu (RPG narratif, open world, simulation complexe).
• Perspective 2D : précisez 2D vue de côté, top-down, isométrique 2D (si vous la considérez 2D), et les implications (collisions, lecture, caméra).
• Durée d’une session : visez une boucle courte et répétable (ex. 2–5 minutes) ou un niveau court (ex. 3–10 minutes). Cela guide le rythme, la difficulté et la quantité de contenu.
• Complexité volontairement limitée : fixez un plafond de systèmes (ex. 1 mécanique principale + 1 mécanique secondaire maximum). Définissez aussi un plafond de contenu (ex. 10 niveaux max, 5 types d’ennemis max, 3 power-ups max).

Exemples de périmètres « petits jeux » (réalistes)

Méthode pratique : cadrer en 10 minutes (pas à pas)

1. Écrivez une phrase : « Le joueur fait X pour atteindre Y, en évitant Z. »
2. Choisissez la perspective 2D (side/top-down) et notez la caméra (fixe, suivi, scrolling).
3. Fixez la durée de session (ex. 3 minutes) et le mode de fin (victoire/défaite/score).
4. Listez 1 mécanique principale (ex. sauter, tirer, pousser) et 1 mécanique secondaire (ex. dash, rechargement, interrupteurs).
5. Définissez 3 contraintes de contenu (ex. 10 niveaux, 4 ennemis, 3 power-ups).
6. Écrivez 5 exclusions (ce que vous refusez d’ajouter). Exemple : « pas de crafting », « pas de multijoueur », « pas de narration dialoguée », « pas de monde ouvert », « pas de progression RPG ».

Astuce : si une idée ne rentre pas dans les limites, elle va dans une section « Backlog / idées futures » (hors périmètre), sans impacter le planning du petit jeu.

Structure type d’un Game Design Document (GDD) pour un jeu 2D simple

Un GDD est un document de référence : il aligne l’équipe (même si vous êtes seul), facilite les décisions, et sert de base aux tests. Pour un petit jeu, il doit rester court, actionnable et facile à maintenir.

1) Page de garde

But : identifier clairement le document et sa version.

• Titre du jeu (provisoire)
• Version du GDD (ex. v0.3) + date
• Auteur(s)
• Statut (brouillon, en revue, validé)
• Liens utiles (dépôt, dossier assets, board de tâches) si pertinent

2) Pitch (1–3 phrases)

But : résumer le jeu de manière compréhensible en quelques secondes. Le pitch doit mentionner le genre, la perspective 2D et l’objectif principal.

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

Exemple :

Un shooter top-down 2D où le joueur survit à des vagues d’ennemis dans une arène unique. Chaque partie dure 5 minutes maximum et se joue au score. Le joueur choisit entre 3 armes et doit gérer son positionnement pour éviter d’être encerclé.

3) Promesse de gameplay

But : exprimer ce qui rend le jeu plaisant, distinct et cohérent. C’est une promesse faite au joueur (ce qu’il va ressentir et faire), pas une liste de features.

• Verbe d’action central : « esquiver », « enchaîner », « réfléchir », « explorer »…
• Fantaisie (fantasy) : « être un pilote agile », « être un stratège », etc.
• Rythme : nerveux, posé, tactique…
• Décisions clés : positionnement, timing, gestion de ressources, lecture de patterns…

Exemple (runner) : « Une expérience courte et intense centrée sur le timing : sauter, glisser, et enchaîner des esquives pour maintenir un multiplicateur de score. »

4) Objectifs du projet

But : clarifier ce que vous cherchez à accomplir avec ce jeu (objectifs de production, de qualité, d’apprentissage), sans entrer dans des considérations commerciales.

• Objectif de scope : « livrer un jeu jouable complet avec 10 niveaux »
• Objectif de qualité : « contrôles précis, lisibilité des collisions, feedback clair »
• Objectif de test : « 3 sessions de playtest, corrections prioritaires »
• Objectif technique : « 60 FPS sur la plateforme cible, temps de chargement minimal »

5) Public visé

But : guider la difficulté, la lisibilité, la durée des sessions et la complexité des contrôles.

• Niveau d’expérience (débutant, habitué, expert)
• Attentes (parties courtes, challenge, détente, score)
• Accessibilité (options de remappage, aide visuelle, vitesse de jeu) si vous choisissez de l’inclure

Exemple : « Joueurs occasionnels aimant des sessions de 3–5 minutes, difficulté progressive, contrôles simples (2–4 actions). »

6) Plateformes cibles (sans considérations commerciales)

But : déterminer les contraintes d’input, d’affichage et de performance.

• Plateforme(s) : PC, navigateur, mobile, console (choisir et préciser)
• Contrôles : clavier/souris, manette, tactile
• Résolution / orientation : 16:9, portrait, paysage
• Contraintes d’interface : taille des boutons (tactile), lisibilité, HUD minimal

Exemple : « PC (clavier) et manette. Résolution 1280×720 minimum, 16:9. »

7) Contraintes techniques

But : éviter les choix de design irréalisables au regard des limites techniques fixées. Cette section doit être concrète et vérifiable.

• Moteur / framework (si déjà choisi) et version
• 2D : système de physique (simple/arcade), collisions (AABB, tilemap), caméra
• Budget de contenu : nombre d’animations par personnage, nombre de sprites, taille audio
• Performance cible : FPS, nombre max d’entités simultanées (ennemis, projectiles)
• Audio : stéréo simple, nombre de pistes simultanées
• Save/Load : oui/non, et forme (highscore local, progression niveaux)

Exemple de contraintes :

- Max 30 ennemis simultanés, max 60 projectiles simultanés. 60 FPS cible. 1 seule scène principale + écran titre + écran fin. Sauvegarde : uniquement meilleur score local.

8) Glossaire

But : éviter les ambiguïtés. Chaque terme important doit avoir une définition courte et stable.

Livrable 1 : Modèle de GDD vierge (sections prêtes à remplir)

Copiez-collez ce modèle dans votre document. Remplissez d’abord les sections « Pitch », « Promesse de gameplay » et « Périmètre » : ce sont les garde-fous du projet.

PAGE DE GARDE
- Titre du jeu :
- Version du GDD :
- Date :
- Auteur(s) :
- Statut :

1) PITCH (1–3 phrases)
- 

2) PROMESSE DE GAMEPLAY
- Verbe d’action central :
- Fantaisie (fantasy) :
- Rythme :
- Décisions clés :
- Ce que le joueur fait le plus souvent :

3) PÉRIMÈTRE (PETIT JEU)
- Genre :
- Perspective 2D :
- Durée d’une session :
- Boucle de jeu (en 3 étapes max) :
- Mécanique principale :
- Mécanique secondaire :
- Plafonds (contenu) :
  - Niveaux / arènes :
  - Ennemis / obstacles :
  - Power-ups / items :
- Exclusions (au moins 5) :
- Backlog (idées futures, hors scope) :

4) OBJECTIFS DU PROJET
- Objectif de scope :
- Objectif de qualité :
- Objectif de test :
- Objectif technique :

5) PUBLIC VISÉ
- Profil :
- Niveau d’expérience :
- Attentes :
- Accessibilité (optionnel) :

6) PLATEFORMES CIBLES
- Plateforme(s) :
- Contrôles :
- Résolution / orientation :

7) CONTRAINTES TECHNIQUES
- Moteur / framework :
- Collisions / physique :
- Caméra :
- Performance cible :
- Budget d’entités :
- Audio :
- Sauvegarde :

8) GLOSSAIRE
- Terme : définition
- Terme : définition

Livrable 2 : Checklist de complétude (jeu 2D simple)

Utilisez cette checklist pour vérifier que votre GDD est suffisamment cadré pour démarrer la production sans zones floues majeures.

Checklist « Périmètre »

• Le genre est défini en une phrase et cohérent avec une production courte.
• La perspective 2D (side/top-down) et le comportement de caméra sont précisés.
• La durée de session est chiffrée (ex. 3–5 min) et la condition de fin est définie.
• La boucle de jeu tient en 3 étapes maximum.
• 1 mécanique principale + 1 secondaire (max) sont clairement décrites.
• Des plafonds de contenu sont écrits (niveaux, ennemis, power-ups, écrans).
• Au moins 5 exclusions sont listées (anti-scope creep).

Checklist « Clarté du GDD »

• Le pitch fait 1–3 phrases et mentionne genre + perspective + objectif.
• La promesse de gameplay décrit une expérience (verbes, rythme, décisions), pas une liste de features.
• Les objectifs du projet sont mesurables (quantités, FPS cible, nombre de playtests).
• Le public visé est défini (niveau, attentes, complexité des contrôles).
• Les plateformes cibles et les inputs sont explicités (clavier/manette/tactile).
• Les contraintes techniques sont vérifiables (budget d’entités, scènes, sauvegarde).
• Le glossaire contient les termes ambigus (session, vague, hitbox, etc.).

Checklist « Prêt à produire » (minimum viable)

• Vous pouvez expliquer le jeu en 20 secondes à partir du pitch.
• Vous pouvez refuser une nouvelle idée en vous appuyant sur les exclusions.
• Vous savez combien de contenu maximum vous allez créer (plafonds).
• Vous savez sur quoi tester en priorité (objectifs de qualité + public visé).