If you've ever tried to embed a game of chess on a website, you probably not only had too much time on your hands, but likely reached for one of the established libraries such as Chessboard.js or Lichess's board component. They work, but what if you wanted to recreate Atomic Chess, where every time a piece is captured, the capturing piece and any pieces surrounding that piece are destroyed? Or even classics such as Grand Chess, which simply require larger 10x10 boards. Perhaps you want to create a new variant where pieces can clone themselves or upgrade their abilities? Suddenly you're forking entire codebases and fighting against architectures designed for one game.
That frustration and a burning desire to take chess in a new direction is what started everything. Sixteen days later, the result was two game engines, six playable games, 16 AI-callable tools, Consumer SDKs, a 190-page rulebook pipeline, developer documentation, and moddable.games tying it all together. The Moddable Chess Engine handles the turn-based logic. Moddable Hexmaps handles procedural map generation. The MCP server makes both callable by any agent. All MIT-licensed, all built using AI-augmented engineering workflows, and all deployed to production in those 16 days.
The Chess Engine
The Moddable Chess Engine plays 70 chess variants on boards of all different shapes and sizes, with multi-depth AI, Web Worker threading, 26 variant-specific opening books, and 5 difficulty levels. Pure JavaScript, no dependencies, embeddable with a single iframe tag. Every variant is a single plugin file that extends a shared core through a tiered plugin architecture. Adding variant #71 takes minutes because the architecture does the heavy lifting.
The engine also ships a Consumer SDK: renderer extension hooks, a reusable game controller, replay API, unit templates, terrain predicates, and effect lifecycle hooks. These aren't chess-specific. They're the primitives for building any turn-based game on top of the move engine and AI. Native ESM throughout, no build step, same source files serve browser, Worker, and Node.js.
The proof is Dungeon Chess, an asymmetric skirmish game with 4 fantasy factions, dungeon terrain, water hazards, and XP-budgeted unit drafting. It runs entirely on the consumer APIs. Custom tilePainter renders dungeon walls. Custom pieceProvider renders fantasy units. The game controller handles multi-faction turns. Zero engine forks. The chess engine became a game framework.
The Hex Map Framework
Moddable Hexmaps solves a different problem: board game designers need maps, but designing them manually is tedious and sharing them is friction-heavy. The answer: seeded procedural generation. Same seed, same map, every time. Every map has a URL. Sharing a map is sharing that URL.
The framework generates hex grids via Canvas (flat-top or pointy-top, at any ring count) for six game configurations: volcanic landscapes, 55-terrain fantasy worlds, galaxy layouts with wormholes and nebulae, faction-clustered biomes, and Seafarers-style island boards. Maps export to PNG, PDF, annotated SVG, and JSON. Everything renders client-side, so there's no server cost regardless of scale.
Like the chess engine, hexmaps ships a Consumer SDK for iframe-free embedding with render hooks, event systems, and full programmatic control. The same pure functions that render maps in the browser power 6 AI-callable MCP tools, letting agents generate and analyse hex maps without a UI.
Why 16 Days Was Enough
Every architectural decision compounds. The variant plugin interface means adding a new chess variant is a single file. The seeded RNG means sharing a map is sharing a URL. The renderer hook system means Dungeon Chess didn't fork the engine. The postMessage API means any embed is controllable at runtime without rebuilding the iframe. Native ESM means the same source files serve the browser, Cloudflare Workers, and Node.js without a bundler.
Each decision removes future work. The 16-day timeline is a consequence of getting these decisions right early, not of typing faster. The architecture that made both engines embeddable also made them AI-callable for free: a Cloudflare Worker at tools.moddable.games serves 16 tools over MCP, REST, OpenAPI, and llms.txt. Any MCP-compatible agent connects with one command:
claude mcp add --transport http moddable-tools https://tools.moddable.games/mcpThe tools are stateless, the Worker runs on Cloudflare's free tier, and the same pure functions that power the browser games power the AI tools. No translation layer. No separate API.
The Other 14 Days
Sixteen days to ship. Fourteen more to make it professional. The ratio is the point.
AI-augmented engineering compresses the build phase dramatically. Two game engines, six games, 16 MCP tools, Consumer SDKs, a 190-page rulebook pipeline, developer documentation, and the main moddable.games website tying it all together — 16 days because the architecture was right and the tooling let the AI operate at full speed.
The next 14 days were a different kind of work. Not building, but curating. Reading every paragraph knowing an AI will confidently start 22 sentences with "But" and never flag the pattern. Noticing that version numbers in prose add noise without adding information. Catching that an evolutionary framing is the wrong narrative when the reader just wants to know what the thing does. Recognising that OG images referenced titles from three rewrites ago, that favicon paths resolve differently on localhost versus production, that a removed meta tag was silently breaking RSS feeds.
Each individually trivial. Collectively the difference between a portfolio piece and a side project.
The more interesting work was systemic. Every correction becomes a rule. Every rule gets encoded into the environment. That environment now governs every project without requiring me to remember what was decided last Tuesday. However, rules are passive.
The next step was process automation: a structured issue pipeline across six repositories, with labels that route work through research and implementation agents running on cloud infrastructure — no terminal open, no machine running. Issues aren't a backlog. They're a typed queue. Research agents investigate and scope. Implementation agents branch, build, and merge. I review the differences.
This is what separates prompt engineering from engineering with AI. Prompt engineering is asking a model to write code. Engineering with AI is building the feedback loops and automation infrastructure that make the model's output compound across time and projects.
The 16-day build is impressive. The system that makes every subsequent build faster, more consistent, and less dependent on me is the result I went looking for.
Try Them
Both engines are live, MIT-licensed, and waiting for someone to build something weird with them.
- moddable.games — the full ecosystem: engines, games, tools, developer docs
- chess.moddable.games — play any of the 70 variants right now
- hex.moddable.games — generate a map, grab the seed, share the URL
- tools.moddable.games — connect your AI agent to 16 game tools
- github.com/Moddable-Games — everything is open source