Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.
L’une des responsabilités principales d’un game designer, c’est d’écrire de la documentation de design. N’importe qui peut écrire des documents, mais un designer, lui, produit de la documentation — et c’est une tout autre affaire.
Un document, ça contient des pensées, des idées, n’importe quoi. La documentation, en revanche, est un type de document spécifique sur quelque chose de concret. Une analyse d’un jeu concurrent. Le résultat d’un playtest. Une feature qu’on a construite et observée en action. Un prototype qui a répondu à une question précise.
Pour comprendre pourquoi cette règle est si souvent bafouée, il est utile de réfléchir à comment la connaissance s’accumule au fil du développement d’un jeu.
Concept DOCUMENTS
Au début d’un projet, presque tout est incertain.
- Constraints | Il y a des choses qu’on sait déjà : la plateforme cible, le genre, peut-être le budget.
- Frontiers | Il y a des questions auxquelles on sait qu’on doit répondre : comment fonctionne le core loop, quelle est la durée d’une session type.
- Risks | Il y a les choses qu’on ne sait pas qu’on ne sait pas encore. Les problèmes de design qui n’émergent que quand le joueur a la manette en main. Les interactions entre systèmes qui semblaient évidentes sur le papier et se révèlent catastrophiques en pratique. Les hypothèses que personne n’a jamais remises en question parce qu’elles paraissaient tellement évidentes qu’elles ne méritaient pas qu’on s’y attarde.
Un concept document vit presque entièrement dans cette troisième couche. Ce n’est pas de la documentation, c’est un instantané de l’imaginaire de l’équipe à un moment précis.
Game Design DOCUMENTATION
La vraie documentation émerge après. Après qu’on a prototypé et découvert que la mécanique qui semblait brillante ne fonctionne pas comme on le pensait. Après qu’on a analysé comment un autre jeu a résolu le même problème. Après qu’on a testé et observé. À ce stade, on a quelque chose à documenter pour de bon.
Documents et Documentation
Un document sert un objectif temporaire. Les notes d’une réunion sont un document. Un concept doc est un document. Une liste d’idées griffonnées avant une session de brainstorming est un document. Ce sont des outils de travail valables, nécessaires, et ils ont une durée de vie naturelle : ils servent maintenant, puis ils passent aux oubliettes.
La documentation, en revanche, est pensée pour durer.
- Elle doit être claire pour quelqu’un qui n’était pas dans cette réunion.
- Elle doit être pratique, une référence qu’on peut vraiment utiliser, pas seulement lire.
- Elle doit inspirer celui qui la lit six mois plus tard, quand l’enthousiasme des débuts est retombé et qu’on a besoin d’appuis concrets.
- Et elle doit être attrayante : pas comme exercice esthétique, mais parce que si personne n’ouvre un document, ce document n’existe pas. J’applique cette formule : 60 % de l’espace doit être occupé par des éléments visuels (diagrammes, images, vidéos…). 30 % par des données et des tableaux. 10 % de texte. La documentation, ce n’est pas un traité ou un roman à lire !
Tous les documents ne sont pas de la documentation, et le projet nécessitera différents types de documents. Votre équipe, elle, a besoin de documentation.
À quoi ressemble une vraie documentation
Une bonne documentation de design répond à quelques questions de façon univoque : c’est quoi ce jeu ? Pourquoi c’est intéressant ? Quelle est la fantasy, la promesse émotionnelle faite au joueur ? Quelles sont les features core — pas toutes les features, seulement celles qui définissent l’identité du produit ? Comment fonctionne exactement ce système ? Et suffisamment de contexte de production pour rendre le document actionnable.
Il y a un principe que je trouve particulièrement utile dans ce sens : si une équipe n’arrive pas à expliquer son jeu de façon claire et concise, c’est probablement que le design n’est pas encore assez clair. La clarté de la documentation reflète la clarté de la pensée. Un document dense, bourré de sections et de sous-sections qui cherchent à couvrir tous les cas de figure, c’est souvent le signe qu’on ne sait pas encore assez pour documenter.
Et ça nous ramène à la règle numéro 1. Si vous n’avez pas encore quelque chose de concret à documenter, ce n’est peut-être pas le moment d’écrire de la documentation. C’est le moment de faire de la recherche. De construire un prototype. De tester. De répondre aux questions qu’on ne sait pas encore qu’on a. D’apprendre et de découvrir.
Est-ce que ça documente quelque chose qui existe, ou quelque chose qu’on veut construire ?