Aller au contenu principal

Choisir ses outils

Après avoir vérifié la chaîne de chargement, choisis l’éditeur que tu utiliseras pour le TP 0 et décide si un assistant IA fera partie de ton travail.

Ton éditeur est ton établi​

Visual Studio Community est un point de départ pratique : la complétion aide à explorer l’API ScriptHookVDotNet, les diagnostics du compilateur signalent les erreurs pendant la saisie et son débogueur peut s’attacher à GTA5.exe pour examiner un script en cours.

VS Code, Rider et d’autres éditeurs peuvent aussi convenir. Choisis-en un qui compile une bibliothèque .NET Framework et qui permet de lire les erreurs sans te battre avec l’outillage.

Utiliser un assistant IA​

Rien n’oblige à utiliser une IA ici. On peut faire les TP à la main et apprendre des problèmes que l’on résout soi-même.

Pour aller plus loin, un agent de dev travaille directement au cœur de 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, te propose des modifications, et tu décides de ce que tu gardes. Leurs interfaces et leurs modèles diffèrent, mais ce détail compte moins que l'habitude que tu prends avec eux.

Comment je travaille avec un agent​

Voilà la méthode rodée après des centaines d'heures à coder des mods comme Street Riders ou InteractV. Un agent de dev IA agit comme un développeur junior infatigable dans ton équipe, dont tu es le responsable technique.

Dans le modding GTA V, laisser coder un agent sans cadre mène droit dans le mur :

  • Il invente des fonctions natives et des méthodes ScriptHookVDotNet qui n'ont jamais existé ou qui sont dépréciées depuis des années.
  • Quand un ped fige dans une animation, il entoure le code d'un timeout arbitraire au lieu de diagnostiquer la transition d'état cassée.
  • Quand un script plante, il tourne en boucle à deviner et réécrit du code qui marchait au lieu d'inspecter les logs du jeu.

Pour obtenir du travail fiable d'un agent, impose-lui un cadre d'ingénierie strict.

D'une idée à une conception​

Le TP 0 vérifie l’installation sans concevoir de gameplay. À l’étape 1, le document de conception donne au mod un plan d’une page avant son premier code de gameplay.

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

De nombreux agents de développement peuvent lire des règles de projet dans AGENTS.md ou dans un fichier propre à l’outil, comme CLAUDE.md. Vérifie comment l’outil choisi charge ses instructions : le fichier n’aide que si l’agent le lit réellement.

remarque

Ce fichier de règles fournit une base de départ adaptable. Il reflète les garde-fous forgés sur des mods en production, à ajuster selon les contraintes de chaque 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. L’autocomplétion peut manquer une API valide ; examine le vrai SDK, compile et étudie les avertissements avant d’utiliser un nom. Vérifie 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) : aucune classe ne fait tout. Une classe a une seule responsabilité, son propre état et un cycle de vie explicite. La classe principale de ton script ne fait que relier les systèmes, elle ne contient pas la logique de jeu.
   - 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 :

  • « Dans une scène de rue, un rival s’approche du joueur et peut déclencher un combat. Avant de coder, distingue qui décide du démarrage de la scène, qui pilote le rival, ce qui termine la rencontre et ce que le joueur doit voir. »
  • Valide les responsabilités, les états visibles et leurs conditions de fin. Construis et teste ensuite ces états un par un.

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.
  • Poser les logs de diagnostic dès l'écriture : GTA V s'exécute en plein écran sans affichage de console par défaut. Le fichier de log enregistre l'historique des opérations du mod. Si un PNJ reste immobile en jeu sans journalisation, aucun élément n'indique si l'instanciation a échoué, si une condition FSM a renvoyé faux ou si l'IA native a interrompu la 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, examine ce qui s’est passé après cette transition, y compris les erreurs et la condition de fin.
  • 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 explorer et construire, puis vérifie ce qu’elle a modifié. Si tu ne peux pas expliquer pourquoi ton mod change d’état ou quand ses acteurs sont nettoyés, reviens au code et au résultat en jeu avant de continuer.

Choisis tes outils et garde la maîtrise des modifications. Le TP 0 teste l’installation en jeu.