Modèle de document de game design
Neuf documents liés qui couvrent un jeu de son pitch à son journal des décisions, chacun avec ce qu’il faut y écrire et un court exemple. Téléchargez-les en fichiers Markdown : ils s’ouvrent dans n’importe quel éditeur, affichent leurs diagrammes sur GitHub et dans Obsidian, et s’importent dans Nodary sous forme de carte.
9 fichiers Markdown dans un .zip, 15 ko
Gratuit, sans compte, sans e-mail. Utilisez-le, modifiez-le, partagez-le.
Lisez chaque page avant de télécharger
La vue d’ensemble tient sur un écran et renvoie à huit parties, une par métier : chaque partie a un responsable, et un changement reste petit. Les lignes en italique disent quoi écrire ; les exemples viennent de Saltmarrow, le jeu d’exemple que ce site montre partout.
Documents
Fichier Modèle de document de game design/Document de game design.md
Document de game design
Mode d’emploi : les lignes en italique sont des consignes. Remplacez-les par vos propres mots, puis supprimez-les. Les valeurs entre crochets sont à remplir. Gardez cette page sur un écran environ : c’est celle que tout le monde lit en premier, et chaque autre partie du design est à un lien d’ici.
En bref
| Champ | Votre jeu |
|---|---|
| Titre de travail | [Titre] |
| Accroche | [Une phrase qu’un inconnu pourrait répéter] |
| Genre | [Genre et sous-genre] |
| Joueurs | [Solo, coop de 2 à 4, compétitif] |
| Plateformes | [PC, consoles, mobile] |
| Durée d’une session | [Une session type, en minutes] |
| Moteur | [Moteur et version] |
| Équipe | [Taille aujourd’hui et au plus fort] |
| Modèle économique | [Prix, free-to-play, abonnement] |
| Prochain jalon | [Nom et date] |
Pitch
Deux ou trois phrases : qui est le joueur, ce qu’il fait, et ce qui rend le jeu différent. Écrivez-le pour qu’il tienne encore sur une page de boutique.
Exemple (Saltmarrow, un jeu d’exemple) : Ratissez le sel, plongez pour des souvenirs, rentrez avant la marée. Un jeu coopératif d’exploration et d’artisanat jusqu’à quatre joueurs, sur des marais salants où une cité-archive engloutie refait surface deux fois par jour.
[Votre pitch]
Piliers de design
Trois à cinq règles que chaque fonctionnalité doit servir. Un pilier qui pourrait décrire n’importe quel jeu, comme « des combats fun », n’en est pas un. Une fonctionnalité qui ne sert aucun pilier est coupée ; une qui en casse un est repensée.
- [Premier pilier] : [ce qu’il veut dire, en une phrase]
- [Deuxième pilier] : [ce qu’il veut dire, en une phrase]
- [Troisième pilier] : [ce qu’il veut dire, en une phrase]
Exemple (Saltmarrow, un jeu d’exemple) : La marée est l’horloge. Le temps est la seule ressource qui ne grandit jamais : chaque système lit la marée, et rien ne la met en pause.
Public
À qui s’adresse le jeu, à quoi ces joueurs jouent aujourd’hui et quand ils décrochent. Citez de vrais jeux et de vraies habitudes, pas seulement une tranche d’âge.
- Joueurs principaux : [qui ils sont et comment ils jouent]
- Ce à quoi ils jouent aujourd’hui : [trois ou quatre jeux]
- Ils décrochent quand : [...]
- Joueurs secondaires : [...]
Jeux comparables
Trois ou quatre jeux que votre équipe et vos joueurs connaissent déjà. Dites ce que vous prenez à chacun et, tout aussi utile, ce que vous laissez.
| Jeu | Ce qu’on prend | Ce qu’on laisse |
|---|---|---|
| [Jeu] | [...] | [...] |
| [Jeu] | [...] | [...] |
| [Jeu] | [...] | [...] |
Périmètre
Ce que contient la première version, et ce qu’elle ne contient explicitement pas. C’est la deuxième liste qui empêche le périmètre de grossir en silence.
- Dans la première version : [...]
- Pas dans la première version : [...]
- À décider plus tard : [...]
Le reste du design
Chaque partie est un document à part. Renvoyez-y plutôt que de la recopier : chaque fait vit à un seul endroit et change à un seul endroit.
- Gameplay : la boucle principale, les mécaniques, les contrôles et la progression
- Systèmes et économie : chaque système, ses règles et ses chiffres
- Monde, histoire et personnages : le cadre, l’histoire et ceux qui la vivent
- Niveaux et contenu : chaque lieu, la première heure et le budget de contenu
- Direction artistique et sonore : l’image et le son du jeu
- Interface et accessibilité : écrans, HUD, commandes et accessibilité
- Conception technique : moteur, cibles, architecture et chaîne de production
- Plan de production : jalons, équipe, risques et journal des décisions
Ce modèle est libre d’utilisation, de modification et de partage. Il vient de Nodary, où ces fichiers s’importent en une carte de documents liés.
Fichier Modèle de document de game design/Document de game design/01 Gameplay.md
Gameplay
Ce que fait le joueur d’une minute à l’autre, et pourquoi il continue. Commencez par la boucle : tout le reste de ce document en découle.
Boucle principale
La boucle que le joueur répète le plus, en quatre à six verbes. Si l’équipe ne sait pas la dessiner, c’est qu’elle n’est pas encore arrêtée.
- Planifier
- Explorer
- Récolter
- Fabriquer
- Améliorer
Mermaid
flowchart LR n0["Planifier"] n1["Explorer"] n2["Récolter"] n3["Fabriquer"] n4["Améliorer"] n0 --> n1 n1 --> n2 n2 --> n3 n3 --> n4 n4 --> n0
| Temps fort | Durée type | La question du joueur |
|---|---|---|
| [Planifier] | [2 min] | [Quel objectif cette fois, et qu’est-ce que j’emporte ?] |
| [Explorer] | [...] | [...] |
| [Récolter] | [...] | [...] |
Exemple (Saltmarrow, un jeu d’exemple) : Récolter ou plonger, 8 à 14 minutes : ratisser du sel sans risque, ou plonger chercher des cristaux qui vaudront peut-être plus ? Chaque temps fort doit poser une question au joueur. Sans question, c’est une corvée.
Mécaniques
Une ligne par mécanique. La colonne des piliers garde chacune honnête : une mécanique qui ne sert aucun pilier part sur la liste des coupes.
| Mécanique | Ce que fait le joueur | Pilier servi | Statut |
|---|---|---|---|
| [Mécanique] | [...] | [...] | [idée, prototypée, verrouillée] |
| [Mécanique] | [...] | [...] | [...] |
Contrôles
Les verbes du joueur et la sensation que chacun doit donner. L’affectation des touches pour chaque appareil se trouve dans Interface et accessibilité.
- [Verbe] : [comment il s’exécute, et quelle sensation il doit donner]
- [Verbe] : [...]
Progression
Ce qui grandit pendant une session et sur tout le jeu, et comment le joueur le voit grandir. Nommez l’objectif à long terme.
- Pendant une session : [...]
- D’une session à l’autre : [...]
- Objectif à long terme : [...]
Difficulté et échec
Comment la difficulté monte, ce que coûte un échec et comment le joueur s’y remet. Un échec qui ne coûte que du temps apprend moins qu’un échec qui coûte un choix.
- La difficulté monte par : [...]
- Un échec coûte : [...]
- Pour s’y remettre : [...]
Exemple (Saltmarrow, un jeu d’exemple) : Un plongeur encore dans l’archive quand la corne retentit perd les cristaux de sa besace et remonte à la tour la plus proche, en gardant son sel.
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/02 Systèmes et économie.md
Systèmes et économie
Chaque système du jeu, ses règles et les chiffres derrière. Les chiffres changent chaque semaine : gardez-les dans des tableaux ou des tableurs, et le raisonnement ici.
Systèmes
Une ligne par système. Un système qui n’alimente rien est un décor. Un système que tout alimente est la colonne vertébrale du jeu, et mérite son propre document.
| Système | Ce qu’il fait | Lit | Alimente | Responsable |
|---|---|---|---|---|
| [Artisanat] | [...] | [Inventaire] | [Améliorations] | [nom] |
| [Système] | [...] | [...] | [...] | [...] |
Exemple (Saltmarrow, un jeu d’exemple) : Chaque système lit la marée : les rendements de récolte, les risques de tempête, les prix du village, jusqu’à la patience d’un personnage pour parler.
Ressources et monnaies
Pour chaque ressource, d’où elle vient (les sources) et où elle part (les puits). Une économie qui a plus de sources que de puits s’emballe : remplissez les deux colonnes avant d’équilibrer quoi que ce soit.
| Ressource | Sources | Puits | Plafond |
|---|---|---|---|
| [Or] | [...] | [...] | [aucun, ou un nombre] |
| [Ressource] | [...] | [...] | [...] |
Récompenses et taux de drop
Tables de butin, chances de récompense et éventuelle règle de pitié. Dites à quoi un joueur doit s’attendre : combien d’essais avant que la moitié des joueurs aient un objet, et avant que neuf sur dix l’aient. Le calculateur de taux de drop gratuit le calcule à partir d’une table de poids.
| Récompense | Poids | Chance par essai | Garantie au |
|---|---|---|---|
| [Objet] | [...] | [...] | [aucune, ou essai n] |
| [Objet] | [...] | [...] | [...] |
Leviers d’équilibrage
Les quelques valeurs qu’un designer change pour rendre le jeu plus facile, plus rapide ou plus généreux, avec la valeur actuelle et la plage déjà testée. Quand l’une change, notez pourquoi dans le journal des décisions du plan de production.
| Levier | Valeur actuelle | Plage testée | Agit sur |
|---|---|---|---|
| [...] | [...] | [...] | [...] |
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/03 Monde, histoire et personnages.md
Monde, histoire et personnages
Les règles du monde, l’histoire que vit le joueur, et ceux qui la peuplent. Le lore qui n’atteint jamais le joueur a sa place dans des documents à part, liés d’ici.
Cadre
Où et quand, en trois phrases, et la règle de ce monde que le joueur ressent en jouant.
Exemple (Saltmarrow, un jeu d’exemple) : Une cité-bibliothèque qui a voulu survivre à la mer en faisant pousser du sel. Cela a marché : le sel a gardé les livres et noyé les lecteurs. Deux fois par jour, la marée la découvre.
[Votre cadre]
Ton
Trois mots, chacun avec un jeu, un film ou un livre qui place la barre. Puis ce que le ton n’est pas : cela tranche plus de débats que ce qu’il est.
- Ton : [...]
- Références : [...]
- Jamais : [...]
Trame
L’histoire telle que le joueur la vit, temps fort par temps fort, et non l’histoire d’avant. Notez comment chaque temps fort lui parvient : une cinématique, une réplique, un objet trouvé, le niveau lui-même.
| Temps fort | Ce qui se passe | Comment le joueur l’apprend |
|---|---|---|
| [Ouverture] | [...] | [...] |
| [Bascule] | [...] | [...] |
| [Fin] | [...] | [...] |
Personnages
| Personnage | Rôle en jeu | Ce qu’il veut | Sa voix en une ligne |
|---|---|---|---|
| [Nom] | [guide, marchand, rival] | [...] | [...] |
| [Nom] | [...] | [...] | [...] |
Dès qu’un personnage a plus de quelques répliques, donnez-lui son propre document (un profil, des références, des exemples de dialogue) et liez-le depuis ce tableau.
Règles d’écriture
Les conventions que suit chaque auteur : noms et graphies, mots que ce monde n’emploie jamais, la plus longue réplique qui tient à l’écran. Écrites tôt, elles font gagner des semaines à l’équipe de localisation.
- [Règle]
- [Règle]
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/04 Niveaux et contenu.md
Niveaux et contenu
Chaque lieu où va le joueur et chaque élément de contenu dont le jeu a besoin, avec leur quantité. Cette liste devient le backlog de production : gardez des chiffres honnêtes.
Lieux et niveaux
| Lieu ou niveau | Rôle dans le jeu | Mécaniques principales | Durée | Statut |
|---|---|---|---|---|
| [Zone de tutoriel] | [apprendre les déplacements et la boucle principale] | [...] | [10 min] | [blockout, passe artistique, final] |
| [Lieu] | [...] | [...] | [...] | [...] |
Règles de level design
Les règles valables dans chaque niveau : comment le joueur est guidé, l’écart entre deux points de sauvegarde, comment les secrets sont signalés. Écrivez-les une fois ici plutôt que dans chaque niveau.
- [Règle]
- [Règle]
La première heure
La première heure du joueur, étape par étape : ce qu’il fait, ce qu’il apprend, et le premier moment qu’il raconterait à un ami. La plupart des joueurs qui abandonnent le font ici.
| Minutes | Ce que fait le joueur | Ce qu’il apprend |
|---|---|---|
| 0 à 5 | [...] | [...] |
| 5 à 15 | [...] | [...] |
| 15 à 60 | [...] | [...] |
Budget de contenu
Combien de chaque type de contenu demande la première version, et qui le fabrique. Confrontez-le au plan de production avant que quiconque commence à construire.
| Contenu | Nombre | Fait par | Notes |
|---|---|---|---|
| [Niveaux ou zones] | [...] | [...] | [...] |
| [Personnages et créatures] | [...] | [...] | [...] |
| [Objets] | [...] | [...] | [...] |
| [Répliques de dialogue] | [...] | [...] | [...] |
| [Morceaux de musique] | [...] | [...] | [...] |
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/05 Direction artistique et sonore.md
Direction artistique et sonore
L’image et le son du jeu, décrits assez précisément pour que deux artistes travaillant chacun de leur côté produisent des éléments qui vont ensemble.
Règles visuelles
Trois à cinq règles sur la forme, la couleur, la lumière et le détail. « Stylisé » n’est pas une règle ; « chaque silhouette se lit à trente mètres » en est une.
- [Règle]
- [Règle]
- [Règle]
Références
Ajoutez des images de référence sous chaque règle, et dites ce qu’il faut prendre à chacune : la palette, la lumière, les formes. Jamais « tout ».
| Référence | Ce qu’on prend | Ce qu’on évite |
|---|---|---|
| [Image ou jeu] | [...] | [...] |
| [Image ou jeu] | [...] | [...] |
Palette
| Usage | Couleur | Notes |
|---|---|---|
| [Fond] | [#hex] | [...] |
| [Danger] | [#hex] | [jamais le seul signe du danger] |
Familles d’assets
Ce que chaque famille d’assets a en commun, son budget (polygones, taille de texture, images) et qui la valide.
| Famille | Notes de style | Budget | Validé par |
|---|---|---|---|
| [Personnages] | [...] | [...] | [...] |
| [Environnements] | [...] | [...] | [...] |
| [Accessoires] | [...] | [...] | [...] |
| [Effets] | [...] | [...] | [...] |
Son
L’ambiance de la musique, les bruitages et les voix, et les informations de jeu que porte le son : alertes, récompenses, temps qui passe.
- Musique : [...]
- Bruitages : [...]
- Voix : [langues et nombre de répliques, ou aucune]
- Informations portées par le son : [...]
Exemple (Saltmarrow, un jeu d’exemple) : Deux minutes avant que la marée ne tourne, une corne retentit sur les plaines. La marée se voit à l’écran, s’entend dans le mixage et se sent dans la manette.
Validations
Qui valide l’image et le son, et quand. Gardez les retours sur l’image elle-même, épinglés à l’endroit dont ils parlent : cela évite un tour de « laquelle, à gauche ? »
- L’image est validée par : [...]
- Le son est validé par : [...]
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/06 Interface et accessibilité.md
Interface et accessibilité
Tout ce que le joueur lit, appuie et parcourt, et comment le jeu s’adapte aux joueurs qui voient, entendent ou bougent autrement.
Écrans et parcours
Chaque écran, et comment le joueur passe de l’un à l’autre, du lancement à la sortie. Un diagramme trouve les impasses avant qu’elles soient construites.
- Écran titreMenu principal
- Menu principalJouerOptions
- JouerPause
- PauseJouerMenu principal
Mermaid
flowchart LR n0["Écran titre"] n1["Menu principal"] n2["Jouer"] n3["Options"] n4["Pause"] n0 --> n1 n1 --> n2 n1 --> n3 n2 --> n4 n4 --> n2 n4 --> n1
HUD
Ce qui reste à l’écran pendant le jeu, et pourquoi chaque élément mérite sa place. Ce que le joueur consulte moins d’une fois par minute peut vivre dans un menu.
| Élément | Affiche | Quand il est visible | Priorité |
|---|---|---|---|
| [Santé] | [...] | [toujours, en combat, à la demande] | [haute, moyenne, basse] |
| [Élément] | [...] | [...] | [...] |
Commandes
| Action | Clavier et souris | Manette | Tactile |
|---|---|---|---|
| [Se déplacer] | [ZQSD] | [Stick gauche] | [...] |
| [Interagir] | [E] | [A / Croix] | [...] |
| [Pause] | [Échap] | [Start / Options] | [...] |
Accessibilité
Cochez chaque point, ou écrivez pourquoi il ne s’applique pas. Décidés tôt, la plupart coûtent peu ; ajoutés tard, ils coûtent cher.
- Chaque commande peut être réaffectée
- Les actions à maintenir peuvent devenir des bascules
- Les sous-titres indiquent qui parle, et leur taille se règle
- Les sons importants ont aussi un signal visuel
- Aucune information ne passe par la seule couleur
- Le texte peut être agrandi
- Les minuteurs peuvent être ralentis ou désactivés
- Les secousses de caméra et les flashs peuvent être réduits
Textes et langues
Les langues à la sortie, et les règles qui gardent la traduction possible : aucun texte incrusté dans les images, de la place pour un texte jusqu’à un tiers plus long que l’anglais, des polices qui couvrent chaque écriture livrée.
- Langues à la sortie : [...]
- Langues ensuite : [...]
- Polices : [...]
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/07 Conception technique.md
Conception technique
Les choix techniques qui façonnent le design, et les limites que le design doit respecter. L’architecture détaillée peut vivre dans des documents d’ingénierie liés d’ici.
Moteur et outils
| Choix | Décision | Pourquoi |
|---|---|---|
| Moteur | [Moteur et version] | [...] |
| Langages | [...] | [...] |
| Gestion de versions | [...] | [...] |
| Builds et distribution | [...] | [...] |
Cibles et budgets
Les chiffres sur lesquels chaque métier construit. Sans eux, les problèmes de performance se découvrent à la fin.
| Plateforme | Images par seconde | Résolution | Mémoire | Temps de chargement | Taille d’installation |
|---|---|---|---|---|---|
| [PC, configuration minimale] | [...] | [...] | [...] | [...] | [...] |
| [Console] | [...] | [...] | [...] | [...] | [...] |
Architecture
Les grandes parties du code du jeu et comment elles se parlent. Un diagramme de cinq boîtes vaut mieux que cinq pages de prose.
- EntréesÉtat du jeu
- État du jeuRenduAudioSauvegardes
Mermaid
flowchart TD n0["Entrées"] n1["État du jeu"] n2["Rendu"] n3["Audio"] n4["Sauvegardes"] n0 --> n1 n1 --> n2 n1 --> n3 n1 --> n4
Sauvegardes et en ligne
- Sauvegardes : [ce qui est sauvegardé, quand, et où]
- En ligne : [rien, pair à pair, serveurs dédiés]
- Données des joueurs : [ce qui est collecté, et où c’est conservé]
Chaîne de production
Comment un asset ou une ligne de texte va de son auteur à une version jouable, et combien de temps cela prend. Une chaîne lente réduit en silence le nombre d’itérations d’une équipe.
[Votre chaîne de production]
Risques techniques
| Risque | Impact | Ce qu’on fait | Responsable |
|---|---|---|---|
| [...] | [...] | [...] | [...] |
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Fichier Modèle de document de game design/Document de game design/08 Plan de production.md
Plan de production
Quand le jeu sort, qui le fait, ce qui pourrait l’arrêter, et chaque décision prise en chemin.
Jalons
| Jalon | Date | Objectif | Atteint quand |
|---|---|---|---|
| [Prototype] | [...] | [la boucle principale est amusante] | [...] |
| [Vertical slice] | [...] | [un niveau en qualité finale] | [...] |
| [Alpha] | [...] | [toutes les fonctionnalités, même brutes] | [...] |
| [Bêta] | [...] | [tout le contenu, corrections seulement] | [...] |
| [Sortie] | [...] | [...] | [...] |
« Atteint quand » est la colonne qu’on oublie. Sans elle, un jalon n’est qu’une date.
Équipe
| Rôle | Personne | Responsable de ces documents |
|---|---|---|
| [Direction créative] | [nom] | [Document de game design, Gameplay] |
| [Rôle] | [nom] | [...] |
Risques
| Risque | Probabilité | Impact | Ce qu’on fait | Responsable |
|---|---|---|---|---|
| [...] | [faible, moyenne, forte] | [faible, moyen, fort] | [...] | [...] |
Journal des décisions
Chaque décision qui change le design : ce qui a été décidé, par qui, pourquoi, et quel document a changé. Six mois plus tard, quand quelqu’un demande pourquoi c’est ainsi, ce tableau répond.
| Date | Décision | Décidé par | Pourquoi | Document modifié |
|---|---|---|---|---|
| [date] | [...] | [...] | [...] | [...] |
Exemple (Saltmarrow, un jeu d’exemple) : 12 septembre : pas de combat, la menace vient de la marée et des tempêtes seulement. Décidé par la direction créative et le design des systèmes, pour garder le jeu calme et son échéance tranchante. Document modifié : les piliers de design.
Questions ouvertes
- [Question], [qui y répond], [pour quand]
Comment s’en servir
Écrivez la vue d’ensemble d’une traite
Remplissez d’abord le tableau, le pitch et les piliers, en une heure environ, avec ceux qui vont faire le jeu. Toutes les autres pages se jugent à cette aune.
Remplissez les parties au fil des décisions
Laissez une section vide plutôt que de l’inventer. Une section vide est une question ouverte assumée ; une section inventée finit par être construite.
Consignez chaque décision
Quand une décision change le design, ajoutez une ligne au journal des décisions du plan de production et mettez à jour la page concernée. Le journal dit pourquoi ; la page dit ce qui est vrai aujourd’hui.
Donnez un responsable à chaque page
Chaque partie nomme son responsable et la date de sa dernière relecture. Une page sans responsable est la première à se périmer.
Importez-le dans Nodary en carte
Nodary est un espace de travail pour les équipes de jeu, où les documents sont reliés comme des étoiles sur une carte. Importez le .zip : la vue d’ensemble arrive avec ses huit parties rangées sous elle, les liens entre les pages conservés et les diagrammes dessinés. Votre équipe commente ensuite des passages, demande des relectures et voit ce qui a changé depuis sa dernière visite, et les agents IA connectés par MCP lisent le design avant d’y écrire.
- Ouvrez la carte d’un projet et choisissez Importer.
- Choisissez l’onglet Dossier ou ZIP, puis Choisir un ZIP.
- Sélectionnez le fichier téléchargé, vérifiez l’arborescence et importez.
L’offre gratuite compte dix documents par espace de travail, page du projet comprise : les neuf du modèle tiennent dans un nouvel espace et le remplissent. Les offres payantes ont de la place pour davantage.
Comment Nodary gère les documents de game design
Écrire un GDD que l’équipe lit vraiment
Un document de game design échoue de deux façons : personne ne le lit, ou tout le monde en lit une version périmée. Ces habitudes évitent les deux.
Une page par partie
Un fichier de soixante pages se lit une fois, au début. De courtes pages liées se lisent quand elles comptent, et un changement touche une page au lieu de cinq.
Écrivez des décisions, pas des souhaits
« Le combat doit être agréable » ne décide rien. « Un coup porte moins de 100 millisecondes après l’appui sur le bouton » se construit et se teste.
Dites ce qui reste ouvert
Marquez les questions sans réponse comme ouvertes, avec qui y répond et pour quand. Une supposition écrite comme un fait, c’est ainsi que deux métiers finissent par construire deux jeux différents.
Liez, ne recopiez jamais
Quand la page de l’économie a besoin des horaires de marée, elle y renvoie. Un fait écrit à deux endroits finit vite par dire deux choses différentes.
Gardez le pourquoi
Le journal des décisions garde la raison des choses, pour qu’un nouveau venu ne défasse pas un choix que l’équipe a déjà payé.
Coupez ce que personne ne lit
Si une section n’a pas été ouverte depuis qu’elle a été écrite, fusionnez-la ou supprimez-la. Un document court et juste vaut mieux qu’un long qui l’a été.
Questions sur le document de game design
Qu’est-ce qu’un document de game design ?
Un document de game design, ou GDD, décrit le jeu qu’une équipe fabrique : son pitch, ses piliers, ses mécaniques, ses systèmes, son monde, ses niveaux, son image et son son, et le plan pour le faire. Game designers, artistes, programmeurs, producteurs et, de plus en plus, agents IA le lisent : il doit rester à jour pendant que le jeu change.
Que doit contenir un document de game design ?
Au minimum une vue d’ensemble d’une page avec le pitch, les piliers, le public et le périmètre ; le gameplay et la boucle principale ; les systèmes et leurs chiffres ; le monde et l’histoire ; les niveaux et le contenu ; la direction artistique et sonore ; l’interface et l’accessibilité ; les contraintes techniques ; et un plan de production avec un journal des décisions. Ce modèle a un document pour chacun.
Quelle longueur doit faire un GDD ?
Aussi court que possible tant qu’il répond aux questions de l’équipe. La vue d’ensemble doit tenir sur un écran. Chaque partie grandit avec les décisions prises, pas avec les envies : une page de règles arrêtées vaut mieux que dix pages de possibilités.
Les équipes indépendantes et agiles ont-elles encore besoin d’un GDD ?
Elles ont besoin que les décisions soient écrites, pas d’une bible rédigée d’avance. Les équipes qui itèrent vite se servent du GDD comme de la trace de ce qu’est le jeu aujourd’hui : des pages courtes, mises à jour quand un playtest change quelque chose, avec les raisons gardées dans le journal des décisions.
Dans quel format est le modèle ?
En Markdown : des fichiers texte que tout éditeur ouvre. Les liens entre documents sont des liens relatifs, les tableaux des tableaux Markdown, et les diagrammes du Mermaid, que GitHub, Obsidian et Nodary dessinent. Rien ne dépend d’un outil en particulier.
Puis-je l’utiliser dans Obsidian, sur GitHub ou dans un autre éditeur ?
Oui. Obsidian ouvre le dossier décompressé comme un coffre, avec tous ses liens, et GitHub affiche les fichiers avec leurs liens et leurs diagrammes. Les outils qui importent le Markdown fichier par fichier gardent le texte et les tableaux ; vérifiez comment ils traitent les liens entre fichiers.
Comment importer le modèle dans Nodary ?
Ouvrez la carte d’un projet, choisissez Importer, puis l’onglet Dossier ou ZIP, et choisissez le .zip téléchargé. Nodary montre d’abord l’arborescence, puis crée les neuf documents avec la vue d’ensemble pour parent, garde les liens entre eux et dessine les diagrammes. N’importe quel dossier ou .zip de 200 fichiers Markdown au plus s’importe de la même façon.
Puis-je utiliser le modèle pour un jeu commercial ?
Oui. Utilisez-le, modifiez-le et partagez-le pour n’importe quel jeu, commercial ou non, avec ou sans compte Nodary. Une mention fait plaisir, elle n’est jamais obligatoire.
Gardez le design là où l’équipe travaille.
Importez le modèle dans Nodary et le GDD devient une carte que votre équipe et vos agents IA tiennent à jour. Gratuit avec deux membres, un projet et dix documents, sans carte bancaire.