Claude of Tanks: a browser-native Three.js armored combat simulator with plate-level armor

What Claude of Tanks actually simulates, and for whom

The problem this project addresses is narrow and specific: running armored combat with physical shell travel, armor geometry, component damage and spotting in a browser tab, without Unity, Unreal or a WebAssembly engine port. The README frames the result as "browser-native armored combat built with Three.js", and the repository layout supports that claim: there is no engine dependency in the top-level entries, only src/, public/, server/, api/, cloudflare/ and a Vite config. The audience is therefore twofold. First, engineers who want to read a working implementation of plate-level armor and ballistics in TypeScript. Second, players who want that simulation without an install step, since the homepage is a hosted build and the README advertises mouse and keyboard plus complete touch controls with safe-area layout.

The scale the README reports is unusual for a hand-built renderer. It claims 171 production-visible and 208 keyed local-development procedural vehicles across 210 saved roster records, 30 authored battlefields, and zero GLB-sourced playables. That last number matters more than the first two. A fleet built from procedural specifications rather than imported models means armor values, module layout and damage behaviour can be derived from the same data that draws the tank, which is exactly what the Tank Gallery export path depends on. It also means the visual fidelity ceiling is set by the procedural generator, not by an artist's mesh.

The fixed 60 Hz authority behind the shooting

The mechanism the README describes is a split between authority and presentation. Movement, ballistics, armor, damage, spotting, bots, destructibles and the match result all run at a fixed 60 Hz on the authority side. Presentation is a separate concern: a direct Three.js and WebGL renderer with adaptive quality, SMAA and FSR, shadow handling and GPU recovery. That separation is the reason the project can claim a "measured 120 FPS test path" while the simulation itself ticks at 60 Hz. The renderer is allowed to run ahead or fall behind; the simulation is not.

Armor resolution is described as plate-level, which in practice means a shell is tested against armor geometry rather than against a single hit-point pool per vehicle. Internal damage and modules sit behind that: the README lists component damage, guided missiles and magazine autoloaders as first-class systems, and the Tank Gallery can isolate armor or internal anatomy on a live rig. Spotting is also part of the authority tick, which is the design choice that keeps a match result reproducible. If spotting were computed on the client from whatever the renderer happened to draw, two machines with different quality settings could disagree about who was visible.

The honest caveat is that all of this is self-reported. The README does not publish a methodology for the 120 FPS figure, and the repository does not include a benchmark result file in the top-level entries. There is a perf:terrain-stream script and a perf:garage-entry probe in package.json, so measurement tooling exists, but the numbers themselves live in the README rather than in a committed report.

Installing Claude of Tanks and getting a first battle running

The README does not spell out a local development install in the excerpt available, but package.json gives the project name and script surface, and the presence of vite.config.ts plus a standard Vite layout means the usual Node workflow applies. The repository is marked private in package.json, so it is not published to a registry; you clone it. The scripts are invoked with node directly, which is consistent with the TypeScript entry points under scripts/.

Start by installing dependencies and launching the Vite dev server from the repository root:

npm install
npm run dev

Vite will print a local URL. Opening it should give you the same game shell as the hosted build, with the Garage, Gallery and Scene Studio routes reachable from the navigation. If you want the full local vehicle archive rather than the production-visible subset, the .env.example file documents a development switch. Copy it into place first:

cp .env.example .env

The switch itself is a browser-visible Vite variable, and the comment in .env.example is explicit that this is "a development switch rather than an authentication key" and that production builds ignore it even when present:

VITE_COT_DEV_FLEET_KEY=claude-of-tanks-local-dev

Restart the dev server after setting it. The README's own numbers give you a way to confirm the switch worked: the production-visible fleet is 171 vehicles, while the keyed local-development fleet is 208, so a larger roster in the Garage is the expected result. For a first real use, open Tank Gallery rather than a battle. Selecting a vehicle there and isolating the armor or internal anatomy shows you the same specification the combat simulation consumes, which is a faster way to understand the data model than watching a match. The README also describes exporting an "exact-surface review packet" from that same view.

Where the multi-agent provenance becomes a real limitation

The README states the project was built end-to-end by a multi-agent Claude and Codex pipeline, and the top-level entries confirm an unusual amount of agent infrastructure: .agent-docs/, .agents/, AGENTS.md, SKILL.md, skills-lock.json and gt-lock.json. That is interesting as a case study, but it has a practical cost for anyone adopting the code. There is no conventional contributor guide in the excerpt, no changelog, and no released versions: the releases field is empty. package.json pins the project at 1.0.0 while the README describes a fleet count that has clearly moved since. When the documentation and the data disagree, the data wins, and you have no version tag to tell you which snapshot you cloned.

A second limitation is the provenance gate. The README reports 7 tracked external comparison models with exact source records, and states that comparison inputs are never a playable loading path and are stripped from public builds. That is a deliberate licensing control, and it means the repository contains assets that are not part of the shipped game. If you fork this, you inherit the obligation to keep those two paths separate. LICENSE-POLICY.md, NOTICE.md and the LICENSES/ directory exist precisely because that boundary needs documenting.

The wrong-tool case is anyone who wants an engine. Claude of Tanks is a game with a simulation inside it, not a simulation library with a game on top. There is no published API surface, no npm package, and no stability contract. If you need armor and ballistics as a dependency in your own product, you will be copying source out of src/ and maintaining it yourself.

Claude of Tanks compared with a physics-engine approach

The obvious alternative is to reach for a general physics engine, such as a WebAssembly build of a rigid-body solver, and let it handle collision while you layer armor rules on top. The difference in approach is fundamental. A general solver gives you contact manifolds, restitution and constraints, and you then have to decide what a contact means for armor. Claude of Tanks inverts that: the README describes armor, ballistics, damage and spotting as authority systems ticking at a fixed 60 Hz, with the renderer as a separate presentation layer. Armor is a first-class simulation concept, not something inferred from a collision event.

That inversion buys determinism. A fixed tick with authority-owned results is the reason the README can advertise "authority-owned results" for multiplayer rooms alongside solo bots and LAN rooms. A rigid-body solver running at a variable timestep makes reproducible match results much harder, and replay or capture tooling depends on reproducibility. It costs flexibility. You get the vehicle behaviours the project implemented: terrain-following suspension, magazine autoloaders, guided missiles, destructible structures and persistent wrecks. You do not get arbitrary rigid-body interactions, and you cannot swap in a different solver without rewriting the authority layer.

A second alternative is simply playing World of Tanks in a browser wrapper or a cloud-streamed client. That comparison is not really about code. The difference is that Claude of Tanks runs its own renderer and simulation client-side, which is why the README can list desktop and mobile with touch controls as a supported platform rather than a streamed one.

Licence, self-hosting and the upgrade cost you are taking on

The repository is MIT-licensed, which is permissive and compatible with commercial use, but the presence of LICENSE-POLICY.md, NOTICE.md, LICENSES/ and a provenance gate tells you the MIT grant covers the project's own code, not necessarily every asset that passes through the repository. The README's own framing, that external comparison models are tracked with exact source records and stripped from public builds, is the mechanism that keeps those two categories apart. Read LICENSE-POLICY.md and NOTICE.md before redistributing anything from public/, and treat the 7 tracked comparison models as a category you must handle separately. None of this is legal advice; it is a description of what the repository documents about itself.

Self-hosting is supported and documented. .env.example describes a "complete first-party Docker deployment" via compose.selfhost.yaml, with COT_SITE_ADDRESS, COT_HTTP_PORT, COT_HTTPS_PORT, COT_PUBLIC_ORIGIN, COT_TURN_EXTERNAL_IP and COT_TURN_REALM as the configuration surface. The comment is blunt about the constraint: localhost defaults work for a one-machine smoke test but cannot relay peers across the internet, because TURN needs a reachable external IP. Multiplayer hosting is a separate story again, with compose.multiplayer.yaml, Dockerfile.multiplayer and docs/MULTIPLAYER-HOSTING.md, plus a choice between Cloudflare TURN and a self-hosted coturn. The TURN shared secret is explicitly a server-side value, not a VITE_ variable, which is the correct split and worth noting because getting it wrong would expose relay credentials to every client.

Upgrade cost is the weak point. With no released versions and a last push on 2026-09-15, there is nothing to pin against. You either track main or you fork and freeze. The repository does ship release gates and self-test scripts, including balance:check, test:seo, test:public-copy and qa:maps, so there is a way to tell whether a given commit is internally consistent. Running those is more informative than reading the README's headline counts.

Editorial conclusion

Adopt Claude of Tanks if you want a readable, MIT-licensed reference for how a browser game can resolve armor plates, ballistics and spotting at a fixed 60 Hz without a commercial engine, or if you simply want to play armored combat without installing anything. Do not adopt it if you need a stable engine API to build your own product on: the repository is a game, not a library, package.json marks it private, and the README describes a multi-agent pipeline rather than a versioned surface. Before committing, verify the deterministic capture tooling under tools/ and the exact-surface review export in Tank Gallery, because those are the pieces that decide whether the simulation is reproducible for your own use.

Frequently asked questions

Official sources

1. Issues
2. Kevin-Liu-01/Claude-of-Tanks on GitHub
3. License: MIT
4. Project website
5. README