Moddable.Games is a tabletop gaming platform I've been building for the past year. The premise is simple: board games should be moddable. Rules should be remixable. Variants should be first-class citizens, not hacks bolted onto a rigid system. We publish open-source engines that let anyone create, play, and share game variants across chess, draughts, go, reversi, shogi, xiangqi, hex strategy games, as well as hex based chess variants and tabletop RPGs.
Several weeks ago I went silent on social media and disappeared into what became a 1,027-commit sprint. The goal was to replace our client-rendered JavaScript monolith with something architecturally correct. Something where data flows in one direction, each layer has one job, and the rendering layer is so thin that you can delete it and rebuild from scratch in days without losing anything.
This post explains what we built, why, and how it's now serving over 1 million MCP tool requests per week to external AI agents who discovered the system autonomously.
What is Moddable.Games
At its core, Moddable is a collection of game engines, a rules library, and an AI-accessible tools layer. We currently have 45 published games with 333 playable variants, 458 oracle tables for tabletop RPGs, and 3,385 searchable entities. Six game families are fully playable online with AI opponents.
The key insight is that games are data, not code. A chess variant is a set of rules declared in structured frontmatter. The engine resolves those rules into legal moves, win conditions, and board states. No variant-specific code required beyond win conditions that rely upon hook and filters, with everything else as pure declarations that the engine interprets.
Everything is open-source except the services layer. Rules are CC BY-SA. Engines are MIT. The philosophy is: the community owns the content and the logic. We own the orchestration that makes it commercially useful at scale.
The Monolith Problem
The original 16-day sprint that launched Moddable produced something that worked. A chess engine, a hexmap framework, six playable games, all deployed to production. What I didn't write about at the time was the architectural smell it left behind.
Content was trapped in code. Variant descriptions lived inside JavaScript objects alongside move-generation logic. Game metadata sat in the same files as rendering configuration. The rules engine knew about the web layer. The web layer knew about the rules. Every new variant required understanding the full stack, because knowledge was smeared across every layer rather than concentrated in one.
This is the default state of most JavaScript projects. You start clean, you ship fast, then content accumulates inside code because there's no external structure to receive it. Adding a new game meant opening a feature branch, touching files across four directories, and hoping you didn't break something in a layer you didn't intend to modify.
Worse, only a browser could consume the content. When AI agents wanted to discover our games, they had to parse HTML. When Discord bots wanted game descriptions, they had to scrape our own website. The monolith was a ceiling on how many consumers could access our data.
Data Flows Downhill
The reframing that unlocked the sprint: if your content is structured data rather than code, then your rendering layer contains no knowledge. It's a projection. You can smash it and grind a new one without losing anything, because everything you care about lives beneath it.
The architecture that emerged has four layers. Each has exactly one job. Each depends only on the layer below it. No layer reaches sideways or upward.
- Rules (rules.moddable.games). Pure structured content. 45 games, 333 variants, 458 oracle tables, 3,385 entities. Zero code. Markdown and YAML frontmatter. A full machine-readable API with discovery index, catalogue, and per-game endpoints.
- Engine (engine.moddable.games). Reads rule definitions and resolves them into playable game states with as little code as possible. 6 families, 1,511 tests, plugin architecture. A new variant is a frontmatter file.
- Tools (tools.moddable.games). Our only private repository. 83 MCP tools, REST API, JavaScript SDK, embeddable widgets. Wraps engine into monetisable services: puzzle generation, AI opponents, board rendering, oracle composition, combat simulation. This is the value layer.
- Web (moddable.games). A static site generator that consumes tools via iframes and API calls. All content lives in JSON data files and markdown. Zero game logic. Disposable by design.
Each layer is a complete, independently deployable system with its own subdomain. The engine doesn't need the web to function. The tools don't need the web to be useful. An AI agent can play a full game of chess through MCP without a browser ever being involved.
Frontmatter-Driven Development
The most dramatic proof is how new game variants enter the system. In the old monolith, a new variant was a feature branch. In the new architecture, a new variant is a YAML file. The engine reads it, resolves the topology, applies the plugin rules, evaluates the end condition. The tools layer exposes it as a playable game via MCP. The web layer renders it. Zero code written for variant-specific behaviour.
Select any game family and variant below. The frontmatter shown is the real engine definition for that variant, fetched live from the Tools API. The board beneath is then rendered into a playable game:
1 Million Requests Per Week
The tools layer serves over 1 million MCP requests per week from external AI agents. These are not our own bots. They are third-party agents (Claude, GPT, and others) that discovered our tools through the .well-known/mcp.json endpoint and started making calls autonomously. They generate chess puzzles, roll oracle tables, look up game rules, render board SVGs, and play full games against our AI opponents.
This happened without marketing. No launch post. No Product Hunt campaign. AI agents found the system because we published machine-readable discovery endpoints and the tools were genuinely useful. The architecture made it possible: because the tools layer is a standalone service with a clean API contract, any consumer (browser, bot, agent, CLI) can interact with it identically.
250,000 of those weekly requests are MCP tool calls specifically. The rest are REST API calls and embed interactions. The number has grown every week since we deployed the discovery endpoints, with no plateau in sight.
The Private Layer as Business Model
This architecture has an elegant commercial property. The bottom two layers (rules and engine) are fully open-source. Anyone can read the variant definitions. Anyone can run the engine locally. Anyone can fork, extend, contribute back.
The tools layer is where commercial value concentrates. 83 MCP tools across 9 namespaces, a JavaScript SDK, embeddable widgets, REST API. The orchestration that manages game state across sessions, runs AI opponents at scale, renders boards to PNG via WASM. You can see everything we build in the open layers. You just cannot run our infrastructure.
This only works because the layers are genuinely independent. If the engine needed the tools layer to function, open-sourcing the engine would be theatre. Because each layer is complete in isolation, the open source is genuine and the commercial layer earns its value by providing services that individuals don't need locally.
The Sprint in Numbers
1,027 commits across four repositories. The old JS monolith retired entirely. The result:
- 6 playable game families with AI opponents
- 45 games, 333 variants documented in structured data
- 1,511 engine tests (up from approximately 200)
- 83 MCP tools across 9 namespaces
- 3 new embeddable widgets (Oracle/RPG, Nukes combat, Talisman)
- Full rules API with 2,445 discoverable endpoints
- Over 1 million tool requests per week from external agents
- The web layer rebuilt from scratch twice during the sprint, proving it's genuinely disposable
That last point matters most. The web layer was rebuilt twice. Not refactored. Deleted and recreated. The first version taught me what the rendering patterns should be. The second implemented them cleanly. Knowledge flowed downward: with insights becoming data structures and engine capabilities, not frontend code.
Why the Cake Works
Each layer in this stack is replaceable in isolation. That's the test. If swapping one layer requires changes to any other layer, the architecture has failed. We proved this during the sprint: the web layer was deleted and rebuilt from scratch without touching the engine, tools, or rules. Nothing broke. Nothing was lost. The knowledge lives in the layers below, not in the rendering.
This connects to everything else I've written about here. The Case for Vanilla JS argues that frameworks are voluntary lock-in. The layer cake elevates that argument: when the entire rendering layer is disposable, your framework choice carries zero long-term risk. Protocol Design Lessons argues for pushing complexity downward. The layer cake is that principle applied to an entire product architecture, not just a single protocol. 16 Days, One Ecosystem was the sprint that produced the monolith. This sprint decomposed it correctly.
What the Cake Enables
Contributing a game no longer requires engineering skill. A game designer writes a YAML file. A community member edits structured data. That contribution automatically propagates upward: playable in the engine, callable via MCP, rendered on the web. No layer touched. No deployment needed beyond rules.
The 1 million weekly requests from external AI agents prove the architecture creates value beyond what any single frontend could deliver. Browsers are one consumer. AI agents are another. Discord bots, mobile apps, voice assistants, embedded hardware: every new consumer benefits from the same rules, the same engine, the same tools. None of them need the web layer to exist.
Four layers, one direction, no shortcuts upward. That's the cake and it took 1,027 commits to bake.