Contexte technique de l’Amiga 500

Le titre original, Babylonian Twins, tournait sur un Amiga 500 doté de 512 KB de RAM, d’un processeur Motorola 68000 à 7,14 MHz et d’un affichage piloté par le coprocessor vidéo « copper ». Le code était purement assembleur 68000 ; chaque sprite, chaque ligne de balayage et chaque accès joystick était écrit à la main. Au démarrage, le programme sauvegardait les vecteurs d’interruption, désactivait l’OS et prenait le contrôle complet du matériel : 

move.l  #$dff000,a0   ; base des registres vidéo
lea     save(pc),a1 ; adresse du système
move.w  #$4000,intena(a0) ; désactiver les interruptions OS
Le rendu reposait sur une liste copper réécrite chaque frame, le blitter était commandé directement et les entrées CIA lues sans couche système. Le jeu fonctionnait à 50 Hz, fréquence native de l’Amiga, et les valeurs de friction, de gravité et de timing étaient calibrées pour ce tick.

Portage initial du moteur C++ vers Godot 4

En 2010, les auteurs avaient réécrit le même gameplay en C++ (≈34 000 lignes) pour iOS. En 2024, le même code a été migré vers Godot 4 en moins de deux heures grâce à Claude Code. Le journal d’exécution montre la création d’un projet vide, l’import des assets TMX, puis la disponibilité de tous les 38 types d’entités en moins de 30 minutes. Le moteur Godot exécute le jeu à 60 Hz, ce qui impose une adaptation des constantes temporelles : la friction au sol, définie par static const float GROUND_DRAG_FACTOR = 0.85f;, était prévue pour 60 ticks s⁻¹ et doit être recalculée pour 50 Hz afin de conserver le même comportement.

Reconstruction de l’assembly 68000 avec Claude

Le défi majeur était de traduire les 72 758 lignes d’assembleur 68000 en GDScript sans documentation. Claude Fable 5 a reçu les binaires, les formats de niveaux et les scripts de construction, puis a généré automatiquement le code source, les drapeaux de compilation et les scripts de test. Les drapeaux ajoutés permettent une exécution sans interface : 

--level=<name>       charge un niveau
--pose=<spec>        positionne les jumeaux
--drive=<spec>       simule les entrées bouton‑par‑bouton
--probe              exporte l’état des portes/clefs
--screenshot=<path> capture une frame et quitte
Claude a ensuite invoqué vasm pour assembler les sources, FS‑UAE pour émuler l’Amiga et diff pour comparer les binaires générés aux originaux. Aucun test visuel automatisé n’a été mis en place ; les captures d’écran ont été inspectées manuellement, ce qui expose le processus à des biais subjectifs.

Synchronisation des fréquences d’horloge et limites

Le portage révèle la sensibilité du gameplay aux taux de rafraîchissement. La multiplication de la vitesse horizontale par 0,85 à chaque tick produit une courbe de décélération qui dépend exponentiellement du nombre de ticks par seconde. À 60 Hz, la friction totale diffère de celle à 50 Hz, entraînant des sauts et des rebonds « qui ne semblent pas bons ». Le développeur a donc maintenu deux jeux de constantes : l’un pour le moteur moderne (60 Hz) et l’autre pour la reconstruction fidèle (50 Hz). Cette double‑calibration garantit que le jeu original conserve son feeling tout en offrant une version moderne jouable. Cependant, l’absence d’une comparaison pixel‑par‑pixel automatisée laisse une marge d’erreur non quantifiée, surtout sur les effets de palette et les timings de la copper list, qui restent difficiles à reproduire sans accès direct au matériel.