Développement de jeu avec Astra : Circuit Shift

Le résultat : une boucle de gameplay complète en trois salles

Circuit Shift est un petit jeu de puzzle vu du dessus construit et testé dans Godot 4.5.1 sur macOS. Vous guidez le coursier CS-07 à travers trois salles de stations de relais, récupérez trois cellules d'énergie dans chaque salle, ouvrez des portes numérotées, évitez les sentinelles mobiles et atteignez la sortie. L'exécution native automatisée finale a terminé les trois salles, exercé la défaite et le redémarrage et sauvegardé la progression de campagne ainsi que les meilleurs temps. Un processus séparé a rouvert cette sauvegarde avec succès.

Pour un projet de jeu assisté par l'IA, l'enseignement utile tient à la combinaison d'un brief délimité, de contrôles de gameplay pilotés par le moteur et d'une inspection visuelle. Demander une petite boucle complète a permis de tester plus que le déplacement : la sortie devait rester scellée avant la collecte, la fin d'une salle devait débloquer le secteur suivant et les paramètres devaient survivre à une relance. Le projet téléchargeable vous permet d'inspecter vous-même ces comportements.

Le brief initial rendait l'achèvement concret

La tâche spécifiait un jeu original nommé Circuit Shift, trois niveaux courts, la physique du moteur, des interrupteurs et des portes, des cellules à collecter, la victoire/défaite/redémarrage, un menu de démarrage, des paramètres et une progression sauvegardée. Elle exigeait aussi de vraies captures d'écran, un miniflow de gameplay dans le vrai moteur et une réouverture de l'état sauvegardé. Godot 4.5.1 était déjà installé et a été réutilisé ; le développement a commencé dans un nouveau répertoire de jeu avec un HOME temporaire séparé.

L'extrait ci-dessous vient du brief initial réel ; des sauts de ligne ont été ajoutés pour la lisibilité et sa formulation originale est conservée. Le fichier complet initial-prompt.txt est inclus dans le ZIP source. Pour votre propre brief, la partie la plus transférable est le critère d'achèvement observable : précisez ce que le joueur peut faire et ce qui doit encore fonctionner après la fermeture du jeu.

Task: build an original polished small 2D Godot game called Circuit Shift.
Three short levels; controllable character, enginephysics/collisions,
switches and gates, collectible cells, exit, win/loss/restart,
start menu, smallsettings and savedprogress.

Du prompt aux fichiers, au feedback du moteur et aux salles fonctionnelles

L'agent a écrit les données des salles, le GDScript, les menus, les paramètres, les sauvegardes locales et un harnais de gameplay, puis a exécuté le moteur à plusieurs reprises et inspecté les résultats. Le déplacement utilise CharacterBody2D.move_and_slide ; les murs et portes utilisent StaticBody2D ; les cellules, dangers et sorties utilisent des déclencheurs Area2D. Ces contrats du moteur relient la salle visible aux collisions et changements d'état que le harnais peut observer.

Le dossier contient 13 exécutions du moteur de jeu couvrant l'import, le gameplay, les régressions, les captures natives, la réouverture, le packaging et l'inspection des pixels. La séquence comprenait un échec initial de présence de scène avant l'implémentation, le gameplay headless, les captures natives, une réparation visuelle ciblée et les contrôles finaux des artefacts. Les éléments graphiques propres au jeu ont été dessinés procéduralement avec du code Godot CanvasItem et cinq effets sonores PCM ont été synthétisés localement. Le travail observé comprenait des patches écrits par l'agent, des commandes locales, des demandes d'autorisation d'exécution native et l'inspection de captures ; aucune orientation supplémentaire de tâche ni réparation de code humaine n'a été observée.

Le vrai défaut : le focus clavier rendait un bouton difficile à lire

La première exécution native du gameplay a réussi ses assertions, mais l'inspection des captures a révélé un texte à faible contraste sur un bouton principal sélectionné. Cela comptait car le menu de station prend aussi en charge la navigation au clavier : une action de démarrage fonctionnelle ne garantissait pas un contrôle de démarrage lisible. Un contrôle de régression ciblé a alors échoué avec un rapport de contraste d'environ 1.36:1.

La réparation a défini explicitement font_focus_color sur la couleur de premier plan sombre du bouton principal. Le contrôle suivant a mesuré environ 10.57:1 et l'exécution native finale a conservé l'assertion de contraste réussie. Les sorties brute échouée et réussie restent dans le répertoire de preuves. C'est une raison concrète d'associer les tests de gameplay à l'inspection des états d'interface focalisés et sélectionnés : les transitions d'état peuvent être correctes tandis que les contrôles qui les exposent nécessitent encore du travail.

Ce que les tests natifs ont réellement exercé

Le miniflow final de gameplay a piloté les actions Godot Input normales et les signaux Control natifs ; un contrôle de mapping a envoyé un InputEventKey. Le coursier s'est déplacé via la physique du moteur. Le harnais a vérifié la collision avec les murs, le blocage par les portes fermées, l'ouverture et la fermeture des relais, l'exigence de sortie après collecte de toutes les cellules, les victoires dans les trois salles, la défaite causée par un danger, le redémarrage, la pause, les paramètres et les déclencheurs de génération/lecture des sons. Il n'a pas téléporté le joueur, attribué directement des cellules ni fixé un état de victoire.

Les nombres ci-dessous sont des assertions à l'intérieur de ces flux, y compris les waypoints et captures, et non des tâches de benchmark indépendantes. Les trois exécutions natives finales se sont terminées avec succès et un stderr vide. Le gameplay de la campagne source est le test le plus large ; l'exécution PCK établit le chargement du paquet et la continuation de la sauvegarde, et non une seconde campagne complète dans le jeu empaqueté.

La réouverture a testé la persistance et la mise en page compacte

Un nouveau processus natif a chargé unlocked=3, completed=true, trois meilleurs temps positifs, volume=0.35 et reduced_motion=true. Continue est entré dans le secteur trois. Cela sépare la persistance d'une valeur qui resterait simplement en mémoire pendant l'exécution du jeu. Le jeu sauvegarde la progression à la fin d'une salle ; le point de reprise prévu est donc une salle, et non la dernière position du coursier.

L'exécution compacte a aussi fourni un second contrôle de mise en page : la salle, le HUD, le minuteur et les contrôles restaient entièrement cadrés en 720 x 540. Les captures desktop sont en 1280 x 960. Sur les exécutions finales source et paquet, douze captures natives ont réussi l'échantillonnage de pixels non vides et l'inspection visuelle a vérifié le cadrage et la lisibilité. Il s'agit de véritables captures de viewport natif ; la plus petite image montre une fenêtre desktop compacte.

Chronologie et configuration : lire le registre d'exécution

Le démarrage demandé était le 5 septembre 2026 à 05:35:51 UTC ; la fin a été enregistrée à 06:00:11.007 UTC. Cela représente 1,460.007 secondes, soit environ 24 minutes 20 secondes de temps écoulé. Cette durée couvre l'implémentation, l'exécution des outils, les tests, les réparations, les captures et le packaging avec un moteur déjà disponible. Il ne s'agit ni de la latence de réponse du modèle ni d'une prévision pour le temps de développement d'un autre jeu. Une seule consigne initiale a conduit à plusieurs itérations d'implémentation et d'outils.

Il s'agit d'une exécution Codex configurée avec Astra : le coordinateur a enregistré spawn_agent.model=gpt-6-astra avec reasoning_effort=xhigh. Cela établit uniquement la configuration demandée. L'identité du modèle de réponse API, l'utilisation des tokens, le coût et le nombre d'appels modèle/API n'ont pas été exposés et restent null dans run-summary.json ; aucune requête directe APIsRouter ni facturation n'a été observée. Le contrôle du catalogue public du 5 septembre n'a pas non plus trouvé Astra sur APIsRouter. La documentation officielle du modèle et cette configuration locale n'établissent pas l'accès à la passerelle.

Téléchargez et exécutez Circuit Shift dans Godot

Téléchargez le ZIP source pour inspecter l'implémentation, le brief complet, les contrôles, le harnais de test et les preuves conservées. Extrayez-le, importez game/project.godot dans Godot 4.5.1 et exécutez le projet. Déplacez-vous avec WASD ou les touches fléchées, utilisez un relais proche avec E ou Espace, redémarrez avec R et mettez en pause avec Échap. Collectez chaque cellule pour activer la sortie ; le contact avec une sentinelle met fin à la tentative.

Pour la version empaquetée, téléchargez circuit-shift.pck et lancez-le avec un runtime Godot compatible à l'aide de la commande ci-dessous. Le PCK nécessite Godot et n'est pas un exécutable autonome. L'intégrité du ZIP, l'égalité des fichiers archivés critiques, l'égalité de la source avec l'exécution native finale et l'égalité SHA-256 des assets copiés ont été vérifiées. Le PCK a été lancé depuis un répertoire temporaire hors du projet source. Les liens de téléchargement des deux artefacts, de run-summary.json et du manifeste SHA-256 sont listés ci-dessous.

godot --main-pack circuit-shift.pck

Ce que ce prototype peut faire ensuite

L'étape suivante utile est un playtest humain de la boucle en trois salles : un nouveau joueur comprend-il la numérotation des relais, remarque-t-il pourquoi la sortie est scellée et sait-il repartir après une défaite ? Aucun playtest humain, test d'écoute ni donnée d'utilisation réelle n'a été collecté dans ce cas. L'achèvement automatisé et les buffers audio générés établissent des chemins fonctionnels ; ils n'établissent ni le plaisir, ni l'équilibre de difficulté, ni la qualité sonore, ni la rétention, ni l'utilisabilité générale.

Windows, navigateur, Steam, tactile et manette restent non testés ; les templates d'export navigateur étaient indisponibles localement. Les exécutions headless accélérées ont encore émis des diagnostics de certificats macOS et des avertissements d'arrêt de ressources audio, même si les journaux natifs finaux avaient un stderr vide. Avant de choisir une cible de sortie, traitez les problèmes runtime pertinents et exécutez les contrôles propres à cette cible sur les entrées, la sauvegarde, le packaging et les performances. Le résultat pratique est ici un prototype natif inspectable et un workflow de vérification répétable pour guider le prochain cycle de développement.

Questions fréquentes