Développement de jeux par l'IA

Commencez par une petite boucle de jeu complète

Une première cible utile est une activité unique dont le début et la fin sont observables : commencer une manche, se déplacer ou choisir, rencontrer un défi, gagner ou perdre, puis redémarrer. Précisez ce que voit le joueur à chaque transition avant de demander à un agent d'écrire des fichiers. Un écran-titre soigné ne permet pas d'établir que la boucle fonctionne.

Choisissez une plateforme cible et un petit ensemble de périphériques d'entrée. Considérez les niveaux supplémentaires, le réseau et le contenu procédural comme un périmètre ultérieur. Un prototype échoué reste ainsi diagnostiquable : vous pouvez distinguer une règle de collision cassée d'une fonctionnalité inachevée au lieu d'élargir sans cesse le prompt.

Choisissez le workflow, puis le moteur

Pour un petit projet 2D original, commencez par évaluer le CLI documenté de Godot pour une boucle inspecter-modifier-exécuter. Unity est un bon point de départ lorsqu'un projet existant ou une équipe dépend déjà de son workflow d'éditeur. Votre capacité à maintenir le résultat doit guider le choix autant que le premier prototype.

Comparez le travail nécessaire pour reproduire un échec sur votre machine. Le meilleur point de départ est celui dont vous pouvez expliquer la structure du projet, les prérequis de build et les erreurs. Un agent ne supprime pas la responsabilité des mises à niveau du moteur ni des paquets tiers.

Gardez l'accès au modèle séparé des outils du moteur

L'agent possède deux connexions différentes : un service de modèle qui produit le raisonnement et les modifications, et des outils locaux qui inspectent ou pilotent le projet. Godot MCP et Unity MCP appartiennent au côté outils. Installer l'un ou l'autre ne choisit pas un fournisseur de modèle et ne prouve pas une intégration de passerelle.

Choisissez la connexion au modèle dans votre client d'agent et la connexion au moteur dans ses paramètres d'outils. Vérifiez chacune indépendamment avec une petite opération. Lorsqu'un chemin de projet local est incorrect, corrigez ce chemin ; changer l'endpoint du modèle ne fera pas apparaître la scène attendue.

Rendez le premier brief testable

Nommez les scènes requises, les actions du joueur, les transitions d'état et le comportement de persistance. Demandez l'implémentation la plus petite qui satisfasse ces exigences ainsi qu'une liste explicite des décisions non résolues. Utilisez le brief illustratif ci-dessous comme point de départ et remplacez son périmètre par le jeu que vous voulez réellement.

Enregistrez le brief initial sans le modifier. Lorsque vous ajoutez une exigence, étiquetez-la comme changement de périmètre. Lorsque vous expliquez un échec ou modifiez vous-même un fichier, étiquetez-le comme intervention. Cela préserve la différence entre un prompt initial et les nombreuses itérations de modèle et d'outils qui peuvent suivre.

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

Travaillez par changements vérifiables

Après le scaffold initial, demandez un comportement à la fois : le déplacement, puis la collision, puis la transition de fin de manche. Relisez les fichiers modifiés et exécutez le même parcours d'acceptation après chaque changement. Préservez un état connu comme fonctionnel avant d'ajouter des paquets externes ou de modifier les paramètres d'import.

Un agent doit recevoir l'erreur pertinente, le contexte de la scène et le comportement observé, pas seulement une demande de faire davantage d'efforts. Lorsque le même symptôme survit à des modifications répétées, arrêtez-vous et isolez la frontière. Une ressource importée manquante et une référence de nœud erronée nécessitent des corrections différentes, même si toutes deux produisent une scène vide.

Traitez les assets et la localisation comme des entrées de production

Conservez un manifeste d'assets avec la source, l'autorisation, l'identité de l'auteur ou de l'outil, les modifications et l'usage prévu. Relisez les sprites à l'échelle du gameplay, notamment la transparence, l'alignement des frames, le contraste et l'adéquation des collisions. Une image plausible n'est pas automatiquement une sprite sheet utilisable.

Rendez les chaînes visibles par le joueur adressables par des identifiants stables. Fournissez le contexte de traduction et protégez les arguments de formatage. Les images, l'audio, les polices et le texte traduit nécessitent chacun une revue avant distribution. Enregistrez séparément les dépenses de génération d'images et le travail de codage par modèle textuel ; ni une licence d'asset ni une licence de moteur n'établit les droits sur tous les fichiers d'un projet.

Prouvez séparément chaque état de livraison

Une démo jouable exige qu'une personne termine la boucle prévue. Un export exige un artefact généré. Un export testé exige en plus le lancement de cet artefact sur sa plateforme cible. La soumission et la sortie Steam sont des états ultérieurs de la plateforme. Utilisez ces libellés avec précision lorsque vous partagez l'avancement.

Conservez l'identité du build, les entrées de test, les captures du jeu réel et les échecs qui subsistent. Une capture de navigateur doit montrer un gameplay qui change après une entrée, et pas seulement un écran de chargement. Un exécutable Windows exporté sur un autre système d'exploitation doit tout de même être vérifié sous Windows. Consultez le guide Steam pour ses exigences distinctes en matière de compte et de planification.

Ce que l'exemple Playco montre du workflow

Le récit client d'OpenAI du 3 septembre 2026 décrit Playco utilisant Astra dans Playbot, un IDE connecté à des moteurs de jeu. L'équipe a itéré sur une base grey-box avant de produire des prototypes thématisés. Il s'agit d'un témoignage client publié par le fournisseur, et non d'un benchmark APIsRouter.

L'enseignement pratique porte sur la forme du workflow : établir les mécaniques jouables, puis varier la présentation tout en conservant une base commune. Gardez les préférences créatives séparées des corrections de défauts afin de voir ce que chaque itération a réellement accompli. Lisez le récit original pour ses résultats rapportés au lieu de les traiter comme une prévision pour votre propre jeu.

Inspectez un prototype Godot local

Switchyard est un petit puzzle de circuits en trois salles produit lors d'une exécution locale de développement Codex. Le projet source comprend le déplacement du personnage, les interrupteurs, les portes, les cellules à collecter, la fin de salle, la défaite et le redémarrage, les paramètres ainsi que la progression persistée. Des contrôles automatisés du moteur ont exercé la boucle de gameplay et un processus distinct a rouvert la sauvegarde. La capture ci-dessous est une véritable capture du viewport Godot, et non une illustration conceptuelle.

L'exécution enregistrée utilisait Godot 4.5.1. Son identité de modèle et sa facturation API n'étaient pas observables ; elle n'est donc pas présentée comme un benchmark de performance ou de coût Astra. Les sources et le PCK téléchargeables démontrent le projet local ; le PCK nécessite Godot. Un build Windows autonome, un export navigateur, un playtest humain et une sortie Steam restent des travaux distincts. Cet exemple montre les artefacts concrets à demander à un agent avant d'avancer une affirmation de livraison.

Choisissez le prochain guide selon votre goulot d'étranglement

Commencez par la sélection du moteur si votre environnement n'est pas arrêté, par les pages de configuration MCP si la découverte des outils échoue, ou par le guide de débogage si le projet s'ouvre mais se comporte mal. Utilisez le guide des coûts lorsque les réparations répétées dominent les dépenses ; réduire le périmètre peut compter davantage que changer de modèle.

Ces guides fournissent des workflows appuyés par des sources et des exemples illustratifs, et non un classement mesuré des moteurs. L'expérience Astra liée explique les preuves nécessaires à son cas précis. Pour votre projet, choisissez l'étape suivante qui résout un blocage concret et préservez son résultat avant d'étendre le jeu.

Questions fréquentes