Offline validation (dropped)¶

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

What was asked¶

An early version of the season design let players play Floors 1–3 offline, on their own, and bring those characters into the online Main Show. The founder preferred that to forcing an always-online connection for single-player play, "but only if we can make it secure."

The question was whether a character built on someone's own machine could be trusted.

The analysis (the assistant's)¶

Bottom line:

• Secure against tampering can be done. Nobody could edit stats, items, levels or outcomes.
• Secure against bots and tool-assisted play can't be done, offline or online. You can prove what happened in a run, not who or what was pressing the buttons.

The method that works: deterministic replay validation¶

1. The offline game records the starting seed plus every input, tick by tick.
2. On reconnecting, it uploads that input log. It's small: kilobytes to a few megabytes per hour.
3. The server re-runs the whole simulation from the seed and the inputs, without rendering, faster than real time.
4. The character the server computes is the only one that counts. The player's own save file is never trusted.

Editing a save does nothing, because the save is ignored. Faking an input log just produces whatever those inputs would really produce. You can't fake an outcome, only play your way to one.

What it requires¶

• A bit-identical deterministic simulation on the player's machine and the server: the same code, a fixed tick rate, seeded random numbers, no clock reads in game logic, and floating-point maths that behaves identically on every machine. In practice that means fixed-point maths, or a physics engine with a cross-platform determinism mode. This is the main cost, and it's very hard to add later.
• The game's rules as one shared library that both the game and the validating server run.
• Server time for re-simulation. Floors 1–3 last 5, 6 and 8 days in the books, so re-running every offline character costs real compute. It could be capped by validating only characters that try to enter the Main Show.
• A version lock. A replay only validates against the exact rules version it was played on, so patching mid-season needs a plan.

What it doesn't stop¶

• Bots and tool-assisted play. Inputs can be generated by a program, or the game slowed down offline to play frame by frame. The replay is valid because it really happened. Timing checks, deadlines and caps on what an offline character can bring in all help; none of them is proof.
• Sharing a run. One good input log could be uploaded on several accounts. Tying the seed to the account fixes that, and also stops offline scouting of the live floors.

Weaker options¶

• Signed or encrypted saves always get broken, because the key ships inside the game.
• Client anti-cheat is intrusive, beatable and disliked, which contradicts "not a nuisance".
• Clamping stats on entry is simple and secure, but throws away what the player earned.

Why it was dropped¶

The founder chose to keep every floor online and accept the risk of scouting on Floors 1–3 instead.

What's still open¶

Determinism is no longer required, since nothing needs validating. It would still make server-side replays, debugging and broadcast playback much easier. Whether to build The Crawl deterministically is recorded as a separate, open build-path choice for the founder. The assistant's recommendation at the time was to build deterministically from the first line of code, because finding out later that you need it is extremely expensive.

The founder's other game, Fboard, did build deterministic replays. The general lesson is on Simulation you can trust.