The problem with browser game scores
In a browser game, the player controls the client. Anything the client sends, including a score, can be edited. The usual answers are to obscure the code or run the whole game on a server. ONE MORE takes a third route: the client sends what the player did, and the server re-runs the game to see what score that produces.
Making the game deterministic
Replay only works if the same inputs always produce exactly the same result on every device. The engine follows a few strict rules:
- Fixed timestep. The simulation advances in ticks of exactly 1/60 second; a full run is 3600 ticks. Rendering runs at whatever frame rate the device manages, but it never changes the simulation.
- Exact arithmetic only. The simulation uses addition, multiplication, division, square roots and flooring, which IEEE-754 defines precisely. Functions like sine and cosine can differ in the last bit between JavaScript engines, so they are never used in game logic.
- Directions from a table. Steering is quantised to 64 directions whose unit vectors are written into the source as literal numbers.
- Integer random numbers. Shards, hazards and power-ups come from a 32-bit integer generator (mulberry32) seeded per arena, so the arena is the same for every player with that seed.
What gets recorded
The client records only changes in input: a list of (tick, direction, dash) triples. Holding one direction for two seconds is a single entry. A typical run is a few hundred entries; the server rejects logs with more than 6,000 entries, ticks that go backwards, or directions outside the table.
What the server checks
- A server-issued run ID. Before a run, the server issues a single-use ID tied to the session, the arena seed and the twist. A run can only be submitted once.
- Replay. The server replays the input log with the same engine. If the result doesn't match the claimed score exactly, nothing is saved.
- Real time. A run that reports 60 seconds of play must have taken close to 60 seconds of wall-clock time between start and submission.
- Leaderboard integrity. Daily runs that took far longer than real time (long pauses, slow-motion play) or whose input log duplicates another account's are kept off the leaderboard but still count for personal stats.
- Version gate. Every rule change bumps the engine version; outdated clients are asked to refresh rather than produce scores under old rules.
A bonus: ghosts for free
Because a run is just a seed plus an input log, the same machinery lets a friend race your exact run as a translucent ghost. When you share a challenge, the server first re-verifies your recording before storing it, so a ghost can't be faked either.
What replay can't prove
Replay proves a score is possible from the recorded inputs. It can't prove a human produced those inputs: a bot that plays in real time would pass. That's why top Daily scores are also reviewed, why automation is banned under the Fair Play rules, and why prize events should verify finalists in person (see the tournament guide).