Le jeu peut-il le faire ?

Je l'ai appris à la dure, et l'IA a rendu la leçon plus chère. Demande à un chatbot quelle animation le jeu joue pour « un signe discret » : il t'invente un nom, sûr de lui. Ce nom ne produit rien une fois le jeu lancé, aucune erreur, aucun crash. Depuis, je ne devine plus un nom. Je vérifie qu'il existe dans le jeu, ou je note qu'il reste à trouver avant de continuer. Cette leçon montre la différence, et pourquoi elle décide du sort de ton GDD.

Chaque phrase de ton GDD, tu la comprends parce que tu l'as écrite. Le jeu, lui, ne lit pas ton GDD. « L'acheteur soutient le regard », « la scène a lieu dans une ruelle », « le deal se passe en territoire de gang » : pour que le jeu fasse vivre ces phrases, quelque chose dans le moteur doit pouvoir le faire, et quelque chose doit pouvoir le détecter. À ce stade, ton travail de conception, c'est de poser la question avant la première ligne de code : le jeu peut-il le faire, et comment le saura-t-il ?

Ce que le jeu doit savoir

Chaque intention de ton GDD mérite les mêmes quatre questions :

• Qu'est-ce que je veux que le jeu fasse ?
• Qu'est-ce que le jeu doit savoir pour le faire ?
• Le jeu a-t-il un moyen de le savoir ?
• Qu'est-ce que je dois détecter ou mesurer, exactement, pour transformer ma phrase française en un fait vérifiable ?

Prends les intentions de ta propre scène, une par une, et pose-leur ces questions.

« Il soutient le regard » : le jeu doit pouvoir diriger le regard d'un personnage vers un autre. Une capacité pour ça existe-t-elle ? On cherche dans les tables de natives, et tant que rien n'est confirmé, l'intention reste marquée comme non vérifiée.

« Dans une ruelle » : rien dans le moteur ne porte l'étiquette « ruelle ». Le monde, c'est de la géométrie et des routes. À toi d'inventer la définition, et une définition se mesure : des murs serrés des deux côtés, un passage étroit, loin d'une route fréquentée. Dès que tu as choisi, tu vérifies que le jeu sait mesurer une distance et détecter des murs proches.

« En territoire de gang » : aucune carte ne dessine les frontières des gangs. Tu décides ce qui le prouve : une zone de la carte, des membres du gang alentour, ou une liste de territoires que tu définis et donnes au jeu. Chaque option est une capacité à vérifier.

« Faire un signe discret » : il faut qu'une animation existe dans les fichiers du jeu, et qu'un petit objet existe pour être posé dans la main du personnage. Les deux se cherchent par leur vrai nom dans les vraies listes, pas dans l'imagination.

Le piège des noms inventés

Si tu sautes ce contrôle, ton GDD se remplit de choses que le jeu n'a jamais vues. Tu écris un nom d'animation comme anim@drug_deal@nod qu'aucun dictionnaire ne contient, ou un hash de prop qui ne pointe vers rien. Ce sont des chaînes : rien ne s'affiche au moment où tu les écris, phrase après phrase, parce que le jeu ne le découvre qu'en essayant de les charger. Mais tu n'es pas aveugle pour autant. Un nom d'animation inventé ne charge pas, et le moteur a de quoi te le dire — tu le demandes et tu interroges son état de chargement. Une méthode inventée sur une API typée comme World.IsPlayerInAlley() ne compile même pas : C# la refuse à la compilation. Le blocage survient dès lors qu'on utilise une ressource sans jamais interroger son état de chargement.

Comment le jeu peut répondre

« Le jeu peut-il le faire ? » reçoit trois formes de réponses, et les connaître te permet de chercher au lieu de deviner :

• Une native : une fonction que le moteur expose à ton script, un comportement du moteur sous un nom public. Dès que tu veux que le jeu fasse quelque chose, ta question devient : une native existe-t-elle pour ça ?
• Une animation : le jeu n'invente aucun geste tout seul. Chaque marche, chaque signe, chaque coup est un clip stocké dans les fichiers et joué sur un personnage. Ton intention peut reposer sur une animation ; il te faut son dictionnaire et son clip, tous deux réels.
• Un modèle ou un prop : c'est ce que tu poses dans le monde. Un sac, un téléphone, une arme posée sur la table : chacun a un nom dans les listes du jeu. Si le nom n'existe pas, rien n'apparaît.

Ces listes sont publiques : l’index des natives CitizenFX documente leurs noms et paramètres ; les catalogues d’animations et d’objets de Pleb Masters Forge aident à identifier les ressources. On vérifie un identifiant dans la référence puis, plus tard, dans le jeu. On ne remplit pas le GDD avec des noms sortis de mémoire.

Garder les doutes visibles

À ce stade de la conception, chaque intention se range dans deux situations : soit la capacité existe dans le jeu et son identifiant réel est consigné, soit elle n'a pas encore été vérifiée.

Le réflexe dangereux consiste à combler le vide avec un nom approximatif pour donner l'illusion d'un document complet. Un nom inventé crée une fausse certitude. Consigner le doute explicitement permet de savoir exactement ce qu'il reste à chercher dans les index avant d'écrire la moindre ligne de code. Si la recherche ne donne rien, l'intention se réécrit tant que la scène n'est encore qu'une phrase.

Le livrable de cette étape

Au bout de la conception, le GDD s'accompagne d'une liste : chaque intention appelant une native, une animation ou un modèle figure avec son identifiant vérifié ou la mention qu'elle reste à confirmer. Les intentions sans ancrage technique deviennent les candidates immédiates à une réécriture. Changer une phrase maintenant ne coûte rien. Découvrir à mi-construction que le jeu ne peut pas le faire, c'est un après-midi perdu.

Avant d’écrire du code, actualise le GDD du mod avec cette liste. Il donne un point de départ concret au premier incrément de code ; on le révise si un test contredit une hypothèse.