Kingdoms of Sand：團隊用 Claude Code 9 天打造瀏覽器 3D 城堡策略遊戲

As kids we played a lot of Stronghold. Build a castle, keep the peasants fed, set taxes too high, watch them leave, then defend the walls against a siege. We've talked about making our own version for years. Last week we finally started, with Claude Code doing most of the programming.

The result is Kingdoms of Sand: a real-time castle strategy game in 3D that runs in the browser, for 1 to 8 players. It's in closed beta now. This post covers what the game is, how we worked with Claude, and some technical details.

What the game is

Kingdoms of Sand is inspired by Stronghold, but the graphics, numbers and rules are our own. It's set in a desert with oases, swamps and rock ridges.

You run an economy with 62 buildings and 23 goods: wood, stone, iron, pitch from the swamp, the wheat to flour to bread chain, apples, cheese, hunting, ale, leather, weapon and armour smiths, horses and a market. Your people care about rations, taxes, ale and religion, and you pick a ruling style between gentle and harsh, which affects popularity, work speed and morale.

You draw walls, palisades, moats and pitch ditches as lines or as closed rings. Soldiers walk on the walls, ballistae sit on towers, drawbridges go up and down. Attackers bring rams, catapults, trebuchets, siege towers, ladders and sappers. When a wall collapses, the soldiers standing on it fall with it.

There are also dragons. You hatch them from eggs and they set towns on fire.

It runs in any modern browser, including phones in portrait and landscape. Nothing to download.

Nine days

The first entry in our changelog is v0.1.0, "The first walls", on 19 October 2026. Today we're at v0.81.3. That's 145 releases and about 250 pull requests in nine days.

We planned a 2D isometric game. This is day 1:

It worked, but it didn't look like the game we had in mind. On day 4 we asked Claude to try the same scene in 3D with three.js, next to the 2D renderer. We compared both, and by the next day the whole game was 3D.

This is today. Most of the last five days went into details: fire that starts at the roof and spreads, horses that walk instead of sliding, rounder fruit on the market stalls (that one is an actual changelog entry).

A few other changelog entries:

• "No more confetti in the sand." Small grass tufts showed up as red and green dots on iPhones.
• "A desert land without rain." We had added weather including rain, then remembered it's a desert.
• "No more smoke walls over battles."
• "Battles with 10,000 soldiers."

How we worked with Claude

We're a small software company in Germany, not a game studio. No 3D artist, no sound designer. Claude wrote most of the code. We played every build and decided what to change.

We wrote the plan first. Before any code there were concept documents: a master plan, the architecture, a simulation spec with the formulas, a netcode spec and a backlog. They're in the repo, and Claude reads and updates them.

We ran many small threads in parallel. Instead of one long conversation, each task got its own thread: fix the horse animation, add clans and tournaments, translate the game to English, find out why it stutters on laptops. Each thread has its own branch and opens its own PR. On busy days that meant a few dozen PRs.

Rules go into CLAUDE.md. With several threads working at once, they need shared rules. Two of ours:

• Every change players can see gets a changelog line in German and English, written for players. That's also how we know what happened on which day.
• Pick the version number last. Before merging, a thread merges main, looks at the newest entry and takes the next free number. This stopped most of our merge conflicts.

Every change comes with a test. New behaviour gets a new test, a bug fix gets a test that fails without the fix. There are about 1,250 unit tests and 21 Playwright end-to-end specs that register players, start matches, build walls, run sieges and check the phone layout. Every PR runs typecheck and the quick tests. Every push to main runs all tests and the Docker build before it deploys.

Every visual change comes with screenshots. Claude takes before/after screenshots and short clips with Playwright against a local server and attaches them to the PR. Reviewing a picture is much faster than reviewing a diff, especially for graphics.

We make the design calls. Our feedback was usually short and concrete: the walls are too weak, the knight looks like a toy, a horse doesn't move like that. Claude then figured out how to fix it.

Technical details

TypeScript monorepo with pnpm workspaces, about 80,000 lines:

packages/sim       deterministic game simulation (no DOM, no clock, no Math.random)
packages/content   buildings, units, recipes, balance tables as typed data
packages/protocol  binary snapshots and deltas, shared by client and server
packages/ai        the AI opponents
apps/server        Node, WebSocket, PostgreSQL, matchmaking, replays
apps/client        React HUD and three.js renderer

Deterministic simulation. Positions are integers in 1/256 of a tile, random numbers come from a seeded RNG stored in the world state, and entities are always processed in the same order. The same start state and the same commands produce the same world, which tests check with a hash. Replays, reconnects and live spectating all use this: they replay the command log.

Server-authoritative netcode. Each match runs on the server at 10 ticks per second in a worker thread. Clients send commands, the server validates them and sends binary deltas back. Each player and their allies get their own delta stream that only contains what they can see. Fog of war is enforced on the server, so a modified client has nothing hidden to reveal.

Large battles. A match allows up to 10,000 soldiers. Soldiers given the same order share one pathfinding result, so 1,000 of them start moving after 0.2 seconds. In our benchmark, two armies of 2,000 take about 18 to 22 ms per tick on the server, against a budget of 100 ms.

3D without a 3D artist. Buildings, walls, terrain, water and fire are generated in code with three.js. The characters started as AI-generated rigged models. Claude wrote a Blender Python script that cleans them up, attaches weapons and shields, selects the animations and exports a compact binary format. The animation data is stored in a texture, so the GPU animates the soldiers and a few thousand of them still run smoothly.

AI opponents. Four strategies: a defensive one, a trader, a raider and a siege specialist. They differ in castle layout, when they attack, how many troops they keep at home and which units they build. We balance them with a headless benchmark that plays every pairing on several maps from both starting positions.

The rest. PostgreSQL, OpenSkill for matchmaking (visible ranks from Squire to Emperor), ranked 1v1, 2v2 and 4-player free-for-all, clans, knockout tournaments, live spectating, replays, an offline mode against up to seven AI opponents that saves when you leave, a three-mission tutorial, and German and English.

What we learned

The code was rarely the bottleneck. Deciding what we wanted was. Small, specific requests with a screenshot of the problem worked much better than large, vague ones.

Anything we had to say twice went into CLAUDE.md. After that, new threads followed it without reminders.

Tests are what allowed us to merge this fast. Most mistakes failed a test before anyone played them.

Our end-to-end tests render real 3D in headless browsers with software WebGL. That got too slow for the CI runners, so the full end-to-end suite now runs on demand instead of on every deploy.

Closed beta

We're looking for players who build strange castles, find exploits, start 8-player matches and tell us what breaks. Developers and strategy game fans are very welcome.

Join the waitlist on kingdomsofsand.com. Leave your email address and we'll send you an invite code.

If you have questions about the stack, the netcode or working with Claude on a project like this, ask in the comments.