Modèle de document de game design : une page d'abord

Un modèle de document de game design doit d'abord tenir sur une seule page, et ne grandir que lorsque le jeu le justifie. Commence par cinq blocs : le pitch, les piliers de design, la boucle centrale, la liste des systèmes et les questions ouvertes. Le reste, des notes de lore aux notes de niveau, s'ajoute quand un playtest prouve que la mécanique tient la route. Voici le modèle que nous utilisons pour les projets de jeu de rôle sur table et les jeux vidéo indépendants, avec l'endroit où chaque section a tendance à pourrir.

Pourquoi la plupart des documents de game design meurent avant la troisième semaine ?

Le problème habituel, c'est l'ambition. Quelqu'un ouvre un fichier vide, colle un plan de 20 sections trouvé sur un forum, et passe un week-end à remplir des cases pour des mécaniques que personne n'a testées. À la troisième semaine, le jeu a bougé et le document non. Plus personne ne l'ouvre, et personne ne l'admet.

Le guide de Game Dev Beginner sur les GDD dit le problème sans détour : les documents très longs et trop détaillés demandent un travail lourd en amont, sont presque toujours périmés, et deviennent contraignants alors que le design bouge encore. Leur remède est la progression par étapes. Écris d'abord une page, puis une dizaine de pages quand le jeu prend forme, et la version complète seulement quand le contenu passe en production.

Cela compte davantage pour les concepteurs de jeux de rôle que pour les équipes de jeux vidéo. Un concepteur de JDR est souvent à la fois l'auteur, le responsable des systèmes et le playtester. Personne n'attend un ingénieur avec une spécification. Le document a un seul travail : t'empêcher de te contredire entre la séance quatre et la séance quarante.

Évite le modèle de 40 pages si tu travailles seul. Tu ne le maintiendras pas. La définition standard d'un game design document, sur Wikipédia, parle d'un document vivant, ce qui veut dire que personne n'attend qu'il soit fini le premier jour.

Que mettre dans un modèle de document de game design que les gens ouvrent vraiment ?

Cinq blocs couvrent le premier mois de presque tous les projets. Garde chacun assez court pour lire la page entière en deux minutes.

1. Pitch. Deux phrases. Qui joue, ce qu'il fait, et ce qui le distingue du jeu le plus proche qu'il possède déjà.

2. Piliers de design. Trois ou quatre affirmations sur lesquelles chaque décision ultérieure sera testée. « Chaque combat coûte quelque chose de définitif » est un pilier. « Amusant et engageant » n'en est pas un.

3. Boucle centrale. Ce que le joueur répète. Dans un donjon, cela peut être explorer, choisir, risquer, dépenser. Dans une campagne politique, intrigue, levier, conséquence, retombées.

4. Liste des systèmes. Des noms seulement, avec une ligne par système. Ne précise pas encore les chiffres.

5. Questions ouvertes. La section la plus utile de la page, et celle que les modèles oublient. Note ce que tu ne sais pas, et date-le.

Ajoute un journal des modifications en bas, même d'une seule ligne par semaine. Quand un playtest tue une idée, note la décision et la raison. Sinon, ton futur toi retentera la même idée.

Comment écrire des piliers de design capables de perdre un argument ?

Un pilier mérite sa place en opposant son veto à quelque chose. Si tu ne peux pas nommer une fonctionnalité que le pilier rejetterait, c'est de la décoration.

Teste chaque pilier avec une liste de coupes. Prends les trois fonctionnalités auxquelles tu tiens le plus et demande-toi à quel pilier chacune sert. Une fonctionnalité qui n'en sert aucun part sur l'étagère « plus tard », et cette étagère a le droit d'être longue. C'est l'heure la plus difficile de tout le processus, et elle vaut plus que n'importe quelle section de modèle.

Voici un exemple concret, tiré d'un univers de campagne centré sur une épidémie. Pilier un : la rareté est visible, donc chaque ressource de soin est suivie sur la table. Pilier deux : les factions veulent des remèdes différents, donc aucun traitement unique ne résout tout. Pilier trois : la carte se rétrécit, donc les voyages coûtent plus cher à mesure que l'histoire avance. Une proposition arrive : un sort de résurrection. Le pilier un le rejette. La décision prend dix secondes au lieu d'un débat de quarante minutes.

Bon à savoir : un pilier n'est pas un slogan marketing. Il est interne, brutal, et il peut sembler un peu désobligeant. C'est très bien comme ça.

Où placer le lore dans un GDD, et quand gêne-t-il ?

Le lore est la partie qui grossit le plus vite et qui est la moins lue. La plupart des documents l'enterrent sous un titre « Histoire » en bas de fichier, ou le laissent occuper tout le fichier. Aucune de ces solutions ne fonctionne.

Sépare la matière selon ce qu'elle fait. Le lore qui modifie le jeu, comme la rancune d'une faction qui débloque une quête ou une malédiction qui façonne une classe, vit à l'intérieur des systèmes qu'il affecte. Le lore qui ne fait que poser une ambiance vit sur une page séparée du Codex, que personne n'a besoin d'ouvrir pour prendre une décision de design. Le test est simple : si supprimer ce paragraphe ne change ni une mécanique, ni un jet de dés, ni un choix du joueur, il appartient au Codex.

Cette séparation protège aussi le canon. Quand un fait vit à deux endroits, les deux versions finissent par diverger. Choisis un seul foyer pour chaque fait et crée un lien vers lui depuis tous les autres endroits. Le canon est une promesse, et chaque incohérence la brise.

Les concepteurs de jeux à forte dimension narrative ajoutent souvent une courte page de chronologie et un tableau « qui sait quoi ». Les deux coûtent peu. Les deux épargnent des sessions entières de reprise quand une révélation tardive doit tomber juste.

Quel outil doit héberger ton modèle : Notion, Obsidian ou un simple document ?

L'outil compte moins que le fait que le document reste à l'endroit où tu travailles déjà. Un document dans un onglet que tu n'ouvres jamais est un document mort.

Notion est le choix par défaut des petites équipes : les pages se lient entre elles, les bases de données tiennent les objets et les factions, et les collaborateurs n'ont aucune installation à faire. Des modèles de GDD existent déjà dans Notion, avec des sections pour les contrôles, la boucle de jeu, le design des niveaux et les règles. Le piège, c'est la dépendance à l'outil et la tentation de créer des bases de données pour des choses qui n'en ont pas besoin.

Obsidian convient au concepteur solo qui veut des fichiers Markdown simples sur son disque. Les rétroliens font ici un vrai travail : relie une faction à chaque scène où elle apparaît, et tu obtiens un contrôle de cohérence gratuitement. Il survit à la disparition de son éditeur, ce qui compte si le projet dure des années.

GitBook convient quand le document doit être public ou semi-public, pour un groupe de playtest ou une page de backers de financement participatif. Un Google Doc classique suffit pour une game jam. Évite les modèles de permissions lourds, sauf si un éditeur le demande.

Quel que soit ton choix, applique une règle : le document est mis à jour à la fin de chaque playtest, avant que quiconque rentre chez soi. Dix minutes, sans exception.

Que faut-il ajouter une fois que le prototype a survécu aux playtests ?

Après trois ou quatre séances avec de vrais joueurs, la page d'une seule face gagne sa couche suivante. Ajoute les sections dans cet ordre, et seulement quand la douleur se fait sentir.

• Détail des systèmes. Chiffres, tableaux, cas limites. Écris-les au moment où tu verrouilles un système, pas avant. Pour un JDR, c'est là que vont l'économie d'actions, les portées de dégâts et les coûts en ressources, avec le texte des règles tel qu'il est écrit. Pour un jeu vidéo, ajoute les données que les ingénieurs liront.

• Listes de contenu. Objets, ennemis, factions, lieux. Une ligne par entrée, avec pour chacune le pilier qu'elle sert. Les entrées qui ne servent aucun pilier sont des candidates à la coupe.

• Interface et parcours. Mise en page de la fiche de personnage pour le jeu sur table, enchaînement des écrans pour le numérique. Esquisse à la main avant de décrire en texte.

• Notes de production. Jalons, périmètre, risques, ce qui est dans la première version et ce qui ne l'est pas. Si tu comptes vendre le résultat sur DriveThruRPG ou Itch.io, c'est aussi là que commencent le texte de ta page et tes hypothèses de prix.

Une section pitch ou marketing est un document distinct pour un lecteur distinct. Éditeurs et backers veulent du contexte de marché et des arguments de vente. Tes playtesters veulent des règles. Les mélanger produit un fichier qui ne sert ni l'un ni l'autre.

L'IA peut-elle t'aider à écrire un document de game design, et où échoue-t-elle ?

Elle aide sur les brouillons des parties ingrates et échoue sur celles qui comptent. Demande à un modèle de développer ta liste de systèmes en cas limites détaillés, et tu obtiendras un premier jet correct en une minute. Demande-lui de choisir tes piliers, et tu obtiendras des piliers qui sonnent comme ceux de n'importe quel autre jeu. Il génère vite. Les décisions demandent toujours une relecture humaine.

L'usage pratique, c'est le contrôle de cohérence. Donne-lui le Codex et la liste des systèmes, puis demande où deux pages se contredisent. Des outils conçus autour d'une bible narrative longue, comme Novelcrafter, sont faits pour ce type de recoupement. Traite le résultat comme une liste de suspects, pas comme un verdict, et vérifie chaque signalement sur tes propres pages.

Une règle ferme : le modèle n'écrit jamais la section des questions ouvertes. Cette page est ta liste honnête de ce que tu ne sais pas, et la déléguer annule son intérêt.

Que faut-il sauter, et que faut-il garder ?

Saute le modèle complet tant qu'une mécanique n'a pas survécu à au moins trois vraies séances. Saute la section « public cible » si tu ne peux pas nommer cinq personnes réelles qui y joueraient. Saute les sections de monétisation détaillées pour un jeu qui n'a pas encore trouvé sa boucle. Saute toute section que tu ne peux pas imaginer lire à voix haute devant un collaborateur.

Garde les piliers, les questions ouvertes et le journal des modifications. Ces trois éléments font presque tout le travail. Un document qui ne contient que ceux-là, mis à jour chaque semaine, vaut mieux qu'un fichier de 30 pages soigné que personne n'a ouvert depuis mars.

Le modèle est une promesse faite à ton futur toi sur ce que tu as décidé et pourquoi. Garde-le assez court pour pouvoir la tenir.