Skip to content

Simulation you can trust

Written 2026-10-27 from the project's own design docs.

The principle: a game's rules should live in exactly one place, run the same way everywhere they run, and be backed by checks that are proven able to fail. Then the server can be the authority, cheats can be rejected, and automated play can find what's broken before players do.

This is as much a design principle as an engineering one. Rules that are scattered, or that quietly differ between the client and server, are rules nobody can reason about.

Rules in one place

  • One rules library, called by everything. In The Crawl, the season and death rules live in one library; the server, client and bots call it and "never re-decide a rule". In Fboard, the skating physics, tricks and scoring live in a simulation library with no game-engine dependency, so a future server can run exactly what the client runs.
  • The simulation as a pure function. Fboard's simulation advances one rider by one fixed tick (60 per second) from its current state and a device-independent input. Things like "the button was just released" are worked out inside the simulation from the previous tick's input, so the result depends only on state and input.
  • What you see is what you collide with. Fboard builds its level meshes from the same data the physics uses, with a test to check it. The Crawl generates its floors from a seed in a shared library, so server, client and bots agree on the map without sending it over the network.
  • Name the gaps instead of filling them. Where The Crawl's design was silent, the code marked an ASSUMPTION and listed it for the founder rather than quietly choosing. Several of those became explicit rules later.

The server decides

In an online game, anything a cheat could fake (positions, deaths, loot, eligibility) should be decided or validated on the server. The client shows things; it doesn't decide them. The Crawl's slice demonstrates the basics: the server rejects a move into a wall and a 200 m jump, and accepts a legal move. Its known gap is also written down: a move through a thin wall between two position updates isn't caught yet.

Determinism: what it buys and what it costs

A simulation is deterministic if the same starting state and the same inputs always produce exactly the same result. That unlocks a lot:

  • Replays that are just a seed plus inputs.
  • Validation: a server can re-run a player's recorded inputs and trust only the outcome it computes itself, so editing a save file achieves nothing. The Crawl analysed exactly this for an offline mode.
  • Debugging and broadcast playback from the same recordings.

Fboard built it. Its replays store per-tick input with state-hash checkpoints (fingerprints of the game state), and headless and on-screen runs agree bit for bit; a one-tick edit to an input is caught.

The costs are real, and both projects record them:

  • It's a discipline from the first line. Fixed tick rate, seeded randomness, no clock reads in game logic. The Crawl's analysis called it very hard to retrofit.
  • Cross-machine determinism is harder still. Floating-point maths can differ between processors and compilers. Fboard's networking plan rules out lockstep (where every machine runs the same simulation from shared inputs) for exactly that reason: its simulation uses ordinary floating-point maths and trigonometry, which "aren't bit-identical across CPUs and compilers". It plans server authority with client-side prediction instead. Making replays agree on one machine is not the same as making them agree on every machine.
  • Determinism proves what happened, not who did it. The Crawl's analysis: replay validation can stop tampering, but no method, offline or online, can stop bots or tool-assisted play. "We can prove what happened in a run, not who or what was pressing the buttons."

Checks that can fail

A test that has never failed might be unable to fail. Both projects prove their checks:

  • The Crawl's rules tests were each broken on purpose and seen to fail: removing the B-Roll lag, letting generic characters respawn, removing an index key, disabling collision. Its 38 combat tests were each shown to fail when their rule was broken.
  • Each Crawl rule has a test named after its rule ID, so a design rule and its proof are linked.
  • Fboard's replay check catches a one-tick edit to an input.

Let bots find the exploits

Automated play is a design tool, not just a test tool.

Fboard built a TAS tool (tool-assisted speedrun: a program that plays under strict, human-like input limits but with perfect planning). Searching for high scores, it found:

  • Scoring was unbounded and quadratic. Every trick raised the combo multiplier, repeats included, so a flat chain of simple tricks scored about four times a showcase route through the level.
  • A run never ended while a combo continued past the buzzer; the same chain reached hundreds of millions of points at ten minutes.
  • Speed exploits on ramps that pumped speed well past the normal cap.
  • Generous spin rounding: a 130° spin landed as a 180°.

None of that was visible from reading the rules. A player optimising for score would have found it eventually; the bot found it first. The Crawl used bots differently, as a crowd for load tests, which showed that how clients subscribe to data mattered as much as how many there were.

Where this came from