Le game design document

La qualité d'un mod, c'est la façon dont le joueur le vit dans un monde ouvert, et une large part se décide avant qu'une seule ligne de code soit écrite. C'est le rôle du game design document (GDD) : une page qui décrit ce que tu veux faire, comment le joueur le vit, et comment tu vas le réaliser avec les vrais outils du moteur.

Le TP 0 a vérifié l’installation. Maintenant, avant d’écrire le gameplay, on donne au mod un GDD d’une page. On fait évoluer le même document à mesure que le mod grandit, au lieu de recommencer à chaque étape.

Écrire un GDD ne demande aucun outil de plus : une feuille ou un éditeur de texte suffit. Les deux prochaines leçons découpent le mod en incréments jouables et vérifient les capacités du jeu dont ils ont besoin.

La conception d'abord : le métier du moddeur

Avant même de taper un prompt ou d'écrire la moindre ligne de C#, l'étape décisive se joue dans ta tête : tu dois savoir exactement ce que tu veux et être capable de l'exprimer clairement en langage naturel.

Ne dis jamais simplement : « Je veux des deals de drogue dans la rue. » Une intention vague te donnera un script superficiel qui casse dès la première situation imprévue.

Tu dois penser à chaque étape chronologique du point de vue du joueur :

• Que voit-il au départ ? Est-ce que l'acheteur s'approche naturellement, soutient le regard, ou fait un signe discret ?
• Dans quelles conditions ? Est-ce que la scène se passe uniquement la nuit, dans une ruelle, ou au cœur d'un territoire de gang ?
• Que se passe-t-il si l'imprévu surgit ? Qu'arrive-t-il si une patrouille de police tourne au coin de la rue pendant la transaction ? Est-ce que l'acheteur fuit, jette la marchandise, ou sort une arme ?
• Comment le joueur le vit-il ? Est-ce une vraie réplique en sous-titre, ou un menu qui coupe l'immersion ? Quel retour indique que l'action est réussie ou ratée ?

Derrière chaque intention en français se cache une réalité technique du moteur GTA que personne ne devinera pour toi :

• « 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, ou on isole l'action comme restant à confirmer.
• « Dans une ruelle » : le moteur de GTA n'a pas de concept magique de 'ruelle'. À 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. Ensuite 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 prop existe pour la main du personnage. Tu cherches les deux dans les vraies listes d'animations et de modèles.

Laisser ces détails au hasard conduit tout droit au blocage : une méthode inventée comme World.IsPlayerInAlley() est rejetée dès la compilation (CS0117), tandis qu'un nom d'animation (anim@drug_deal@nod) ou un hash de prop inexistant refusera de charger dans le jeu.

Concevoir, c’est relier son idée aux mécaniques et aux ressources réelles du jeu à l’aide de bases de référence :

• Animations : Pleb Masters Forge Animations pour chercher, filtrer et prévisualiser en 3D une animation sur des PNJ avant de récupérer les vrais animDict et animName.
• Props et objets : Pleb Masters Forge Objects pour trouver les modèles 3D et les hashes vérifiés d'armes, de sacs, de paquets ou de téléphones.
• Natives : CitizenFX Natives et docs.fivem.net/natives pour vérifier chaque native GTA V, ses arguments et sa valeur de retour.

Tu peux tout à fait mener cette réflexion avec l'IA : demande-lui de te poser des questions sur ton idée, de pointer les angles morts ou de suggérer des variantes. Mais une IA n'a aucun goût, aucun sens du tempo, et aucun souvenir de ce qui rend GTA prenant à jouer. Créer une expérience cohérente que les joueurs apprécient demande un vrai regard humain. C'est ton vrai travail de moddeur.

Ce que contient un GDD d'une page

Cinq rubriques suffisent pour poser le projet avant le code :

1. Le concept : le mod en une phrase, sans jargon technique.
2. Le parcours joueur : étape par étape, ce que le joueur voit, entend et a le droit de faire. C'est ici que les questions « que se passe-t-il si... » reçoivent leurs réponses.
3. Les conditions : quand et où le mod existe (heure, zone, distance, état du monde).
4. Les échecs : ce qui peut casser, et ce qui se passe alors (abandon, retour au calme, nettoyage).
5. Les ancrages techniques : les natives, animations, props et modèles réels qui répondront à ces intentions, vérifiés sur les bases de référence. Jamais depuis ta mémoire.

Et une règle de périmètre : ce qui ne sera pas dans la première version. C'est une rubrique difficile à écrire, et celle qui te sauve.

Exemple : une première rencontre de rue

Cet extrait décrit un premier incrément jouable d’un mod de rencontre de rue :

• Concept : un rival s’approche du joueur à un coin de rue ; un allié se tient à proximité.
• Parcours joueur : le rival avance, peut pousser le joueur puis dégaine si la confrontation s’aggrave. L’allié réagit au combat. Le joueur voit quand la scène se termine.
• Conditions : choisir un coin de rue visible et un déclencheur clair. La distance exacte reste à tester.
• Échecs : si un acteur meurt ou disparaît, les autres cessent de suivre l’ancien plan et la scène nettoie les ressources qu’elle possède.
• Ancrages techniques à vérifier : une tâche d’approche, un comportement de confrontation, le combat et le nettoyage des acteurs. On ne note les vrais noms d’API qu’après vérification dans le SDK et les sources.
• Périmètre : ni économie territoriale ni dialogue à embranchements dans ce premier incrément.

Les inconnues restent visibles dans le document. La leçon suivante découpe la scène en incréments ; celle d’après vérifie les capacités du jeu nécessaires.

Un GDD pour le mod qui évolue

Un mod garde un seul GDD. Avant chaque nouvel incrément, on actualise le parcours joueur, les cas d’échec et les ancrages techniques. La page reste le plan de travail du même mod.

Le GDD sert aussi de contrôle du résultat en jeu : on compare ce que le joueur voit à ce que la page annonçait.

Vérifie par toi-même

1. Rédige un GDD d’une page pour le mod que tu veux construire.
2. Pour chaque intention, note au moins un ancrage technique vérifié, ou indique clairement qu'il reste à chercher. Garder les doutes visibles dans le GDD est sain : c'est une recherche à mener, pas une réponse à inventer.
3. Indique ce que le premier incrément jouable laisse de côté.

Ensuite, délimite le périmètre en incréments jouables, puis vérifie que le jeu peut les prendre en charge.