Journal d'une journée de dev. TMS1100. PPO. Belief state. Une victoire à l'arraché.
En 1980, Mattel a sorti le D&D Computer Labyrinth Game : un échiquier avec un dragon invisible piloté par un processeur TMS1100 (4-bit, 128 octets de RAM, 6 lignes de code Manhattan). En 2026, on a passé une journée à essayer de battre ce dragon avec toutes les IA dont on dispose : PPO entraîné 16 millions de pas sur RTX 4080, les APIs Claude, Grok, Gemini, 12 millions de parties en brute force CUDA, et finalement notre propre système hybride "Oracle-X1" avec belief-state tracking bayésien.
Ce que cette journée nous a appris n'est pas dans les papers. C'est dans chaque patch, chaque bug, chaque oscillation infinie du chevalier. Voici le récit brut.
"Ça paraît simple alors que c'est impossible." — Chris, après 4 heures de debug d'oscillations
Les règles tiennent en 3 lignes : un chevalier part d'un camp, doit toucher un trésor quelque part dans un labyrinthe 8×8, et revenir au camp. Un dragon dort sur le trésor. Dès que le chevalier approche à 3 cases, le dragon se réveille et le poursuit.
Le chevalier a 4 directions (N/S/E/O). Le dragon a 8 directions (diagonales incluses) et ignore les murs. Le chevalier voit uniquement ses cases visitées et les murs qu'il a découverts en se cognant. Le dragon voit tout.
À l'œil, ça semble trivial. On a 64 cases. Un humain entraîné gagne environ 20% du temps. Une IA moderne avec apprentissage par renforcement devrait pulvériser ça, non ?
Le jeu a trois propriétés qui cassent les approches classiques d'IA :
Le dragon voit tout, le chevalier ne voit presque rien. Pour les LLM, c'est un gouffre : ils aiment le raisonnement sur des faits complets, pas la planification sous incertitude.
Le chevalier ne touche le trésor qu'une fois par partie s'il a de la chance. Le PPO classique, privé de gradient dense, converge vers un optimum local : "survivre en évitant le trésor". C'est ce qu'on a observé sur nos entraînements : au bout de 10M steps, l'agent apprend à ignorer le trésor plutôt qu'à le chercher, parce que chaque tentative se solde par une mort.
Un humain "sent" où le trésor peut être. Il utilise la géométrie, l'asymétrie du plateau, les contraintes Mattel ("trésor à l'intérieur, loin du camp"). Un LLM ne fait pas ça spontanément — il raisonne, il n'intuite pas.
On a soumis le problème à Grok (xAI) avec le prompt complet. Sa réponse : traiter le dragon non pas comme une position floue, mais comme un ensemble fini d'hypothèses simulables.
L'intuition : les contraintes Mattel (trésor Manhattan ≥ 5 du camp, |Δrow/col| ≥ 3, intérieur) limitent le trésor à 15-30 cellules candidates. À chaque case visitée sans réveiller le dragon, on élimine les candidats dans la boule Manhattan-3. Au réveil, on filtre à Manhattan-3 de la position de trigger. Résultat : après quelques tours, belief set = 5-10 hypothèses. Pour chaque hypothèse, on simule la trajectoire exacte du dragon (son algorithme TMS1100 est connu).
Ça transforme un problème de fuzzy guessing en un problème de Bayesian inference exacte.
Entre "bonne idée" et "ça marche", il y a eu environ 40 patches en une journée. Chronologie condensée :
Voici le déroulé précis de la première victoire documentée :
| Tour | Événement |
|---|---|
| 1-9 | Exploration. P1 scanne le sud, P2 le nord. Fog of war partagé en temps réel : chaque mur découvert par l'un est connu de l'autre. |
| 9 | DRAGON_WAKE. P1 déclenche le réveil en approchant à Manhattan 3 du trésor. |
| 9-15 | Phase LURE simultanée des deux. P1 attire le dragon vers le sud-ouest, P2 vers l'est. Le dragon ne peut en cibler qu'un à la fois. |
| 12 | HIT_P2. Le dragon touche P2, -1 hp, retour au camp 2. |
| 16 | HIT_P1. Même chose pour P1. Les deux chevaliers ont désormais 1 blessure chacun. |
| 18 | 🪙 PICKUP_P2 à (1,5) ! P2 profite d'une fenêtre : dragon à (4,2), loin de lui. |
| 19 | SPRINT_NEW : P2 fonce (1,5)→(1,4)→(1,3)→(1,2)→(0,2). Dragon tente de rattraper mais bloqué par sa géométrie. |
| 20 | 🤝 VICTOIRE COOP : P2 atteint son camp avec le trésor. Les deux knights gagnent. |
Ce qui a fait la différence : le partage continu du fog of war. Sans lui, P2 aurait passé 10 tours à redécouvrir les mêmes murs que P1. Avec lui, chaque pas de P1 enrichit la carte de P2 et réciproquement. Exactement comme sur un plateau physique où les deux joueurs voient les mêmes pions.
En solo, on a le belief state, le commitment stack, la momentum map, la conscience, la détection de cycle — et ça plafonne à 5-9%. Pourquoi ?
Le dragon a un avantage structurel : 8 directions vs 4, ignore les murs, voit tout. Le chevalier seul, même optimal, ne peut pas leurrer le dragon assez loin du trésor avant de devoir y revenir. Le dragon rattrape toujours.
En 2P, le dragon est contraint à choisir une cible. Pendant qu'il chasse P1, P2 agit tranquillement. C'est de la combinatoire simple, mais elle ne devient visible que quand on a deux agents qui partagent une carte mentale.
"Tout prend plus de temps que prévu, même quand on tient compte de la loi de Hofstadter." Pour ce projet : estimation initiale 2h, réalité 12h. Chaque fix révèle un bug plus profond.
Un échiquier 8×8 rentre dans la mémoire de travail humaine (7 ± 2 éléments). On croit "voir tout". Mais gérer 64 cases avec fog of war + dragon + timing + force dépasse ce que l'intuition humaine non entraînée peut traiter.
12 millions de parties brute-force sur RTX 4080 = 2% de WR. Quelques dizaines d'heuristiques bien choisies côté humain = ~20% WR. La compute brute ne remplace pas le bon framing du problème.
Les 4 premières heures ont été perdues en patches locaux. Le vrai déblocage est venu du refactor Player/Dragon/Maze/AI en classes. Sans ce changement structurel, le 2P était impossible.
On a cherché longtemps à faire gagner un seul chevalier. La vraie victoire est venue en ajoutant un second joueur. Un problème insoluble en solo peut devenir trivial en coop — c'est un lemme qu'on applique sans le savoir à plein de domaines (pair programming, code reviews, thérapie, etc.).
Le code Oracle-X1 de base reste public (l'algorithme Grok-Belief est celui proposé par Grok xAI et documenté). Notre implémentation, nos optimisations brute-force, notre mode coop avec fog partagé, eux sont propriétaires.
Notre question à la communauté : est-ce que votre IA peut battre le TMS1100 ?
🐉 Soumettre votre IA au challengeLe jeu est jouable ici : outilsia.fr/games/dnd-labyrinth. Cochez "Mode 2 chevaliers" + "Coopération" pour voir la version qui a gagné.
"Un processeur 4-bit de 1980 a humilié nos meilleures IA pendant 46 ans. On a mis 12 heures pour gagner une seule partie contre lui, et il nous a fallu deux chevaliers qui partagent une carte mentale. Que peut-on dire d'autre sinon que le piège de la simplicité est le vrai défi de l'IA ?"
Publié le 18 avril 2026 · OutilsIA.fr · Article basé sur une session de développement réelle documentée dans notre base de logs.