OpenFront Seekable Replay Viewer (v0.35.0): Enable It, Seek Any Moment, and Review Without Rewatching

Direct answer: turn on “New Replay Viewer” in settings, then open any finished game to seek it

The v0.35.0 release replaced the linear, watch-from-the-start replay with a seekable viewer, and it ships opt-in: with the setting off, “Watch replay” still opens the classic replay, and the only way past that is the New Replay Viewer toggle in the settings menu (it reads settings.replayViewer, default off). Once it is on, every finished game you open from the game history goes into the viewer instead. The viewer works by processing the game’s archived record once, in your browser, on the engine’s own worker — the same worker live games use — and after that single pass, every jump on the timeline is a roughly 20 ms seek, because the whole game is already decoded and sitting in local memory. Keyboard control is minimal by design: Space toggles play and pause, ArrowRight and ArrowLeft step one frame forward or back, and holding Shift jumps 100 frames at a time. The speed menu offers 0.5x, 1x, 2x, 4x, 8x, 16x and 32x. There is also a direct link form, #replay-viewer=<gameID>, that opens the viewer even when the setting is off — which is how you can hand someone a link that lands straight in the seekable view. Nothing about this feature runs on the server; the server only supplies the archived record. If you take one action from this page, make it this: enable the toggle once, open a long finished game from your history, and let the processing pass finish before you judge it — the first open is slow by design, and every later open of the same game on the same machine is near-instant because the processed replay is stored in IndexedDB. One honest expectation before you start: the viewer is a review instrument, not a new way to spectate live games. It works on finished matches only, it adds a processing step the old path did not have, and it asks your browser for real memory — the store caps the decoded archive at 256 MB so a weak device is protected, and a very large game that would exceed its practical budget simply will not decode in a session where the browser cannot afford it. That is a deliberate ceiling: the product is “re-open a finished game and jump to the minute that matters,” and for that job the opt-in, local, server-free design is exactly right — you keep the classic replay as a fallback, pay the one-time processing cost only when a match is worth reviewing, and get a review instrument that turns hours of linear rewatching into a few minutes of targeted seeking without any change to how live games run.

Version boundary: what v0.35.0 changed, what it did not, and where the viewer still stops

Before v0.35.0, a finished OpenFront match could be re-opened only by re-running the live replay path: you joined the finished game by URL or from the lobby, and the client replayed it in real time the way you would have watched it live. That had three structural limits. First, it was linear — you could not jump to minute forty of a ninety-minute game without waiting through the first forty. Second, it had no speed control; the replay ran at the rate the simulation ran. Third, it had no integrity check of any kind, so you were trusting the record as-is. v0.35.0 changed all three: the record is now processed into encoded frames, the timeline is fully seekable, the speed menu spans 0.5x to 32x, and the processing pass verifies the hash checkpoints the live clients agreed on, stopping at the first mismatch. The v0.35.0 release also shrank the replay worker itself from 815 KB to 340 KB by moving replay processing onto the engine’s own worker. What v0.35.0 did not change is the determinism boundary: the core simulation is only deterministic within one build, so a record still only replays fully on the build that played it. A record from another build is routed to that build’s versioned shell at replay.<domain>/<gameID>, exactly as the v0.33.6 versioned-replay mechanism described in the changelog already handled. In practice this means: on the main site, a very old match may still open (through the shell or a stored copy), but the moment the record’s build no longer exists anywhere, the match is gone — the viewer does not resurrect records, it makes the still-available ones far better to watch. The “Catching up…” behavior during live play is a separate thing entirely: it is the deterministic simulation catching up to the server’s action stream after lag, not a replay feature, and the viewer does not touch it. All control values on this page — the 256 MB cap, the 10 ticks/second rate, the speed list, the ±1/±100 frame steps — are read from the v0.35.2 tag source, which is byte-for-byte the same replay code the v0.35.0 release shipped with. Two practical consequences of this boundary worth stating plainly. First, the seek speed itself depends on your machine, not the server: the ~20 ms figure is a measured median for a typical long game on the release’s test hardware, so a modest laptop seeking a 3-hour 25-player FFA will feel a little slower, and the first seek after processing is the heaviest one because the decoded frames are still being laid into memory. Second, the viewer inherits whatever the record contains and nothing more — it cannot show spectators who never existed in the record, and it cannot extend a match past its recorded end, so “what would have happened if” questions stay out of scope; the viewer answers what actually happened at minute 47, not counterfactuals. If your review needs the broader game context around a replay — which map, which economy curve, which nuke windows — the companion pieces in the v0.35 new maps overview and the v0.35 small economy and spawn boost guides cover the standing rules the replay is being judged against.

Decision framework: when the viewer pays off and when the classic replay is still fine

The first decision is easy: if you regularly re-watch matches to find the moment a decision went wrong, the viewer pays off immediately, because the single most expensive part of the old workflow — waiting through the parts you already know — is deleted. The viewer is built for exactly the review question the community kept asking in 2025: “can I skip to the time?” The second decision is about when to open a replay, not whether. Processing happens once per game, per machine, per build: the first open of a long game costs a processing pass — roughly 70 seconds for a 26-minute 25-player game in the documented benchmark, and that pass happens on your machine, not a data center — while every later open is a cache hit that loads the stored frames from IndexedDB and opens effectively instantly. So the rational workflow is to process a game once on the best machine you have available, and then seek freely from anywhere, including from a phone, where the stored replay loads without re-processing. The third decision is about storage budget. The store caps at 256 MB total across all stored replays, evicting the least recently watched first; the benchmark game stored at about 24 MB, so the cap holds on the order of a dozen long games, and once you exceed it, old entries are quietly removed as you watch new ones. If you review only a few games a week, the cap will never bite; if you treat every match as review material, expect your oldest stored replays to age out and be re-processed when you come back to them. The fourth decision is about what you do not need to do: you do not need to save files, export anything, or keep the tab open — the store is automatic once a replay finishes processing, and a replay that never finishes processing (for example, one that is cut off by a mismatch) is simply not kept. The classic replay is still the right tool in exactly two cases: when you want the minimal, dependency-light path on a weak device (it does not run the verification pass), and when you are watching a record so old it has already been routed to its versioned shell. A third, subtler case is the first time you open a given game on a weak or new device: the processing pass itself uses real CPU and memory, so on a low-end phone the classic path can actually open the finished game faster than the viewer’s first decode, and you can let the classic watch stand in while the viewer pass finishes in the background of your decision. The honest summary: the viewer is a strict upgrade for anyone who seeks, and a mild tax on one-time, watch-once viewers — which is precisely why it ships behind a toggle rather than forcing the extra work on every player.

Scenario one: the 3-hour 25-player FFA — finding one betrayal without rewatching three hours

Assume the situation the community thread described in November 2025: a long, high-player-count FFA that ran well past two hours, with a late-game collapse you suspect came from one specific ally breaking faith. With the classic replay, your review cost is the full duration of the game at 1x — roughly three hours of wall time, or a lot of patience with no speed control at all. With the viewer, the math changes. Open the finished game from your history; the viewer fetches the archived record and starts the processing pass on the engine worker. For a game of that length and player count, the processing pass takes on the order of one to two minutes on a modern machine, scaling from the documented 70 seconds for a 26-minute 25-player game; while it processes, the unprocessed tail of the timeline shows as grey, and seeking into grey snaps back — so do not try to jump ahead before the pass finishes. Once processing completes, the whole timeline is live. You work from the end: set the speed to 16x or 32x and sweep back from the finish, watching the territory and unit counts at a tenth of the cost, until the collapse window appears; drop to 1x for the decisive exchanges; use the Space bar to hold a frame while you read a unit count or a flag, and Shift+ArrowLeft to step 100 frames — ten ticks at the 10-tick-per-second rate — back when a single step undershoots the moment. The stored replay of a game this large lands somewhere in the tens of MB, which is well inside the 256 MB budget; the specific numbers depend on map, duration, and event density, but the benchmark gives you the scale: long, busy games cost real storage, short ones cost almost nothing. The review question you can now answer that you could not answer cheaply before is a causal one — which decision, made at which minute, produced the collapse — and the answer lands in minutes instead of hours. This is the entire product in one workflow: process once, sweep fast, zoom slow, verify the specific frame. And because the review question here is causal rather than cosmetic, the one output worth writing down is the exact game clock at which the betrayal became visible — not “somewhere in the third hour” but a timestamp your future self can seek to in seconds. In a 25-player FFA the record of who was allied with whom is implicit in behavior, so if the moment is ambiguous at 1x, the frame-by-frame step with the Space bar is the arbiter: hold the frame, read the flags and the unit directions, and only then decide whether the break was a premeditated strike or a forced retreat. That distinction — deliberate betrayal versus desperation — is what changes your next lobby’s alliance policy, and it is the kind of call the old linear replay made nearly impossible to make for a game of this length.

Scenario two: the mobile second pass — process on desktop, seek from the phone the next morning

The second scenario is the one that breaks the old version-lock pain pattern. You finish a competitive team match on your desktop the night before, with the viewer enabled, and you open it once so the processing pass completes and the replay lands in IndexedDB on that machine. The next morning you are on a phone and want to check one crossing. If the record’s build is still the current one, the phone’s openfront.io open of the same finished game will run its own processing pass — IndexedDB storage is per-device, so the desktop cache does not travel with you — and then the seek is available; on a phone the processing pass for a typical team match is short but real, so open it once and let it finish before you seek. The version boundary then does its work: if a site update landed overnight and the record’s build is no longer the live one, the main site routes the record to its versioned shell, and the shell preserves the old build so the replay still opens with the old rules — the same mechanism the November 2025 thread discovered on blue.openfront.io, now generalized to replay.<domain>. The practical rule: for a match you know you will want next morning, open it on your best machine the same night, before any update can land, and the record is pinned to a build you know exists. If the update has already landed, check whether the shell still hosts the build — very old builds eventually stop being hosted, at which point no client, new or old, can process the record and the match is unrecoverable. Treat the versioned shell as a grace period, not a vault. One more boundary specific to this scenario: the verification pass checks the hashes the live clients recorded, at a cadence of one checkpoint every 10 turns in multiplayer, so a multiplayer replay of a team match is checked densely — and if the record ever arrives without its hashes, the viewer flags it on screen with “This game’s record has no checks, so this replay couldn’t be verified against the game that was played,” and deliberately does not store it. An unverified replay is watchable but not trusted and not cached, which is the right trade: you would rather re-process a doubtful record than silently cache one, and the on-screen notice is precisely the signal that separates “I can look at this” from “I can rely on this” when the crossing you are checking is a claim about a match you care enough about to argue about the morning after.

Failure modes and countermeasures: what breaks, and what to do about it

The first failure mode is the build mismatch, and it is the most common reason a replay “doesn’t work.” A record only fully replays on the build that produced it; the viewer checks this before doing the heavy work and sends you to the versioned shell for other builds. Countermeasure: understand that “the replay stopped or redirected” is almost always a version problem, not a corrupted game. If you are on the main site and the record’s build is hosted, the shell opens it; if the build is gone from hosting, there is nothing on the client side that recovers it, so the only countermeasure is upstream — open and process the replay while its build is still hosted, and if you are the kind of player who archives matches, note the build in the shared link’s context. The second failure mode is the hash mismatch mid-processing, which means the record you fetched is not bit-for-bit what the live clients verified. The processing pass stops at the first mismatch, and by construction everything the viewer already sent you is still the real game — frames are only delivered once a later checkpoint matched — so the visible result is that the timeline ends early or a seek snaps back, and the viewer tells you the replay was flagged. Countermeasure: do not treat a truncated timeline as a rendering bug; it is the integrity check doing its job. If a record that should be clean keeps failing, fetch it again; the server record is the source of truth and a transient fetch glitch is the more likely cause than a broken engine. The third failure mode is storage pressure: the 256 MB cap with least-recently-watched eviction means your oldest stored replays disappear silently as you watch new ones. There is no per-game pin, so the countermeasure is workflow, not settings — if a replay matters, review it while it is stored, and keep a copy of the game’s ID and link so you can re-process it later from the record. The fourth failure mode is the chunk-load fallback: if the viewer’s own code chunk fails to load — a network error or a deploy that replaced it mid-load — the client logs the error and falls back to the classic replay with a full page reload, which also picks up the new deploy. You will not notice a bug here; you will notice a plain replay instead of the viewer, and the fix is simply to reload. The fifth failure mode is expecting live-play latency to change: the “Catching up…” banner in live games is the deterministic simulation replaying missed ticks and is not affected by the viewer at all; if that is your pain point, the viewer helps your reviews, not your live play.

Playback controls: the full keyboard and speed reference

The viewer is keyboard-first, and the whole control surface is small enough to be a table. The processing rate underneath is 10 ticks per second, so a frame is one tick of the simulation — ten frames is one real game-second — and every seek, step, and speed below is defined against that base.

A few notes make the table usable. First, the frame step is exact: at 10 ticks/second, a single ArrowRight is a tenth of a game-second, and Shift+ArrowRight is ten game-seconds — the 100-frame constant is chosen so a held Shift covers a meaningful span in a few presses. Second, the keys are deliberately ignored while a settings menu is open — the release notes call this out as a fix, so that hunting for the toggle mid-view does not accidentally scrub the timeline. Third, the speeds are multiplicative over real time, so 32x plays a 10-tick/second simulation at 320 ticks/second; the renderer and the decoded frames keep up, but treat 32x as a scanning speed for spotting where something happened, not a speed at which you will read unit counts. Fourth, seeking into the unprocessed tail is not an error condition to be alarmed by: the tail is grey precisely because it does not exist yet, and a seek into it snaps back to the last processed frame. The correct behavior is to let the pass finish, then seek; the viewer will not pre-empt it for you. Fifth, because the playback state is local to the viewer page, closing the tab mid-view loses the playhead but not the work — the stored replay remains in IndexedDB and the next open starts at the beginning with instant frame access, which is what makes the “open once, come back later” workflow described in the scenarios safe. Sixth, the same keys are dead inside the settings overlay: the release notes specifically fixed the case where pressing a seek key while hunting for a toggle would silently scrub the timeline behind the menu, so if your arrows seem unresponsive, check whether a settings panel is still open and dismiss it before scrubbing. Seventh, the speed choice is sticky for the session — it does not reset when you close the settings menu — which is convenient for the “sweep at 32x, then drop to 1x” pattern and only annoying if you forget you left it at 32x; when a replay appears to be flying by without you choosing to, that is the usual explanation. Eighth, and easiest to miss: because a frame is one simulation tick and the simulation runs at 10 ticks per second, the numeric frame positions you can read off the timeline are ten times the game seconds — so “frame 4700” is minute 7:50 of gameplay, and when you want to tell a teammate where to look, it is cleaner to give them the game clock than the frame number.

Mode and map adjustments: FFA, team, and singleplayer all get different value

The viewer is uniform across modes, but the value per open is not, because the review question differs. In 25-player FFA, the density of concurrent events is highest and the timeline is longest: a game with that many players produces more state change per second, so the processing pass is the heaviest, the stored replay is the largest, and the payoff of seeking is greatest — the whole point is to find one thread in a noisy game. Sweep at 16x or 32x, drop to 1x only inside the window you found. In team modes (1v1, 2v2, 4v4), the game is cleaner and the review question is usually tactical: a specific landing, a specific crossing, a specific nuke launch. The frame-level step is the right tool here — 10 frames is a real second, so you can land exactly on the moment and step through the follow-up tick by tick — and the replays are cheaper in both processing time and storage, which means you can afford to review more of them; the 256 MB cap holds many more team games than FFA games. In singleplayer, two things change. The hash cadence is coarser — one checkpoint every 100 turns instead of every 10 — so the integrity check is less dense, and the tail of a replay (the frames after the last recorded hash) has nothing left to check against; the docs are explicit that those final frames are sent as-is, which in practice is the last few seconds at most. The second singleplayer change is that the “record” can come from your own run, which means an unverified flag is more likely to be a real data gap than a fetch glitch; when you see the unverified notice on your own singleplayer replay, re-record the run rather than trusting the stored frames. Map size matters within modes: a big map with long trade routes produces more event history and a larger stored replay than a compact one at the same duration, so if you are near the storage cap and reviewing big-map FFA games, that is the first thing you should prune by simply watching newer, smaller replays. None of this changes the controls — the same table applies everywhere — it only changes where your review time is best spent. One cross-mode habit follows from the storage math: because team replays are cheap and FFA replays are expensive, a review-heavy week of FFA followed by a week of team play will naturally rotate the store in your favor, and you do not need to manage it manually — the least-recently-watched eviction does that, which is also why the “open the replay you care about today” habit is the whole storage strategy.

Review workflow: turn the viewer into a repeatable post-game habit

The viewer is a tool for evidence, and the habit that makes it pay is a fixed five-step pass you run on every match that matters. Step one: enable the toggle once — New Replay Viewer in the settings — and never think about it again; the one-time direct-link form #replay-viewer=<gameID> is your escape hatch for sharing a seekable view with anyone, including people whose setting is off. Step two: open the finished game from your history the same night, so the processing pass runs on your best machine and the replay stores while the build is definitely live — this single habit is the entire defense against the version-lock pain where a great game becomes unwatchable after an overnight update. Step three: let the pass finish before you seek, and use the grey tail as your progress indicator; if you are in a hurry, the pass is short for team games and you can step out and come back — the store does the remembering. Step four: sweep fast, then land slow: 16x or 32x to find the window, 1x to read it, Space to hold a frame while you check numbers, Shift+Arrow keys to move ten-second blocks — and write down the frame or timestamp of the moment you care about, because the playhead does not survive closing the tab. Step five: turn the moment into one testable change before the next match, which is exactly the review method the Replay Review guide codifies: find the first broken assumption at the moment you just located, and change one thing in the next lobby. That final step is what separates the viewer from a video player — the seek exists to answer “why did that decision fail at that second,” and the answer is only useful if it changes the next lobby. If your review question is about how you play in general rather than one match, the broader control surface in the Hotkeys guide is where the live-side habits live; this page owns the post-game side, from the moment a match ends to the moment you have one concrete next-match change. Everything above is grounded in the v0.35.2 source and the v0.35.0 release: the v0.35.0 release states the ~20 ms seek and the opt-in rollout, and the tag source pins the 256 MB cap, the 10 ticks/second rate, the 0.5x-to-32x speed list, and the exact keyboard behavior described in the table.