[Journal de board] Mon AI joue à pokemon rouge

Ca fait deux ans que je bosse par période sur un projet de moteur de jeu textuel deterministe mais ouvert (pas de scripts, uniquement des patterns émergeants) compatible avec les IA pour créer une nouvelle génération de jeux textuels (qui contrairement à AI dungeons serait complètement déterministe et impossible à "prompt hacker").

A force d'ajouter de nouvelles features, mon moteur s'est peu à peu transformé en "cerveau neuro-symbolique" et j'ai commencé à me demander si je ne pouvais pas l'utiliser pour des taches plus orienté buisness et pour proposer une alternative aux RAGs actuels en créant une sorte de "jumaux numérique" capable de réduire considérablement le scope d'actions d'un agent IA.

En gros ma thèse, depuis un moment, c'est qu'il faut garder les IA généralistes pour les taches où elles excellent (à savoir réflechir, plannifier...) et les laisser utiliser des outils ciblés pour interagir avec leur environnement. Les MCPs vont actuellement dans la bonne direction, mais bien souvent sur des projets complexes le nombres de possibilités d'outils et la "mémoire textuelle" explose si bien que... Et bien la mayo ne prend pas vraiment et les agents font beaucoup d'erreur

Bon c'est bien rigolo tout ça, mais quel rapport avec Pokemon ? Et bien il y a quelques mois, "Claude plays pokemon" a un peu buzzé sur internet car Claude a été (de mémoire, ça a peut être encore changé depuis...) l'IA allant le plus loin dans une partie de Pokemon (même si il n'a pas été jusqu'au bout de l'aventure).

Ce cas est super intéressant car il illustre parfaitement ce que je veux démontrer. Les agents sont vites dépassé à cause de la mémoire contextuel qui fini par exploser et l'IA fini par se perdre et n'arrive plus à avancer.

Et donc pour cette nouvelle année, je me suis dis que j'allais tenter moi même l'expérieur en laissant jouer un agent à pokemon mais de la bonne manière:
- avec des outils propre et bien pensés pour automatiser certaines interaction avec le jeu (par exemple, si l'agent veut aller dans l'arène X, on s'en fiche qu'il trouve la bonne séquence d'input, ce qui est intéressant c'est qu'il veuille aller dans l'arène X... Et donc on lui fourni des outils de navigation automatique)
- et équipé de mon engine en guise de mémoire neuro-symbolique pour l'aider dans sa prise de décision.

C'est un gros projet, on verra si j'arrive au bout, mais je veux garder des traces au niveau de ce que je développe en préparation d'articles que je pourrais plublier sur le sujet par la suite (on verra, mais autant avoir des notes de prêtes si ça venait à arriver). Bref, ce topic me servira de journal de bord, je compte passer de temps en temps pour poser sur le papier les avancements / problèmes que j'ai pu rencontrer, etc...

Ah, et tout est 100% codé par claude code, pas le temps de gerer moi même

Au niveau de la stack technique, j'utilise principalement Python. Claude Opus 4.5 pour gérer le code. GPT 5.2 pour "brainstormer".

J'utilise Pyboy qui est un emulateur construit en python qui expose la ram du jeu et me permet d'interagir avec le jeu en temps réel via du code.

Actuellement mon "core engine" (nom de code: syntium) permet de créer une représentation simplifié d'un monde. Mon idée est de créer une (ou plusieurs on verra) couches intermédiaires entre l'emulateur et la mémoire. L'agent, lorsqu'il voudra interagir avec le monde, pourra consulter la mémoire symbolique et agir en fonction via un set d'outil.

Au niveau temps de dev pure, j'ai déjà passé 3 semaines sur le code du core engine afin qu'il soit le plus robuste et fonctionnel possible. Sans exposer son fonctionnement dans les détail, il me permet de faire émerger tout un tas de comportement, gère des environement, des entités à l'intérieur de ces environnements et est 100% configurable. Tout est orienté data, on peut crée un instance personnalisé simplement à partir d'un template et de quelques jsons. C'est abstrait pour le moment mais j'entrerais un peu plus dans les détails quand je creererais les ponts nécessaires entre l'emulateur et mon moteur

Le 02 janvier 2026 à 14:59:17 :
Je rappel que l'OP a fait un beau bénéfice sur IONQ donc on croit en lui

J'ai fait x6 en bourse cette année avec une stratégie d'arbitrage aussi depuis, mais c'est HS pour ce topic

Le 02 janvier 2026 à 15:07:55 :

Le 02 janvier 2026 à 14:59:17 :
Je rappel que l'OP a fait un beau bénéfice sur IONQ donc on croit en lui

J'ai fait x6 en bourse cette année avec une stratégie d'arbitrage aussi depuis, mais c'est HS pour ce topic

Oui mais ta arrêter de mettre le topic à jour

Maintenant petit récapitulatif des deux derniers jours:

J'ai eu l'idée de faire jouer à un agent à pokemon via mon engine pendant la soirée du nouvel an et je n'ai jamais touché à l'émulation ou la robotique (je suis data scientist de base), donc pas mal de nouveautés pour moi.

Je découvre tout actuellement et j'ai déjà eu mes premières difficultés

Etape 1: permettre à l'IA (en l'occurence Claude Code) d'intéragir directement avec le jeu.

Côté installation de l'emulateur (Pyboy) , rien à dire c'était assez direct et j'ai ensuite simplement demandé à claude de coder un MCP (une interface lui permettant d'executer des fonctions) lui permettant d'intéragir avec le jeu.

Le jeu marchait en fenêtre invisible mais Claude pouvait y naviguer. En twickant un peu et en bidouillant au niveau du multiproc j'ai réussi à obtenir une version que je pouvait voir bouger "en live", et sur laquel l'IA et moi pouvont agir.

Le fait que je puisse prendre la main est super important en phase de dev car j'ai pas envie d'attendre 50 inputs de claude pour tester la réactivité des autres services que je vais faire tourner par dessus

Bref, jeu fonctionnel et pilotable, c'est une première victoire.

Etape 2: Créer une version 'papier' du monde afin de pouvoir y naviguer facilement

Là ça se complique.

En gros sur la game boy, on a une vue centrée sur le personnage de 9 px x 9px. Pyboy fourni l'état de la mémoire pour chaque case ainsi qu'un masque de collision et la position du joueur.

Pour récuperer l'état de la carte en live, j'ai crée un petit service qui va appeler les bons endpoints sur pyboy afin de récuperer l'état de la mémoire sur chaque pixel et le masque de collision. Je stock ensuite cette information sous forme de graph {coordonnée_absolue: pixel_type} ce qui me permettra de facilement naviguer d'un point à un autre via des algos d'explo classique.

Pour mapper les caracteristique de la mémoire en "info réel" (= qu'est ce qui est de l'eau, de l'herbe, une porte d'entrée)... Et bien je fais des essais en me plaçant à certains endroits, puis je regarde la valeur dans la ram et j'associe le pattern correspondant.

J'ai eu quelques problèmes de syncronisation de la carte, notamment pendant les déplacement du personnage que j'ai réglé via des flags (en gros je mets à jour la carte que quand le personnage est considéré "immobile".

Ensuite j'ai demandé à Claude de me coder une petite view qui se syncronise en live en affichant la carte exploré à côté de la vue "game boy" et voici le resultat final. Chaque couleur représente une information utile (bloc infranchissable, PNJ, warps, hautes herbes, eau) et la vue est syncroniser avec le jeu quand je me déplace.

A partir de là, j'ai une représentation "mentale" de la carte qui pourra servir d'appuis à l'IA pour naviguer. Youpi

Toujours dans le récapitulatif, l'étape d'après est de crée le service de navigation à proprement parler.

Grosso modo ce qu'on ne veut pas, c'est de laisser l'agent entrer à la main chaque input un par un. Pour plusieurs raisons:
- Déjà, ça consomme potentiellement énormement de token et ça coute cher, et on aime pas ce qui coute cher
- Ensuite il y a le risque, surtout pour de longues distance, que l'IA perde le fil. Je l'ai vu tout au début en essayant de laisser l'agent entrer dans une maison: il va essayer d'entrer, puis se cogner contre un mur, et faire deux inputs au lieu d'un, se retrouver de l'autre côté de la porte, etc... Bref ça marche pas.

La solution est de proposer une fonction capable de calculer le "plus court chemin" entre deux points. On passe coordonnée initiale et coordonnée final, et l'algo se charge de fournir la séquence à suivre pour aller de A à B. Ensuite on a plus qu'à executer la séquence via l'interface pyboy. L'agent n'a pas besoin d'écrire "je fais droite, droite, droite, haut, haut", il a juste à dire: "je veux aller en X" et un outil se charge de la navigation.

J'ai trouvé deux cas un peut tricky à prendre en compte, mais avec des petites logiques supplémentaire, ça se fait bien.
- Premier cas: le cas où on rebondit sur des PNJ "mobile". On peut se retrouver sur une séquence désyncroniser. Pour éviter ça, on execute la trajectoire "par morceau" avec un mecanisme de retry. Si on se désyncronise à cause d'un PNJ, le "GPS" se resyncronise à l'itération suivante.
- Deuxième cas: les warps sont codés de deux manières différentes. Entrer dans une maison ou prendre un escalier nous TP dans le nouvel environnement en entrant sur la case. Sortir suppose de "pousser" vers le mur adjacent. Pour éviter les problèmes, j'ai ajouté un controle afin de detecter le "TP" lorsqu'on touche un warp. Si il n'a pas lieu, on pousse automatiquement contre le mur.

Voilà à quoi ça ressemble en vidéo. Ici je donne une séquence à l'IA (va dans la maison, monte les escalier, puis retourne au labo) et l'IA s'execute. Au moment du recording il y avait encore un petit bug avec le warp mais ça a été corrigé depuis.
https://youtu.be/9_leY_9Ks0o