A seed is only the beginning of a reproducible game

Pressing restart in Dino Arena regenerates the same course. That is useful, but it does not by itself reproduce the previous match. A jump applied on a different simulation tick is a different input, even if a human thinks they pressed the key at the same moment. A controller with leftover internal state can also make a different decision on an identical course.

I built the game around a narrower, testable contract: given the same simulation version, configuration, seed, and action sequence, the core should reproduce the same state evolution. The browser provides controls and pictures around that contract. Keeping those responsibilities separate makes a failed jump something I can investigate without treating the animation as the source of truth.

The core creates an immutable obstacle tape from a seed. Both lanes share that tape. A step advances a fixed simulation tick, and the renderer draws the resulting state. The core does not depend on React, Canvas, the DOM, wall-clock time, or Math.random. Its seeded randomness and state transitions belong to the simulation.

At the documented 60 Hz step rate, simulated time advances in fixed increments. A delayed browser frame can change when a person sees a picture. It should not change the duration of a simulation step. This separation is why the headless benchmark can call the same transition logic used by the game.

That is an architectural boundary, not a universal claim about every browser and machine. Input scheduling, numerical behavior, and code changes still deserve checks. The existing tests cover seeded determinism, controller replay, state isolation, and collision behavior. I do not have a cross-platform benchmark here establishing bit-identical results under every runtime.

The roster makes another boundary visible. It has eight entries, including Manual Sparring, so there are seven autonomous opponents. They range from a fixed-cadence hopper with no sensor access to Course Cartographer, which reconstructs the full seeded course. Between them are distance thresholds, time-to-collision estimates, a state machine, an analytical jump solver, and a bounded rollout controller.

Course Cartographer can plan with future obstacles that a nearest-obstacle controller cannot see. A better result from the cartographer could therefore reflect both planning and privileged information. Calling the whole roster a difficulty ladder is useful for play, but it is insufficient as an experiment isolating algorithm quality.

This distinction travels well beyond games. If one system receives a fuller context, a future schedule, or an extra tool result, its score combines the benefit of that information with the quality of its decisions. For a scientific comparison I would match the observation contract, or explicitly make information access the variable under study.

The environment adapter exposes reset, step, and serialization seams for headless work. That makes it possible to isolate a collision or controller decision from rendering. It also gives a future training loop an environment interface without requiring it to drive a browser. An interface ready for training does not mean a learned policy has been trained or evaluated.

The documented benchmark uses nine fixed seeds and reports normalized progress, clear rate, and ticks. The project page records the historical benchmark results. This article focuses on the contract behind that comparison: a score describes a controller together with its information budget, course generator, and tested seeds. It does not isolate algorithm quality or establish performance on unseen course designs.

The practical decision is to preserve the inputs to a result before arguing about the result. A repeatable obstacle tape lets me revisit a course. A complete execution contract lets me revisit a failure. Once the input stream and controller privileges are explicit, a benchmark has a chance to answer the question its title asks.