Divine Simulation, AIs playing gods in WorldBox

The project

It all started from a WorldBox session. For those who don’t know, it’s a god game where you watch civilizations be born, fight, found religions, and get steamrolled by a meteor you triggered two minutes earlier. And at some point I asked myself: what if the game’s gods were real AIs, with personalities, strategies, and grudges against each other?

So I built a system where four AI agents (Claude, via Anthropic) each play a god, Ares the warrior, Gaia the benevolent, Loki the trickster, Athena the strategist. Each god drives several religions in the game, blesses followers, curses enemies, triggers catastrophes, negotiates in the council of gods, and obviously schemes against the others whenever possible.

The end goal is to film a 1000-year simulation and make a YouTube video of it, to see what kind of divine personality wins out when you let them loose for long enough.

The architecture fits in three pieces:

A C# mod that exposes the game state via an HTTP API (42 tools)
A Node.js orchestrator that makes the gods think via Claude and executes their actions
A React dashboard to visualize everything in real time and replay sessions

My contributions

The WorldBox mod (C# / .NET 4.8)

Full build of WorldBoxMCP, a mod that exposes the game via an HTTP JSON-RPC 2.0 server. Concretely, it delivers:

42 MCP tools. Reading the world state (kingdoms, creatures, religions with founder, traits, notable followers), divine actions (blessings, curses, catastrophes, diplomacy, terraforming), time control (pause, speed), and religion integration (adding traits like summon_lightning or necromancy, converting followers, changing banner colors).
Unity threading handled through a custom MainThreadDispatcher. HTTP calls land on a background thread, but game operations have to run on the main thread, otherwise Unity yells and the game crashes. Classic, but it had to be done properly.
Pathfinding fix. Creating artificial islands was crashing the game because nav regions weren’t recomputed after terraforming. Debugged via Unity logs, rebuilt MapChunks on the fly, and it holds.
Game decompilation via ILSpy to understand internal APIs. The religion color system goes through ReligionColorsLibrary, traits through ReligionTraitLibrary, converting a follower via actor.setReligion(). Without decompilation, it would’ve been pure scraping.

The orchestrator (Node.js / TypeScript)

The simulation’s brain. The tick loop goes like this: pause game → snapshot world → council of gods (3 rounds of debate, Sonnet) → parallel thinking of the 4 gods (Haiku) → action validation by budget → execution via MCP → unpause game.

A few points I spent real time on:

Divine Power. Each god accumulates points based on a ratio of followers / total worldwide. Points stack across 10 ticks, and every action has a fixed cost (1 point for a bless, 6+ points to add a religion trait). The server enforces costs, so if a god cheats, their actions get rejected wholesale. This is what eventually produced real balance, I’ll come back to it below.
Multi-religion. Each god manages 5 to 7 religions in round-robin, and their power stacks all their followers. Domination of a god is directly correlated to the number of civilizations worshipping them.
Council of gods. Three rounds of sequential debate via Claude Sonnet, the most powerful god speaks first, and the summary persists in the prompt until the next council. Creates a kind of political memory across sessions, which is exactly what I wanted.
God-vs-god interactions. Sabotage to steal points from a rival, divine shield, provocation, empowering allies, stealing followers. Typical stuff that emerges on its own as soon as you give them the tools.
SQLite persistence. Every thought, every prompt sent, every action, every world snapshot is saved tick by tick. On server restart everything is restored via a sim:hydrate event, which makes it possible to replay a full session cold, weeks later.

The React dashboard

Real-time interface to observe the simulation and intervene if needed.

Sidebar with the gods’ avatars, all their religions, followers, and a divine power bar.
Main dashboard: population per race, followers per god (stacked area), divine power over time, kingdom table (king, religion, protector god, population, cities).
God panels: 10-year strategic plan, internal thoughts, recent actions with a cost badge, rejected actions crossed out, and a full debug mode with the prompt sent and Claude’s raw response. Very useful to understand why a god is doing nonsense.
Council: debate log with colored avatars and archetype.
Replay: tick-by-tick slider, detailed view of each event, collapsible god thoughts with prompt and response side by side.
Overgod: direct intervention panel, to issue decrees to gods, run quick actions, or call an MCP tool by hand.
Action Feed: real-time stream with icons, cost badge, action reason, and target creature name.

Takeaways

LLMs are mediocre players without guardrails. Probably the clearest lesson of the project. Without a point budget and server validation, the gods were making world peace in a single click and converting entire armies for free. Balance came from strict constraints: fixed costs, limited budget, rejection of too-expensive actions, and memory of past failures in the prompt. Once properly framed, the game gets interesting again.

Real impact is the hardest to obtain. Gods prefer small actions (bless one person, convert one follower) to big ones (add a religion trait that changes the gameplay for thousands of followers). So the natural growth of the game crushes divine intervention, which means you have to actively push the AIs toward high-impact actions. Counter-intuitive at first, but it makes sense: a costly action is a short-term risk for a long-term benefit, and LLMs reason pretty poorly on that kind of trade-off without guidance.

Persistence isn’t optional. I started with JSON/JSONL files, obviously, and migrated to SQLite when I realized a refresh was wiping everything. Now every thought of every god is traceable, replayable, analyzable. Typical investment you postpone and regret later.

Modding is an ideal playground for AI. WorldBox exposes enough API to build complex systems without touching the source code, and decompilation via ILSpy was crucial to understand the internal mechanics (religion colors, traits, pathfinding). Interesting format for testing what AIs can do in a non-trivial but constrained environment.

Haiku + Sonnet, the right compromise. Haiku for the 800+ action calls per simulation (cheap, enough for structured JSON), Sonnet for the ~50 council sessions (better dialogue, more personality, and it shows on the debates). Total estimated cost: around 5 to 10 dollars for 1000 years of simulation. That’s the kind of number that makes the project playable as a side project.

Context

Personal project, built in an intensive session with Claude Code. The idea comes from my passion for emergent simulations and the question: what happens when you give autonomy to AI agents in a complex system, with strict rules but room to improvise?

The C# mod, TypeScript orchestrator and React frontend code were all written via Claude Code, debugging included (pathfinding crash, religion color API, JSON parsing of Haiku responses). A fair amount of iteration on the gods’ prompts, but pretty quickly convergent on the rest.

Tech stack

Component	Technologies
WorldBox mod	C# (.NET 4.8), NeoModLoader, Unity Engine
Orchestrator	Node.js, TypeScript, tsx
Gods’ AI	Claude Haiku 4.5 (actions) + Claude Sonnet 4 (council), via Anthropic SDK
Persistence	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
Analysis	ILSpy (game decompilation)