Olympus | Mihael Fugaj

A climb the server can't see

Olympus is a 30-floor tower you climb in the browser, and how high you get is your score. The browser is the player's own machine, so nobody else could take its word for the score.

Pixel-art tower in a narrow portrait frame. A small climber is in mid-air beside a plank partway up, and two chips at the top read 'Floor 14' and 'Rooftop in 2'. — The climb: 30 floors, played in the browser. Sample run.

A secret level can't be played

The first plan kept the level's seed secret on the server, sent only its hash, and checked the score at the end. That cannot work: the browser has to build the same tower to let you climb it, and the first prototype also moved by frame time and used unseeded randomness for the lightning, so the same seed and the same key presses could play out differently on two machines.

Diagram with two boxes. The left box, "What the browser needs to draw the tower", shows a tower of planks and orbs and the words "every plank, gap and orb". The right box, "What a secret seed hides", shows the same planks and orbs as dashed outlines behind a padlock, and the words "exactly that". A crossed-out arrow joins the two boxes. — To play a level, the browser has to know it.

Replay the climb instead of trusting it

I rejected both a trusted score and a secret level. The browser sends which button was held on each frame, two bits per frame, with the state hash at each stop, and the server re-runs the climb with the same engine; the replay is the result. The map is public on purpose because the challenge is playing it. What each pickup turns out to be comes from a second seed, locked in by its hash before the climb and revealed only in the response that ends the run.

Two-lane diagram. In the top lane a public layout seed, known from the start, feeds both "Browser builds the tower" and "Server builds the same tower". In the bottom lane a reward seed, of which only the hash is shown, leads to "Moves sent, rooftop by rooftop" and then "Run ends: seed revealed, checked against the hash". Underneath, a strip of 17 frame cells from a test climb marked 2 (right), then 3 (push), 0, 0 (none) and 1 (left), with a key: 0 none, 1 left, 2 right, 3 push. — Two seeds: one anyone can see, one locked until the run ends.

Changing the rules without breaking old climbs

When we changed how pickups are chosen and made planks break on the third landing in a row, we hit the catch in our own design: any rule change changes the state hash, so a climb recorded under the old rules no longer replays under the new ones. The fix: each run pins its engine build and its rules, the old build is kept byte for byte, and the new pickup roll still draws exactly one random number per floor at the same point as before, so a seed builds the same tower under both rule sets.

Table for one test climb (seed 1, same inputs, 1,431 frames to the first rooftop at floor 5). Under the old rules the state hash after the first rooftop is 59ff2f49; under the new rules it is ac8394f4. A box below reads: 0 mismatches in 597 segments, old build vs new code, on the old rules. — The same moves under two rule sets give two different hashes, so every run carries its own rules. Test climbs played by the autopilot.

Change one key press and the check fails

The physics uses whole numbers only (positions in 1/256 of a pixel), runs at a fixed 60 steps a second with seeded random streams, and hashes the full state at every rooftop stop. In a recorded test climb that reaches floor 15, we changed one frame out of 4,490 from right to left: the replay falls on floor 4 instead of reaching the floor-5 rooftop, and the check fails.

Two terminal panels, one above the other. The top one replays a test climb: three segments marked ok, ending in MATCH. The bottom one replays the same climb with one frame changed: segment 0 MISMATCH, fall at floor 4, ending in MISMATCH. Frame counts are running totals, as the tool prints them. — Real output of the replay check. Test climb played by the autopilot; below, one frame is changed. Frame counts are running totals, as the tool prints them.

The score is recomputed, not trusted

The server no longer decides how high a climb got. It recomputes it from the inputs, and the same replay can be run again from the same inputs. Every number below comes from a command that can be run again at the commit named under the numbers.

As of commit 5f70ddf, 22 Oct 2026.

10of 10

recorded test climbs replay to the exact recorded state hash at every stop (4 under the old rules, 6 under the new)

0

mismatches between the archived old engine build and the new code on the old rules, over 597 climb segments from 300 seeds (plus 300 random-input climbs)

800

automated tests passing: 41 engine, 759 Worker (26 of them on run start, replay and reveal)

28,106bytes

the whole engine, one file with no runtime dependencies; rebuilding it gives the same bytes

Sources: the replay tool run on each of the 10 recorded test climbs, a comparison of the archived old engine build with the new code (node --experimental-strip-types showcase/proof/difffuzz.mjs "$PWD", committed in Olympus commit 865d594), the engine and Worker test suites (pinned at commit 5f70ddf), and a rebuild of the engine file. Test climbs were played by the autopilot.

Replay proves the moves, not the hands

A replay proves that these inputs reach this floor. It cannot prove a person pressed them, so a bot that plays in real time would pass it. Climbs are checked against real time and summit climbs are looked at by a person, but I won't call it bot-proof. The next gap to close is a recorded test climb that reaches the summit: as of 22 Oct, the deepest one ends on floor 15.

Three-row table with the columns check, stops, and does not stop. Final segments stop retries but not searching ahead. The real-time floor stops sped-up submissions but not a real-time bot. Summit review by a person stops an unnoticed automated summit and nothing else. — What each check stops, and what it doesn't.