Slay the GBA : 100 % codé par des agents autonomes sous Claude Opus 5.5

Journal de bord & Making-of d'un demake Game Boy Advance en C++20 Dernière mise à jour : Version 0.50.0 — 50,1 % du contenu de Slay the Spire 2 implémenté.

Je joue à Slay the Spire 2. Beaucoup. Et comme beaucoup de passionnés de jeux rétro, un fantasme me trottait dans la tête depuis l'annonce du jeu : pouvoir y jouer sur une vraie console portable des années 2000, calé dans le métro ou sur un canapé, avec les boutons rigides et la croix directionnelle d'une Game Boy Advance sous le pouce.

Mais ce projet n'est pas un simple portage amateur de plus. C'est le laboratoire d'une expérience radicale d'ingénierie logicielle :

Règle absolue : 0 ligne de C++ écrite par l'homme. 100 % du code du jeu, du moteur de règles, des tests unitaires, des pipelines d'assets et de la documentation est conçu, implémenté et testé par des agents autonomes propulsés par Claude Opus 5.5.

Mon rôle dans cette histoire ? Je ne touche pas au code. Je ne résous pas de bugs de pointeurs ni de segfaults. Je lance des sessions d'agents autonomes de 5 heures, et je ne passe que 5 minutes par session pour superviser la trajectoire globale et vérifier les Pull Requests.

Voici l'histoire sans fard de ce projet : des déboires du "vibe coding" naïf jusqu'à la mise en place d'une véritable chaîne de production agentique autonome capable de compiler 5 cartouches GBA complètes.

Écran titre de Slay the GBA — L'écran titre officiel de Slay the GBA, affiché en 240x160 sur la key-art originale

🎮 Le terrain de jeu : 240×160 pixels et 16 couleurs

Pour ceux qui n'ont jamais codé sur console rétro : la Game Boy Advance est un univers impitoyable. On est aux antipodes du développement web moderne :

Résolution : 240 × 160 pixels (ratio 3:2).
Graphismes : Sprites de dimensions matérielles strictes (8×8, 16×16, 32×32, 64×64, ou rectangles 32×8...), palettes indexées de 16 couleurs par sprite, 128 sprites maximum à l'écran.
Mémoire vive : 32 Ko d'IWRAM ultra-rapide et 256 Ko d'EWRAM. Si vos structures de données saturent la RAM, la pile d'exécution s'effondre et la console freeze au boot.
La Stack technique :
C++20 moderne avec Butano, un moteur GBA remarquable conçu par Gustavo Valiente.
devkitARM encapsulé dans Docker pour une compilation croisée reproductible.
Un moteur de règles agnostique du hardware, compilable en natif sur Mac et Linux pour faire tourner des suites de tests à la vitesse de l'éclair.
Cinq cartouches ROM distinctes (.gba) : une par héros (Soldat de Fer, La Silencieuse, Le Défectueux, Le Régent, La Nécrolieuse).

📚 La Genèse : Une "Bible" scrapée comme cahier des charges

Avant même d'écrire la moindre ligne de combat, les agents avaient besoin d'une source de vérité absolue. Pas question de laisser l'IA halluciner les dégâts d'une carte ou le coût en énergie d'un pouvoir.

Un premier agent a scrapé l'intégralité des données du patch bêta de Slay the Spire 2 pour constituer une véritable encyclopédie interne :

25 tomes d'archives documentant le lore, les règles et les interfaces.
Des bases de données JSON exhaustives référençant 569 cartes, 298 reliques, 111 monstres, les potions et tous les évènements de la Tour.
Des livrets d'instructions rétro générés automatiquement pour chaque cartouche, reprenant le format et la mise en page des notices Nintendo de l'époque.

Cette bible est le contrat d'interface des agents. Quand un agent prend en charge l'implémentation d'une carte ou d'un monstre, il ne devine rien : il lit la spécification exacte, ses statuts associés et ses illustrations sources.

😵 L'illusion du "Vibe Coding" naïf : Le mur du bas-niveau

Tout le monde parle de "vibe coder" des applications en discutant gentiment avec une IA. J'ai commencé ce projet avec cette approche naïve, en utilisant Gemini.

Le résultat a été un désastre technique instructif :

Le crash UTF-8 immédiat :

Dès la première frame du combat, la console s'arrêtait net sur un écran rouge d'erreur Butano. Le coupable ? Une simple flèche décorative dans l'UI :

   cps << ((frame_count / 10) % 2 == 0 ? "▲ " : "► ")

La police par défaut de Butano ne supporte que l'ASCII strict et quelques caractères espagnols. Un caractère UTF-8 non mappé, et le moteur panique. Même problème pour tous les accents français (« Élite », « Événement »). L'IA affirmait que tout marchait à la perfection, alors que la ROM ne démarrait même pas.

Crash UTF-8 au lancement du combat — Écran d'erreur Butano à cause d'un caractère non supporté

La double attaque fantôme :

Dans le code généré, les ennemis attaquaient deux fois par tour. Pourquoi ? Parce que le moteur de jeu exécutait le tour ennemi dans end_player_turn(), et que l'interface graphique le relançait une seconde fois avec execute_enemy_turn().

Le sprite impossible :

L'IA essayait de déclarer des barres de vie de 64×8 pixels. Problème : ce format n'existe pas dans le hardware GBA. La console exigeait de découper chaque barre en deux sprites distincts de 32×8 juxtaposés.

Le constat était limpide : le vibe coding sans harnais de test et sans boucle de rétroaction autonome est une impasse sur les systèmes contraints.

🤯 Le saut quantique : Claude Opus 5.5 & L'Armature Agentique

Le tournant du projet s'est produit en basculant sur Claude Opus 5.5 et en transformant la relation avec l'IA. Au lieu de lui demander de "coder une feature", je lui ai donné les pleins pouvoirs pour bâtir son propre environnement d'ingénierie et de vérification.

Ce qui s'est passé ensuite a dépassé toutes mes attentes :

1. Un émulateur GBA headless pour vérifier son propre travail

Pour ne plus jamais être aveugle face aux crashs graphiques, l'agent a configuré un émulateur mGBA headless dans un conteneur avec un utilitaire C dédié. L'agent peut désormais :

Compiler la ROM.
Lancer le jeu sans interface graphique.
Injecter des séquences d'appuis sur les boutons (A, B, D-Pad, Start).
Capturer des captures d'écran pixel-perfect de la mémoire vidéo pour vérifier visuellement le rendu des cartes et des arènes !

2. La chaîne de traitement graphique 16 couleurs

L'agent a conçu en Python une suite complète de conversion d'images :

Conversion des illustrations originales 4K en formats GBA.
Réduction en palettes de 16 couleurs avec tramage spatial adaptatif (spatial_aq).
Recomposition pixel par pixel d'une police française complète supportant accents, cédilles et glyphes de cartes (♥, ★, ●).

Arène de combat avec la main de cartes — L'arène de combat : Soldat de Fer face au monstre, intentions visibles et cartes illustrées

🛡️ Les Garde-Fous : Comment tourner 5 heures en autonomie sans tout casser

Comment est-il possible de laisser des agents coder pendant 5 heures d'affilée sans surveillance humaine sans que le projet ne dérive dans le chaos ? Grâce à une batterie de garde-fous stricts et automatisés :

flowchart TD
    A["Agent Claude Opus 5.5"] --> B["Écriture C++20 & Assets"]
    B --> C["Banc de tests natifs (Moteur & E2E)"]
    C --> D["Analyseur d'empreinte mémoire (RAM GBA)"]
    D --> E["Vérificateur typographique (Largeurs de textes)"]
    E --> F["Émulateur mGBA Headless (Validation visuelle)"]
    F --> G["Commit Conventionnel & Pull Request"]
    G --> H["CI/CD GitHub Actions & Déploiement Netlify"]

La séparation moteur / interface :

Toutes les règles du jeu (calcul des dégâts, vulnérabilité, force, pioche, défausse, artefacts, blocage) sont regroupées dans un moteur C++ pur sans dépendance graphique. Ce moteur est compilé et testé en natif sur Mac à chaque modification.

Le simulateur de combats massifs déterministe :

Les agents lancent des milliers de combats aléatoires avec des seeds fixées pour s'assurer qu'aucune combinaison de cartes ou de reliques ne provoque de boucle infinie ou de division par zéro.

Le gardien de l'empreinte mémoire (RAM & ROM) :

Avant d'autoriser la publication d'une cartouche, un outil d'inspection analyse les sections mémoire du binaire compilé (.text, .rodata, .bss, .data). Il calcule l'espace restant exact en RAM pour la pile d'exécution (stack) et bloque immédiatement la chaîne si la marge de sécurité de la console devient insuffisante.

Le banc de test typographique et de calage d'interface :

Chaque nom et description de carte est mesuré au pixel près par rapport aux glyphes de la police pour garantir qu'aucun texte ne déborde de son encart sur l'écran 240×160.

⚔️ Le Système de Combat : Pokémon croisé avec Slay the Spire

Sur console portable, la clarté visuelle est essentielle. L'interface a été conçue pour combiner l'efficacité de Slay the Spire avec le charme nostalgique des combats Pokémon sur Game Boy Advance :

Disposition scénique : Le héros est visible de dos sur la gauche de l'arène, tandis que les ennemis se dressent sur leurs socles à droite.
Affichage des intentions : Au-dessus de chaque monstre, des icônes explicites indiquent l'action prévue pour le tour suivant (Attaque + montant des dégâts, Armure, Malus, Renforcement).
Cartes animées : Quand une carte est sélectionnée, elle s'agrandit au centre de l'écran avant de s'élancer vers sa cible dans une gerbe d'étincelles avec secousse d'écran (screenshake).
Feedback d'impact : Barres de PV dynamiques avec transition de couleur vert → jaune → rouge, chiffres de dégâts flottants et effet de mosaïque Butano lors de la mort d'un ennemi.

La carte jouée s'agrandit avant l'impact — Animation de zoom et projection de la carte

Impact et dégâts flottants — Impact visuel et chiffres de dégâts flottants

🏛️ L'Architecture Multi-Cartouches

Pourquoi cinq cartouches .gba distinctes plutôt qu'un seul jeu monolithique ?

Une cartouche Game Boy Advance physique a une limite matérielle de 32 Mo, et la mémoire Butano dédiée aux graphismes ne peut pas stocker simultanément les centaines de sprites et d'arènes de tous les personnages du jeu.

L'équipe d'agents a donc adopté la tradition des cartouches Game Boy (comme Pokémon Rouge et Bleu) : une cartouche par héros !

Édition	Héros	Couleur dominante	Mécanique clé	État d'avancement
🔴 Ironclad	Soldat de Fer	Rouge sang	Force, Auto-blessure, Épuisement	89,7 % (78 cartes sur 86, 91 éléments)
🟢 Silent	La Silencieuse	Vert poison	Surins (Shivs), Poison, Pioche massive	81,7 % (71 cartes sur 86, 82 éléments)
🔵 Defect	Le Défectueux	Bleu néon	Orbes (Foudre, Givre, Plasma), Focus	92,9 % (80 cartes sur 86, 97 éléments)
🟠 Regent	Le Régent	Or / Cuivre	Souveraineté, Armes royales	67,5 % (59 cartes sur 86, 67 éléments)
🟣 Necrobinder	La Nécrolieuse	Violet spectral	Âmes, Invocation d'alliés, Maudits	62,9 % (54 cartes sur 86, 62 éléments)

Toutes les cartouches partagent le même moteur de combat, le même bestiaire, la même carte de la Tour (16 étages avec scrolling fluide) et les mêmes feux de camp, mais chacune possède son propre écran titre, son orbe d'énergie et sa bande-son personnalisée.

Combat avec le Défectueux — L'arène du Défectueux avec ses orbes élémentaires et ses cartes dédiées

📜 Le Journal de Bord des Agents (Devlog Vivant)

Ce projet évolue constamment grâce aux cycles de développement des agents. Voici les grandes étapes franchies et l'état d'avancement actuel du portage :

timeline
    title L'Épopée de Slay the GBA
    section Phase 1
        v0.10.0 : Prototype initial : Moteur de base, Soldat de Fer jouable, premiers combats
        v0.20.0 : Bible & Assets : Intégration de la bible STS2, conversion des 569 cartes en 16 couleurs
    section Phase 2
        v0.30.0 : Les 5 Cartouches : Découpage en 5 ROMs indépendantes, support de la Silencieuse et du Défectueux
        v0.40.0 : Systèmes de Survie : Carte de la Tour à 16 étages, boutiques, forges, sauvegarde SRAM
    section Phase 3
        v0.45.0 : Profondeur Tactique : 536 éléments validés, 342 cartes héros, 29 reliques, 28 potions, boss Cerf Auguste

📊 Tableau de Bord Actuel (Version 0.50.0)

L'avancement n'est pas une estimation subjective : il est calculé automatiquement à chaque compilation par un outil d'audit interne, qui inspecte les symboles du code C++ et les compare à la bible de données Slay the Spire 2.

Avancement Global : 50,1 %
Total des éléments : 536 validés, 54 partiels, 653 en attente (36 hors périmètre multijoueur).
Détail par domaine :
🔵 Le Défectueux : 92,9 % (80 cartes sur 86 faites, 97 éléments avec orbes et focus)
🔴 Soldat de Fer : 89,7 % (78 cartes sur 86 faites, 91 éléments avec mécaniques)
🟢 La Silencieuse : 81,7 % (71 cartes sur 86 faites, 82 éléments avec surins et poison)
🟠 Le Régent : 67,5 % (59 cartes sur 86 faites, 67 éléments avec armes royales)
🟣 La Nécrolieuse : 62,9 % (54 cartes sur 86 faites, 62 éléments avec invocations et âmes)
⚔️ Règles de combat : 54,4 % (30 règles validées : calculs de dégâts, vulnérabilité, artefacts, boucliers)
⚙️ Systèmes de jeu : 55,6 % (19 systèmes : sauvegarde SRAM physique, carte 16 étages, forges, boutiques)
🎨 Interface, audio & cartouches : 58,1 % (15 validés : écrans titres, musiques, palettes)
🧪 Reliques & Potions : 22,6 % (56 validés : 29 reliques actives sur hooks d'événements, 28 potions)
👹 Bestiaire : 8,2 % (8 monstres complets avec IA de combat et le boss de l'Acte 1, le Cerf Auguste)

📦 Les Derniers Sprints des Agents (PRs récentes)

PR #302 (fix(engine)) : Correction des buffs ennemis, résolution des emballements de Fiend Fire, recalibrage de la capacité des pouvoirs (64 entrées) et ajout des reliques manquantes.
PR #301 (feat(potions)) : Implémentation et raccordement de 28 potions de combat supplémentaires au moteur.
PR #300 (feat(engine)) : Intégration de 8 monstres supplémentaires jouables immédiatement par l'IA.
PR #299 (feat(relics)) : Câblage de 29 reliques sur les hooks d'événements du moteur de combat.
PR #298 (feat(engine)) : Sélection dynamique des cartes dans la pioche et la défausse avec écran d'inspection dédié.

🚀 L'Usine Logicielle : De l'Agent au Déploiement Netlify

Le cycle de vie d'une fonctionnalité est 100 % automatisé grâce à GitHub Actions :

L'agent autonome développe une fonctionnalité sur une branche dédiée, valide les tests et ouvre une Pull Request documentée avec Conventional Commits.
Les tests natifs, les tests de scripts et le check mémoire GBA s'exécutent en CI.
À la fusion (merge) sur la branche main :

Le système d'audit interne calcule automatiquement le nouveau pourcentage d'avancement et dérive le nouveau tag de version (ex: v0.45.0).
Le compilateur cross-platform devkitARM recompile les 5 ROMs GBA.
Le site web encyclopédie et la page avancement.html sont régénérés avec les données fraîches.
Les 5 cartouches .gba sont packagées et mises à disposition en téléchargement direct.
Le webhook Netlify déploie le site mis à jour en quelques secondes.

🎯 Ce que cette expérience m'a appris

Il y a deux ans, développer un tel jeu aurait nécessité des mois de travail acharné d'une équipe de développeurs spécialisés en C++ bas-niveau et en hardware GBA.

Aujourd'hui, avec des agents autonomes propulsés par Claude Opus 5.5, le rôle du développeur a radicalement muté :

Le développeur n'est plus l'artisan qui tape chaque ligne de syntaxe. Il est l'architecte système qui conçoit le cahier des charges, bâtit les garde-fous de sécurité et supervise l'effort collectif d'une escouade d'agents infatigables.

Ce projet est la preuve vivante qu'avec la bonne méthode, les bons tests et un modèle doté d'une grande rigueur de raisonnement, des agents autonomes peuvent maîtriser les environnements techniques les plus stricts de l'histoire de l'informatique.

🎮 Découvrir et Jouer à Slay the GBA

Vous voulez tester le jeu sur votre ordinateur, votre smartphone ou directement sur votre Game Boy Advance avec une cartouche flash (Everdrive ou EZ-Flash) ?

🌐 Site officiel & Avancement en direct : slay-the-gba.alexandre-enouf.fr
📊 Page d'avancement détaillée : slay-the-gba.alexandre-enouf.fr/avancement.html
📦 Télécharger les 5 ROMs GBA : Disponibles directement sur la page d'accueil du site officiel.