Comment rédiger un document de game design que les gens lisent vraiment

Un document de game design, ou GDD, est la référence centrale de ce que votre jeu est censé être. Il décrit les mécaniques principales, l'expérience joueur, la direction artistique, l'approche technique et le périmètre. C'est l'endroit unique où n'importe qui sur le projet peut aller pour comprendre ce qui est construit et pourquoi. Ce qu'il n'est pas, c'est un roman. L'erreur classique est d'écrire un document de 60 pages qui couvre chaque détail possible, se lit comme une thèse, et est abandonné à la troisième semaine parce que personne n'a le temps de le maintenir. Un GDD devrait ressembler davantage à un wiki qu'à un livre. Structuré, consultable et mis à jour régulièrement. Ce n'est pas non plus un document de pitch. Un pitch deck vend l'idée. Un GDD guide l'exécution. Ils servent des objectifs différents et devraient être des documents différents. Votre GDD n'a pas besoin de convaincre qui que ce soit que le jeu mérite d'être fait. Il doit dire aux personnes qui le font comment le faire.

L'argument le plus courant contre la rédaction d'un GDD est « nous sommes une petite équipe et nous savons tous ce qu'est le jeu ». C'est vrai jusqu'au jour où ça ne l'est plus. La mémoire n'est pas fiable, les hypothèses divergent, et les décisions prises lors d'une conversation dans le couloir sont oubliées deux semaines plus tard. Un GDD crée une source de vérité partagée. Quand l'artiste demande « quel style artistique visons-nous ? », la réponse est dans le document. Quand le programmeur demande « comment fonctionne le système d'inventaire ? », la réponse est dans le document. Quand vous-même oubliez si vous aviez décidé d'un système de vies ou d'un système de checkpoints, la réponse est dans le document. Cela vous oblige aussi à réfléchir à votre design avant de le construire. Mettre par écrit le fonctionnement d'une mécanique révèle souvent des lacunes dans votre réflexion que vous n'auriez pas repérées autrement. « Le joueur collecte des gemmes pour déverrouiller des portes » semble simple jusqu'à ce que vous écriviez les détails et réalisiez que vous n'avez pas décidé ce qui se passe quand le joueur n'a plus de gemmes, si les gemmes réapparaissent, combien en faut-il par porte, ou ce qui se passe si un joueur casse la séquence prévue. Pour les développeurs solo, le GDD est votre conversation avec votre futur vous. La version de vous qui travaillera sur ce projet dans quatre mois ne se souviendra pas pourquoi vous avez pris certaines décisions de design. Le document préserve ce raisonnement.

Commencez par un aperçu d'une page. Titre du jeu, genre, plateforme cible, public cible, et une description en deux à trois phrases de l'expérience principale. C'est le pitch d'ascenseur qui oriente quiconque lit le document pour la première fois. Ensuite, décrivez la boucle de gameplay principale. Que fait le joueur à chaque instant ? Quelle est l'action principale, le feedback principal et le cycle de récompense principal ? C'est le battement de cœur de votre jeu et tout le reste devrait le soutenir. Incluez une section sur les mécaniques. Chaque mécanique majeure a sa propre sous-section : comment elle fonctionne, comment le joueur interagit avec elle, comment elle se connecte aux autres mécaniques, et les cas limites que vous avez identifiés. Soyez précis. « Le combat est rapide et fluide » ne dit rien à votre équipe. « Le joueur a un combo de 3 coups avec des fenêtres de 0,4 seconde entre les inputs, une roulade d'esquive avec 12 frames d'invincibilité, et une parade qui nécessite un timing dans les 6 frames d'une attaque entrante » leur dit exactement quoi construire. La direction artistique mérite sa propre section, idéalement avec des images de référence ou des liens vers votre moodboard. Les exigences techniques, la structure des niveaux ou du contenu, les notes d'UI et d'UX, la direction audio, et un plan approximatif de périmètre et de jalons complètent les sections principales. Tous les jeux n'ont pas besoin de toutes les sections. Un jeu axé sur la narration a besoin d'une section histoire. Un jeu multijoueur a besoin d'une section réseau et matchmaking. Adaptez la structure à votre projet.

Écrire trop et trop tôt est le tueur numéro un. Vous n'avez pas besoin que chaque système soit entièrement conçu avant de commencer à construire. Écrivez d'abord l'aperçu et les mécaniques principales. Remplissez les détails de chaque système à mesure que vous approchez de sa construction. Un GDD qui essaie d'être complet dès le premier jour sera obsolète au trentième. La deuxième erreur est de le traiter comme un document à écrire une seule fois. Un GDD est un document vivant. Quand vous testez et découvrez que votre système de combat a besoin d'une mécanique d'esquive que vous n'aviez pas prévue, mettez à jour le GDD. Quand vous coupez une fonctionnalité pour des raisons de périmètre, retirez-la du GDD. Un document qui ne correspond plus au jeu en cours de développement est activement nuisible car les gens prendront des décisions basées sur des informations obsolètes. La troisième erreur est d'enterrer les informations importantes. Personne ne va lire 15 pages pour trouver comment fonctionne le système de sauvegarde. Utilisez des titres clairs, gardez les sections ciblées, et rendez le document facile à parcourir. Un développeur devrait pouvoir trouver l'information dont il a besoin en moins de 30 secondes. Enfin, ne le rédigez pas dans un outil qui rend la mise à jour difficile. Si mettre à jour le GDD nécessite d'ouvrir une application séparée, de naviguer dans des dossiers et de gérer des conflits de versions, les gens arrêteront simplement de le mettre à jour. Le document doit vivre là où le travail se fait.

Le GDD devrait être revu et mis à jour à chaque jalon. Quand vous atteignez votre jalon de prototype, comparez le GDD à ce que vous avez réellement construit. Qu'est-ce qui a changé ? Qu'avez-vous appris des tests ? Mettez à jour le document pour refléter la réalité, pas le plan initial. Désignez un responsable. Si personne n'est chargé de maintenir le GDD à jour, personne ne le fera. Dans une petite équipe, c'est généralement le designer ou le chef de projet. En solo, intégrez-le dans votre checklist de jalons. « Revoir et mettre à jour le GDD » devrait être une tâche, pas une réflexion après coup. Liez votre GDD à votre tableau de tâches. Quand vous créez des tâches pour implémenter une mécanique, référencez la section GDD correspondante. Quand quelqu'un marque une tâche comme terminée, il devrait pouvoir consulter le GDD pour vérifier si l'implémentation correspond au design. Cette connexion bidirectionnelle entre documentation et exécution est ce qui maintient le document pertinent. Versionnez vos changements majeurs. Vous n'avez pas besoin d'un contrôle de version complet, mais noter « Section combat mise à jour après le playtest Alpha, 15 mars » en haut des sections modifiées permet aux gens de savoir quand l'information a été vérifiée pour la dernière fois. Les sections obsolètes devraient être visuellement évidentes.

La fonctionnalité de documents de design dans IndieDevBoard est conçue exactement pour ce type de documentation structurée et vivante. Vous créez un document avec des sections nommées, chacune dédiée à un aspect spécifique de votre jeu. Les sections peuvent être réorganisées, développées et mises à jour indépendamment, de sorte que maintenir le document ne signifie pas tout réécrire. Comme le document de design vit à l'intérieur de votre projet aux côtés de votre tableau Kanban, de vos jalons et de votre moodboard, la connexion entre documentation et exécution est intégrée. Vous pouvez consulter votre moodboard en rédigeant la section direction artistique. Vous pouvez vérifier votre tableau de tâches en mettant à jour la section périmètre. Tout est dans le même espace de travail. L'assistant IA peut aussi vous aider avec votre GDD. Demandez-lui de rédiger un brouillon de section pour votre système de combat ou votre plan de monétisation, et il générera un point de départ basé sur le contexte de votre projet. Il ne remplacera pas votre réflexion de design, mais il peut vous faire gagner du temps sur le premier brouillon pour que vous puissiez vous concentrer sur le raffinement des détails qui comptent.

Si vous vous sentez submergé par l'idée de rédiger un GDD complet, commencez par une seule page. Titre du jeu, genre, plateforme, un paragraphe décrivant la boucle principale, et un paragraphe décrivant la direction artistique. C'est tout. Vous avez maintenant un GDD. À partir de là, ajoutez des sections au besoin. Sur le point de construire le système d'inventaire ? Écrivez d'abord la section inventaire. Sur le point de briefer un artiste sur le design des personnages ? Écrivez la section direction artistique avec des images de référence. Le document grandit organiquement avec le projet au lieu d'être un investissement initial massif. L'objectif n'est pas d'avoir un document parfait. L'objectif est d'en avoir un utile. Un GDD brut d'une page qui est consulté chaque semaine vaut plus qu'un magnifique document de 40 pages qui reste non lu dans un dossier Google Drive. Commencez petit, soyez honnête, et mettez-le à jour quand la réalité change. C'est tout ce qu'il faut.