2026-05-08

The replay surface looked like UI polish until the timing changed.

Bichess games already had an event log. That was enough to reconstruct board states, add a canonical replay route, link directly to a ply, and show White, Black, and Truth views after the game. But the first replay experience still felt like a generated animation over data, not a review of a game that had actually happened.

The missing input was time.

Autoplay originally had to invent pacing. Every move became roughly the same kind of beat, because the replay knew the order of events but not the rhythm of the room. That flattened the useful signal. A fast tactical sequence, a long think, a scramble after a capture, and a final move all became interface ticks.

The later replay pass uses recorded move timing when it can. For each ply, the delay comes from the move event timestamp relative to the prior move, falling back to computed pacing only when the event data cannot answer. That same pass rounded out the review controls: first, previous, next, latest, ply links, orientation controls, postgame reveal, and live-room replay after game over.

That work also changed what had to be persisted. Started games and PvE games needed to be durable enough to appear in replay lists, not just completed records that happened to survive the happy path. The replay route stopped being a debug affordance and became part of the product’s memory.

The lesson is not that realistic autoplay matters aesthetically. The lesson is that review tools inherit the semantics of the source artifact. If the artifact contains time, throwing it away makes the replay less truthful. If it does not contain time, the product will quietly invent a story about how the game felt.

An event log that supports replay is not just a list of states. The timestamps are part of the game.