Aller au contenu principal

Choisir ses outils

L'atelier est réel : la chaîne de chargement fonctionne, et Visual Studio compile du C# contre le bon framework. Avant P0, une dernière décision d'installation. Elle ne porte pas sur le matériel. Elle porte sur les deux outils avec lesquels tu passeras chaque session : ton éditeur, et la question de savoir si tu amènes un assistant IA avec toi.

Ton éditeur est ton établi​

Tu as déjà installé Visual Studio, et pour ce cours, c'est le bon choix. Pas parce que c'est à la mode, mais parce qu'il te donne trois choses qu'un éditeur de texte ne peut pas. L'IntelliSense complète l'API pendant que tu tapes, et c'est ainsi que tu découvres ScriptHookVDotNet au lieu de l'apprendre par cœur. Les diagnostics du compilateur font remonter les erreurs dès que tu les tapes. Et le débogueur s'attache au GTA5.exe en cours pour que tu voies exactement quelle ligne a figé le jeu.

D'autres éditeurs existent, et certains sont charmants. Mais un premier projet n'est pas le moment de lutter contre ton outillage. Apprends le métier sur l'établi qui a le débogueur intégré, et décide plus tard si tu veux déménager.

L'assistant IA : ton choix, pas une obligation​

Aucune obligation d'utiliser l'IA ici. Chaque projet de ce cours est conçu pour que tu puisses le construire à la main, et une grande partie de l'apprentissage se produit justement quand tu es bloqué. Si tu aimes comprendre les choses seul, rien dans cette école n'exige d'assistant.

Si tu en veux un, la façon moderne n'est pas un chatbot dans lequel tu colles ton code. C'est un agent de codage qui vit dans ton projet : opencode, Google Antigravity, Claude Code, Codex, et d'autres. Tu décris un problème dans ton éditeur, l'agent lit tes vrais fichiers, propose des modifications, et c'est toi qui décides quoi garder. Ils diffèrent par leur interface et par le modèle qui les alimente, mais ce détail compte moins que l'habitude que tu formes autour d'eux.

Comment je travaille avec un agent​

Voici le workflow auquel j'ai atterri après des centaines d'heures à coder des mods comme Street Riders et InteractV. Un agent de codage n'est pas un tuteur académique poli qui te pose des questions socratiques. C'est un ingénieur junior infatigable dans ton équipe, et c'est toi le lead dev.

Dans le modding GTA V, laisser une IA coder sans garde-fous mène droit dans le mur :

  • Elle invente des fonctions natives et des méthodes ScriptHookVDotNet qui n'ont jamais existé ou sont obsolètes depuis des années.
  • Quand un PNJ se fige dans une animation, elle emballe le code dans un timer arbitraire au lieu de diagnostiquer la transition d'état cassée.
  • Quand un script crash, elle tourne en rond à faire des suppositions et réécrit du code qui marchait au lieu de lire les logs du jeu.

Pour obtenir du travail fiable d'un agent, tu ne lui demandes pas de jouer au professeur. Tu lui donnes un contrat d'ingénierie strict.

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 la plus importante 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 à un agent : « Je veux des deals de drogue dans la rue. » Un prompt vague te donnera un script superficiel, sans âme, 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 diégétique, ou un menu LemonUI 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 l'IA ne devinera jamais pour toi :

  • « Il soutient le regard » : Quelle native gère ce comportement ? C'est TASK_LOOK_AT_ENTITY (ped.Task.LookAt(target)), pas une méthode imaginaire.
  • « Dans une ruelle » : Le moteur RAGE de GTA n'a pas de concept magique de 'ruelle'. Comment la détecter ? Par deux raycasts horizontaux latéraux (World.Raycast) pour vérifier des murs étroits à moins de 4 mètres et l'éloignement d'un node routier majeur (GET_CLOSEST_VEHICLE_NODE) ?
  • « En territoire de gang » : Comment savoir si on y est ? En lisant la zone de la carte (GET_NAME_OF_ZONE), en scannant la présence ambiante de peds du gang, ou via un fichier de configuration de territoire data-driven ?
  • « Faire un signe discret » : Quelle animation réelle du jeu applique-t-on ? Quel prop 3D pose-t-on dans la main du PNJ ?

Si tu laisses l'IA deviner ces détails sans les cadrer, elle va t'inventer des fonctions fantaisistes comme World.IsPlayerInAlley(), des animations imaginaires (anim@drug_deal@nod) ou des hashes d'objets inexistants qui échoueront en silence dans le jeu.

La conception consiste à relier ta vision de jeu aux vraies mécaniques et aux vrais atouts du moteur grâce aux bases de référence (toutes détaillées dans notre guide des Liens utiles) :

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 viscéral et amusant. Créer une expérience cohérente, vivante et percutante que les joueurs apprécient demande un vrai regard humain. C'est ça, ton vrai travail de moddeur.

Le fichier de règles de départ : AGENTS.md​

Les agents de codage modernes comme Claude Code, OpenCode, Google Antigravity et Cursor lisent les règles du projet dans un fichier à la racine de ton espace de travail : AGENTS.md (ou CLAUDE.md). Quand ce fichier est présent, l'agent charge ces contraintes dans son contexte dès le début de chaque session.

remarque

Ce fichier de règles est une base de départ générique, pas un dogme absolu gravé dans le marbre. Il reflète les garde-fous forgés sur des mods en production, mais tu dois adapter ses règles, ses chemins et ses contraintes aux besoins de ton propre projet.

Crée un fichier AGENTS.md dans le dossier où vit la solution de ton mod :

# AGENTS.md

Règles de départ pour le modding GTA V en C# avec ScriptHookVDotNet.

## Règles fondamentales

1. NE JAMAIS DEVINER : Même avec une confiance élevée, pose toujours des questions pour clarifier la demande avant d'écrire du code. Clarifie les déclencheurs, le comportement attendu des PNJ et les cas limites.
2. VÉRIFIER CONTRE LES VRAIES SOURCES ET LE SDK : N'invente jamais de native, de dictionnaire d'animation ou de hash de prop de mémoire. Si une méthode ne s'autocomplète pas dans le SDK ou provoque un avertissement du compilateur, elle n'existe pas. Vérifie systématiquement sur les bases de référence avant d'écrire :
   - Natives : base CitizenFX (https://github.com/citizenfx/natives ou https://docs.fivem.net/natives/)
   - Animations : Pleb Masters Forge (https://forge.plebmasters.de/animations) pour les vrais animDict et animName
   - Props et Objets : Pleb Masters Forge (https://forge.plebmasters.de/objects) pour les hashes et modèles réels
   - SDK C# : assembly réel ScriptHookVDotNet3.dll et scripts décompilés de référence
3. LOGS DE DIAGNOSTIC DÈS LE DÉPART : Place tes sondes de log dès l'écriture du code, jamais après être déjà bloqué :
   - Journalise les quatre points cruciaux : Décisions (pourquoi une action a été choisie), Transitions (de l'état A vers l'état B), Fallbacks (cible perdue, chemin bloqué), et Résultats (tâche terminée, entité nettoyée).
   - Ajoute toujours du contexte : Timestamp (`Game.GameTime`), handle de l'entité, nom de l'état et distance. N'écris jamais de logs vides du genre « ici » ou « ok ».
   - Zéro log par frame : N'écris jamais sur le disque à chaque frame de `OnTick`. Loggue sur les événements, les entrées et les sorties d'état pour ne pas effondrer les performances.
   - En cas de bug, lis les logs avant de deviner : si une anomalie n'apparaît pas dans tes logs, ajoute des sondes sur le chemin avant de modifier la moindre logique.
4. ARCHITECTURE SRP ET DATA-DRIVEN AVANT LE CODE : Définis toujours les responsabilités et les contrats de données avant d'écrire les lignes d'implémentation :
   - Responsabilité unique (SRP) : Zéro God Class. Une classe a une seule responsabilité, son propre état et un cycle de vie explicite. La classe principale de ton script n'est qu'un point d'assemblage (composition root), pas un fourre-tout métier.
   - Approche data-driven : Zéro valeur de tuning en dur dans le C#. Exporte les bascules de features (activer/désactiver), les distances, seuils et cooldowns dans des fichiers de configuration (.ini ou XML) pour activer, couper et ajuster tes systèmes sans recompiler le mod à chaque essai.
   - FSM explicite : Modélise les comportements de PNJ sous forme de machine à états avec des transitions nettes, jamais en empilant des if/else géants.
5. NETTOYAGE DES ENTITÉS ET ZÉRO TIMER TRICHE : Chaque PNJ, véhicule ou blip créé doit être nettoyé au rechargement ou à l'arrêt du script. N'entoure jamais un état bloqué d'un timer arbitraire pour forcer sa complétion : corrige la vraie condition de fin.

Le cycle de travail en trois phases​

Une fois ton fichier de règles posé, découpe chaque session de travail en trois phases distinctes au lieu de réclamer un script complet d'un seul coup :

1. Cadrage, SRP, configuration​

Avant de générer la moindre ligne de C#, force l'agent à poser l'architecture :

  • « Je veux un garde du corps qui me suit et me défend contre les agresseurs. Avant d'écrire le moindre code, liste les classes et leur responsabilité unique (qui décide vs qui exécute la tâche), les états FSM de ce PNJ, et les paramètres qui vont dans un fichier .ini pour que je puisse activer/désactiver la feature et tuner les distances sans recompiler. »
  • Valide d'abord les responsabilités, les états (Following, Combat, Returning) et les options de config (Enabled=true, FollowDistance=5.0). Corriger une liste d'architecture prend dix secondes. Refactoriser deux cents lignes de C# monolithique prend des heures.

2. Implémentation, sondes de diagnostic​

Fais écrire le code par petits contrats ciblés et place les sondes immédiatement :

  • Le compilateur C# et l'IntelliSense sont ton premier filtre de sécurité : 0 erreur et 0 avertissement contre le SDK réel.
  • Pose les logs de diagnostic dès l'écriture, pas après le bug : GTA V tourne en plein écran, tu n'as pas de terminal qui défile sous les yeux pendant que tu joues. Ton fichier de log est ta boîte noire. Si un PNJ reste immobile en jeu sans logs, tu es totalement aveugle : impossible de savoir si le spawn a échoué, si une condition FSM a renvoyé faux, ou si l'IA native de Rockstar a écrasé ta tâche.
  • Vérifie que chaque état journalise ses quatre points clés : la décision d'agir, la transition d'état, le fallback si la cible disparaît, et le nettoyage final.
  • Ajoute du debug visuel simple : un sous-titre temporaire ou un texte au-dessus du PNJ affichant son état courant et son handle te donne une confirmation immédiate en jeu sans même avoir à quitter l'écran.

3. Diagnostic en jeu sur pièces​

Quand tu testes en jeu et qu'un comportement coince (un PNJ qui regarde dans le vide, un véhicule qui fonce dans un mur), ne demande jamais à l'agent de deviner :

  • Ouvre ScriptHookVDotNet.log ou le fichier de log de ton mod.
  • Si le log affiche Transition : Idle -> Approach [Ped 104] puis reste muet, tu sais exactement que le problème se situe dans la condition de fin de Approach.
  • Si le bug n'apparaît nulle part dans les logs, tes sondes sont mal placées : ajoute des logs dans les branches de décision, recharge le script avec Insert, et diagnostique sur des faits réels au lieu de tourner en rond.

La ligne à ne pas franchir​

Utilise l'IA pour construire et comprendre plus vite, jamais pour sauter la compréhension. Si tu termines un projet et que tu ne peux pas expliquer comment sa machine à états bascule ou pourquoi une entité est nettoyée, tu ne l'as pas appris, tu l'as loué. Les projets de ce cours sont des points de contrôle précisément parce que le jeu ne négocie pas avec les bonnes intentions : soit tu comprends ton garde du corps, soit il te tire dessus.

Choisis ton établi, pose tes règles, et garde les mains sur le volant. P0 est le moment où ton installation est vraiment mise à l'épreuve.