Développement de jeux Unity avec l'IA

Commencez par le contrat du projet existant

Identifiez l'éditeur Unity sélectionné, le chemin du projet, la plateforme cible, les paquets et la configuration du rendu avant de donner à un agent un accès en écriture. Conservez la version du projet et les verrous de dépendances dans le registre de l'expérience. Confirmez que l'opérateur dispose de l'accès à l'éditeur et des modules cibles requis ; l'accès au modèle ne fournit pas ces prérequis.

Définissez une petite scène jouable selon les conventions établies du projet. Si l'équipe possède déjà un contrôleur de personnage ou une abstraction d'entrée, demandez à l'agent de l'inspecter avant de proposer un remplacement. Les changements générés seront ainsi vérifiables et un prototype apparemment isolé ne contournera pas les systèmes dont dépend le reste du jeu.

Traitez l'automatisation de l'éditeur comme une connexion séparée

Le projet Unity MCP de CoplayDev expose des opérations de l'éditeur à des clients compatibles. Son guide d'installation décrit un paquet éditeur et une connexion serveur. Le service de modèle de l'agent est séparé : changer les identifiants du modèle ne réparera pas une instance d'éditeur indisponible.

Commencez par une inspection du projet en lecture seule et confirmez quelle instance ouverte reçoit la requête. Limitez les approbations de mutation à une scène jetable ou à une fonctionnalité explicitement détenue. Le succès renvoyé par un outil signifie que l'opération s'est terminée à sa propre frontière ; la scène obtenue peut encore avoir des références incorrectes ou échouer pendant le jeu. Le guide MCP dédié couvre les contrôles de connexion et l'enregistrement des versions.

Demandez des changements délimités aux résultats visibles

Demandez un ajustement de contrôleur, une transition de menu ou une petite fonction de persistance plutôt que la réécriture d'une scène entière après chaque échec. Indiquez ce que le joueur doit faire, quel état doit changer et comment le résultat sera observé. Préservez l'état fonctionnel précédent avant d'accepter des modifications générées.

Utilisez le brief illustratif ci-dessous pour définir une modification limitée et ses critères de revue. Pour les scènes et prefabs, inspectez les références d'objets et l'état sauvegardé ainsi que les diffs de scripts ; un fichier source peut ne pas contenir la configuration qui détermine le gameplay. Demandez à l'agent d'identifier les objets concernés avant de les modifier.

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

Attendez la compilation avant d'interpréter les résultats de jeu

Séparez la compilation du code, la disponibilité de l'éditeur et le gameplay dans le journal d'observation. Si la compilation échoue, capturez la première erreur pertinente et le contexte du code modifié. Ne demandez pas d'ajuster les déplacements lorsque l'éditeur ne peut pas charger les scripts prévus ; cela crée d'autres modifications sur une base invalide.

Après la compilation, vérifiez les composants et références attendus avant d'entrer en mode jeu. Reproduisez la même action du joueur après une correction. Une console sans erreur est une preuve utile, mais le jeu doit encore atteindre l'état prévu. Des changements répétés qui ne modifient pas le symptôme doivent déclencher une reproduction plus petite plutôt qu'un remplacement plus large.

Utilisez délibérément le framework de tests du projet

Unity Test Framework documente la sélection des tests en ligne de commande et la sortie des résultats. L'exemple suppose que le framework est déjà configuré et que le répertoire de résultats existe. UNITY_BIN et PROJECT sont des variables shell illustratives pointant vers l'éditeur et le projet existants. Faites correspondre la documentation de référence à votre paquet installé.

Exécutez les contrôles EditMode pour la logique isolée adaptée et les contrôles PlayMode pour le comportement nécessitant une exécution. Ces catégories ne remplacent pas la revue pratique des contrôles et de la présentation. Gardez le nombre de tests, les échecs et les fichiers de résultats avec la révision testée. Une exécution qui ne découvre aucun test ne peut pas établir que le jeu passe.

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

Relisez les entrées du build avant de produire un player

Un build doit utiliser la sélection de scènes et la configuration cible relues du projet. Ne supposez pas que la scène actuellement ouverte dans l'éditeur est celle incluse au démarrage. Conservez l'identité du build et les journaux afin de relier les échecs ultérieurs à l'artefact exact.

Le CLI Unity permet d'appeler une méthode d'éditeur statique existante via -executeMethod. Ce flag ne crée pas une implémentation de build : le projet doit posséder une vraie méthode avec un comportement de build et une gestion des échecs explicites. Préférez le point d'entrée de build existant de l'équipe à des méthodes d'exemple inventées qui semblent exécutables mais n'existent pas dans le projet.

Validez le gameplay en dehors de l'éditeur

Testez le player livré sur le système d'exploitation déclaré avec les contrôles attendus et un état de départ propre. Entrez depuis le premier écran, terminez une manche, redémarrez, modifiez les paramètres et relancez. Comparez la persistance et les transitions au brief d'acceptation au lieu de vérifier seulement l'ouverture d'une fenêtre.

Enregistrez des captures authentiques et une courte séquence pilotée par des entrées depuis cet artefact. Si l'exécution de l'éditeur réussit mais le build échoue, inspectez l'inclusion des scènes, les dépendances de ressources et le comportement propre à la plateforme avant de demander à l'agent de réécrire le gameplay central. La frontière qui a changé est un indice utile de la cause.

Suivez le travail humain et les dépendances non résolues

Conservez les modifications manuelles de l'inspecteur, les retouches d'assets, les instructions ajoutées et les réparations d'environnement dans le registre des interventions. Elles font partie de l'effort de production même si elles ne génèrent aucune utilisation de modèle. Distinguez les appels de codage textuel de la génération d'images, du travail moteur et des tests sur l'appareil cible lors de la revue des coûts.

Ce parcours fondé sur la documentation doit être validé avec les versions choisies de l'éditeur et des paquets. Gardez dans le relais le plus petit workflow complet : connexion, modification, compilation, jeu et export. Lorsqu'un autre développeur peut le répéter, utilisez cette base pour la prochaine fonctionnalité et revoyez le contrôle chaque fois qu'une dépendance ou une cible de build change.

Questions fréquentes