Développement de jeux Godot avec l'IA

Définissez la frontière du projet avant les modifications

Commencez depuis un répertoire de projet dont vous avez la maîtrise et une liste écrite des modifications autorisées. Inventoriez les scènes, scripts, assets et plugins existants afin que l'agent étende la structure actuelle au lieu de créer une seconde implémentation. Gardez l'état initial du projet récupérable et enregistrez le binaire du moteur qui l'ouvre.

Choisissez une petite tranche jouable avec des transitions explicites. Par exemple, un écran-titre menant à une salle et revenant par une victoire ou une défaite fournit un test répétable. Décidez qui relit la composition visuelle et les contrôles, car ni un analyseur réussi ni le message d'achèvement d'un modèle ne prouvent que l'expérience est cohérente.

Identifiez l'exécutable et les arguments pris en charge

La documentation CLI stable de Godot fournit les commandes ci-dessous. GODOT_BIN et PROJECT sont des variables shell choisies pour cet exemple, et non des paramètres Godot ; remplacez leurs chemins placeholders par votre exécutable et votre projet existants. Le chemin du projet doit contenir project.godot.

Capturez la version et la sortie d'aide avant de scripter d'autres flags. Vous éviterez ainsi de supposer qu'une commande présente dans la documentation en ligne actuelle existe dans votre build installé. Enregistrez l'identité du binaire avec les résultats de test ultérieurs et gardez-la stable pendant l'analyse d'un échec. Ces commandes illustratives utilisent les formes CLI documentées.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

Séparez import, analyse et jeu réel

Un import headless contrôle une frontière de traitement des assets. Un contrôle d'analyse examine un script. Un lancement normal atteint le jeu et peut révéler le câblage des scènes et les problèmes runtime. Gardez ces résultats séparés dans le dossier de revue au lieu de résumer les trois par « tests réussis ».

Le chemin de script illustratif ci-dessous doit déjà exister dans votre projet. Un contrôle d'analyse est volontairement étroit : il ne peut pas établir le bon fonctionnement des collisions, la réactivité des entrées ou la persistance correcte. Après une modification, rejouez le comportement concerné et la transition immédiatement avant et après. C'est souvent plus instructif que de créer de nombreux contrôles isolés pour des fonctions auxiliaires générées.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

Choisissez délibérément les outils CLI ou MCP

Un agent capable d'utiliser un shell peut exécuter une séquence CLI relue. Godot MCP est une interface d'outils supplémentaire maintenue par un projet, dont la configuration est couverte sur sa page dédiée. Dans les deux cas, l'opérateur doit savoir quel projet est ciblé avant d'approuver une écriture ou le lancement d'un processus.

Gardez les paramètres du fournisseur de modèle de l'agent séparés des outils du moteur. Une connexion locale fonctionnelle ne prouve pas qu'un modèle particulier est disponible ni que l'agent prend en charge chaque fonctionnalité d'une passerelle compatible. Établissez d'abord la plus petite lecture autorisée, puis une modification de scène réversible et seulement ensuite un cycle de gameplay complet dans une expérience autorisée.

Donnez assez de contexte de scène aux échecs

Lorsqu'une interaction échoue, capturez l'arbre de scène concerné, le script, l'action d'entrée et la première erreur runtime significative. Expliquez la transition attendue et l'état observé. Un rapport indiquant que le joueur ne bouge pas doit préciser si le jeu a le focus, si l'entrée est détectée et si la position du joueur change.

Exigez une petite correction proposée avec une explication liée à ces preuves. Après application, répétez la même action et inspectez les régressions du redémarrage et des transitions de scènes. N'acceptez pas une réparation uniquement parce que l'erreur a disparu ; désactiver la fonctionnalité concernée peut supprimer une erreur tout en laissant l'exigence initiale non satisfaite.

Préparez explicitement les prérequis d'export

Un export exige un preset correspondant et des templates d'export installés. Relisez export_presets.cfg et l'inclusion des ressources avant le build. Gardez les identifiants d'export privés. Le nom de preset de l'exemple est illustratif et doit correspondre à votre projet ; le répertoire de sortie doit déjà exister.

Traitez un template ou un preset manquant comme un problème d'environnement, et non comme une preuve que la logique de jeu générée est incorrecte. Conservez les journaux d'export et le hash de l'artefact afin que les constats de plateforme cible renvoient à un build précis. Un export réussi est un point de contrôle important, mais n'établit pas que le jeu livré démarre ou termine une manche.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Exécutez un miniflow de livraison sur la cible

Lancez le jeu exporté sur le système d'exploitation que vous comptez prendre en charge. Testez le démarrage, les entrées, une manche complète, le redémarrage, les paramètres et la persistance après relance. Pour chaque résultat, conservez l'identité de l'artefact, le contexte de l'appareil et le résultat observé. Un export créé sur macOS ne vérifie pas à lui seul le comportement Windows.

Pour une cible web, inspectez aussi le chargement du navigateur et les erreurs runtime et exercez le canvas avec une entrée réelle. Vérifiez que le contenu est visible et bouge lorsque c'est attendu. Testez la configuration d'hébergement prévue au lieu de supposer qu'une exécution locale de l'éditeur couvre le chargement des ressources du navigateur et les restrictions de plateforme.

Un projet source et une capture native à inspecter

L'exemple local Switchyard fournit un puzzle Godot en trois salles, des contrôles automatisés du gameplay, des contrôles de réouverture de sauvegarde, des journaux bruts, un ZIP source et un PCK Godot. Ses captures natives montrent le projet réel en cours d'exécution à deux tailles de viewport. Répéter les commandes documentées constitue un contrôle plus solide que juger le projet sur une simple capture d'écran.

Le projet a utilisé Godot 4.5.1 lors d'un run Codex dont le modèle exact de génération n'a pas été vérifié. Il démontre donc un workflow de moteur local, et non un benchmark Astra. L'export navigateur était bloqué par des templates d'export manquants et le PCK n'est pas un exécutable Windows autonome. Ces limites sont enregistrées avec la source afin que le prochain développeur sache ce qui reste à tester.

Fermez la boucle avec un relais vérifiable

Le relais doit nommer le périmètre jouable, l'identité de la source, les versions du moteur et des templates, les instructions de build, les résultats acceptés et les défauts non résolus. Incluez des captures authentiques de l'artefact testé et la provenance des assets livrés. Conservez les tentatives de réparation et les interventions manuelles au lieu de ne présenter qu'un dump de code final généré.

Lorsque la boucle de base est acceptée, ajoutez les assets et la localisation avec leurs propres contrôles d'import et de gameplay avant d'envisager la soumission à une plateforme. Cette présentation repose sur la documentation du moteur ; appliquez-la à votre version installée et conservez les résultats réels. Gardez une courte liste de problèmes non résolus avec des étapes de reproduction afin que la prochaine session démarre depuis le même état connu.

Questions fréquentes