De l’idée de jeu au prototype : écrire un brief d’une page et une liste de tâches

Un brief d’une page vaut mieux qu’un document de design de quarante

Pour un prototype, un long document de design vieillit avant d’avoir servi. Un brief d’une page tient en tête, se relit en deux minutes et peut être donné à un coéquipier ou à un agent de code. Il ne décrit pas tout le jeu : il explique ce que vous testez, pourquoi, et ce que vous laissez volontairement de côté.

1. Les six lignes du brief

Écrivez : l’intention (ce que le joueur doit ressentir), la mécanique à tester, les références utiles, les contraintes (temps, outils, portée), ce qui est hors périmètre et la question à vérifier. Pour Dicebound : « Tester si verrouiller un dé crée une décision intéressante. Références : Dicey Dungeons, Slice & Dice. Contraintes : un personnage, un ennemi, deux soirées. Hors périmètre : progression, sons, menus. Question : les testeurs relancent-ils volontairement ? »

2. Découpez en tâches de moins d’une demi-journée

Chaque tâche doit tenir en une session de travail. Pour Dicebound : afficher trois dés et un ennemi ; permettre de verrouiller un dé ; relancer les dés non verrouillés ; répartir les résultats entre attaque et défense ; afficher l’intention de l’ennemi ; écran de fin de combat. Une tâche trop vague, comme « faire le combat », cache plusieurs décisions. Découpez-la jusqu’à pouvoir la terminer sans nouvelle réunion avec vous-même.

3. Donnez à chaque tâche un résultat observable

Décrivez ce qu’on peut voir ou faire une fois la tâche terminée : « Je clique sur un dé, il se verrouille et ne bouge plus au lancer suivant. » Cette phrase sert de critère de relecture, que ce soit vous, un coéquipier ou un agent qui ait codé la tâche. Ajoutez une ligne sur ce qui ne fait pas partie de la tâche pour éviter les ajouts silencieux.

4. Dans Impstash : de l’idée gardée à la tâche

Marquez l’idée comme gardée, puis créez la tâche depuis l’idée : son titre et son texte servent de point de départ et la tâche reste liée à l’idée. Complétez la description avec le brief, puis placez les tâches dans les colonnes du Kanban. Pour chaque tâche, une version peut être soumise à relecture avec une note et des liens, et un membre l’accepte ou demande une reprise.

5. Terminez par une tâche de test, pas par une fonctionnalité

La dernière tâche du lot est toujours : « Faire essayer à trois ou cinq personnes et noter ce qu’elles ont fait. » Sans cette tâche, le prototype sert à construire un jeu et non à répondre à votre question. Après le test, mettez à jour le brief : gardez, ajustez ou abandonnez, puis écrivez le prochain pari.

Un prompt à adapter à votre jeu

Voici une idée retenue pour Dicebound : verrouiller un dé, relancer les autres et répartir les résultats entre attaque et défense. Références : Dicey Dungeons, Slice & Dice. Contraintes : un personnage, un ennemi, deux soirées. Écris un brief d’une page avec intention, mécanique à tester, références, contraintes, hors périmètre et question à vérifier. Puis propose six tâches de moins d’une demi-journée, chacune avec un résultat observable. Termine par une tâche de test avec cinq personnes. Signale les points où tu fais une hypothèse.

Remplacez les références et les contraintes par les vôtres. Les réponses de l’IA sont des pistes à examiner ; le choix reste le vôtre.

Références et communautés pour continuer

• Dicey Dungeons — Des valeurs de dés transformées en décisions : observer les contraintes des équipements.
• Slice & Dice — Des intentions ennemies visibles : comparer risque, relance et coopération des dés.
• Dicey Dungeons — Notes du créateur et vidéos
• r/gamedesign — Pour discuter des mécaniques, des règles et des compromis de design.
• r/gameideas — Pour partager une idée structurée et développer ses possibilités. Vérifiez les règles avant de publier.