Divine Simulation, des IA qui jouent aux dieux dans WorldBox

Le projet

Alors, pour le coup, tout est parti d’une session WorldBox. Pour ceux qui ne connaissent pas, c’est un god game où on observe des civilisations naître, se battre, fonder des religions, et se faire rouler dessus par une météorite qu’on a déclenchée deux minutes avant. Et à un moment, je me suis dit : et si les dieux du jeu étaient de vraies IA, avec des personnalités, des stratégies, et des rancunes les unes contre les autres ?

Du coup, j’ai monté un système où quatre agents IA (Claude, via Anthropic) incarnent chacun un dieu, Ares le guerrier, Gaia la bienveillante, Loki le trickster, Athena la stratège. Chaque dieu pilote plusieurs religions dans le jeu, bénit ses fidèles, maudit ses ennemis, déclenche des catastrophes, négocie au conseil des dieux, et évidemment, complote contre les autres dès qu’il peut.

L’objectif final, c’est de filmer une simulation de 1000 ans et d’en faire une vidéo YouTube, pour voir quel type de personnalité divine l’emporte quand on les lâche longtemps.

L’architecture tient en trois briques :

Un mod C# qui expose l’état du jeu via une API HTTP (42 outils)
Un orchestrateur Node.js qui fait réfléchir les dieux via Claude et exécute leurs actions
Un dashboard React pour tout visualiser en temps réel et rejouer les parties

Mes contributions

Le mod WorldBox (C# / .NET 4.8)

Développement complet de WorldBoxMCP, un mod qui expose le jeu via un serveur HTTP JSON-RPC 2.0. Concrètement, ça donne :

42 outils MCP. Lecture de l’état du monde (royaumes, créatures, religions avec leur fondateur, leurs traits, leurs fidèles notables), actions divines (bénédictions, malédictions, catastrophes, diplomatie, terraforming), contrôle temporel (pause, vitesse), et intégration religion (ajout de traits comme summon_lightning ou necromancy, conversion de fidèles, changement de couleur des bannières).
Gestion du threading Unity via un MainThreadDispatcher custom. Les appels HTTP arrivent sur un thread background, mais les opérations de jeu doivent tourner sur le thread principal, sinon Unity hurle et le jeu crashe. C’est un classique, mais il fallait le faire proprement.
Fix du pathfinding. La création d’îles artificielles faisait crasher le jeu parce que les régions de navigation n’étaient pas recalculées après terraforming. J’ai debuggé via les logs Unity et reconstruit les MapChunk à la volée, et ça tient.
Décompilation du jeu via ILSpy pour comprendre les API internes. Le système de couleurs passe par un ReligionColorsLibrary, les traits par un ReligionTraitLibrary, la conversion d’un fidèle par actor.setReligion(). Sans la décompilation, c’était du grattage pur.

L’orchestrateur (Node.js / TypeScript)

C’est le cerveau de la simulation. La boucle de tick tourne comme ça : pause du jeu → snapshot du monde → conseil des dieux (3 rounds de débat, Sonnet) → réflexion parallèle des 4 dieux (Haiku) → validation des actions par budget → exécution via MCP → reprise du jeu.

Quelques points sur lesquels je me suis arrêté un moment :

Le Divine Power. Chaque dieu accumule des points basés sur un ratio followers / total mondial. Les points sont stackables sur 10 ticks, et chaque action a un coût fixe (1 point pour un bless, 6+ points pour ajouter un trait de religion). Le serveur enforce les coûts, du coup, si un dieu triche, ses actions sont rejetées en bloc. C’est ce qui a fini par donner un vrai équilibrage, j’en parle plus bas.
Multi-religion. Chaque dieu gère 5 à 7 religions en round-robin, et sa puissance cumule tous ses fidèles. Ce qui fait que la domination d’un dieu est directement corrélée au nombre de civilisations qui le vénèrent.
Le conseil des dieux. Trois rounds de débat séquentiel via Claude Sonnet, le dieu le plus puissant parle en premier, et le résumé persiste dans le prompt jusqu’au conseil suivant. Ça crée une espèce de mémoire politique entre les sessions, ce qui est exactement ce que je cherchais.
Interactions dieu-vs-dieu. Sabotage pour voler des points à un rival, bouclier divin, provocation, empowerment d’alliés, vol de fidèles. Typiquement le genre de choses qui émerge tout seul dès qu’on leur donne les outils.
Persistance SQLite. Chaque pensée, chaque prompt envoyé, chaque action, chaque snapshot du monde est sauvegardé tick par tick. Au redémarrage du serveur, tout est restauré via un événement sim:hydrate, ce qui permet de rejouer froidement une partie en entier des semaines après.

Le dashboard React

Interface temps réel pour observer la simulation et intervenir si besoin.

Sidebar avec les avatars des dieux, toutes leurs religions, followers, et une barre de puissance divine.
Dashboard principal : population par race, followers par dieu (stacked area), puissance divine dans le temps, table des royaumes (roi, religion, dieu protecteur, population, villes).
Panneaux dieux : plan stratégique à 10 ans, pensées internes, actions récentes avec un badge de coût en points, actions rejetées barrées, et un mode debug complet avec le prompt envoyé et la réponse brute de Claude. Très utile pour comprendre pourquoi un dieu fait n’importe quoi.
Conseil : log des débats avec avatars colorés et archetype.
Replay : slider tick par tick, vue détaillée de chaque événement, pensées des dieux dépliables avec prompt et réponse côte à côte.
Overgod : panneau d’intervention directe, pour lancer des décrets aux dieux, des actions rapides, ou appeler un outil MCP à la main.
Action Feed : flux temps réel avec icônes, badge de coût, raison de l’action, et nom de la créature ciblée.

Ce que j’ai retenu

Les LLM sont des joueurs médiocres sans garde-fous. C’est probablement l’enseignement le plus net du projet. Sans budget de points ni validation serveur, les dieux faisaient la paix mondiale en un clic et convertissaient des armées entières gratuitement. L’équilibrage est venu de contraintes strictes : coûts fixes, budget limité, rejet des actions trop chères, et mémoire des échecs passés dans le prompt. Une fois qu’on encadre proprement, le jeu redevient intéressant.

L’impact réel est le plus dur à obtenir. Les dieux préfèrent les petites actions (bénir une personne, convertir un fidèle) aux grosses (ajouter un trait de religion qui change tout le gameplay pour des milliers de fidèles). Ce qui fait que la croissance naturelle du jeu écrase l’intervention divine, du coup, il faut activement pousser les IA vers les actions à fort impact. C’est contre-intuitif au départ, mais ça fait sens : une action coûteuse, c’est un risque à court terme pour un bénéfice à long terme, et les LLM raisonnent assez mal sur ce genre d’arbitrage sans qu’on les guide.

La persistance n’est pas optionnelle. J’ai commencé avec des fichiers JSON/JSONL, évidemment, et j’ai migré vers SQLite quand j’ai réalisé qu’un refresh faisait tout perdre. Maintenant chaque pensée de chaque dieu est traçable, rejouable, analysable. C’est typiquement le genre d’investissement qu’on repousse et qu’on regrette après.

Le modding est un terrain de jeu idéal pour l’IA. WorldBox expose assez d’API pour créer des systèmes complexes sans toucher au code source, et la décompilation via ILSpy a été cruciale pour comprendre les mécanismes internes (couleurs de religion, traits, pathfinding). C’est un format intéressant pour tester ce que les IA peuvent faire dans un environnement non trivial mais contraint.

Haiku + Sonnet, le bon compromis. Haiku pour les 800+ appels d’actions par simulation (pas cher, suffisant pour sortir du JSON structuré), Sonnet pour les ~50 sessions de conseil (meilleur dialogue, plus de personnalité, et ça se sent vraiment sur les débats). Coût total estimé : environ 5 à 10 dollars pour 1000 ans de simulation. Pour le coup, c’est ce genre de chiffres qui rend le projet jouable en side project.

Contexte

Projet personnel, développé en une session intensive avec Claude Code. L’idée vient de ma passion pour les simulations émergentes et de la question : que se passe-t-il quand on donne de l’autonomie à des agents IA dans un système complexe, avec des règles strictes mais de la marge pour improviser ?

Le code du mod C#, de l’orchestrateur TypeScript et du frontend React a été écrit intégralement via Claude Code, débugage compris (crash de pathfinding, API de couleurs des religions, parsing JSON des réponses Haiku). Pas mal d’itérations sur les prompts des dieux, mais assez vite convergent sur le reste.

Stack technique

Composant	Technologies
Mod WorldBox	C# (.NET 4.8), NeoModLoader, Unity Engine
Orchestrateur	Node.js, TypeScript, tsx
IA des dieux	Claude Haiku 4.5 (actions) + Claude Sonnet 4 (council), via Anthropic SDK
Persistance	SQLite (better-sqlite3), WAL mode
Frontend	React 18, Vite 8, TypeScript, Tailwind CSS 4, Recharts, Zustand, Framer Motion
Communication	HTTP JSON-RPC 2.0 (MCP), WebSocket (ws), Express
Analyse	ILSpy (décompilation du jeu)