Always record, keep only what you need — the rolling buffer approach to bug capture
Comparing deterministic replay, state snapshots, and rolling buffers — and how the rolling buffer, the easiest to bolt onto a game client, actually works.
- qa
- unity
- bug-report
Unity bug reporting, part 2 of 3 — ① Why reproduction fails · ② Always record, keep what you need · ③ A minimal Unity setup
The previous post ended here: you notice a bug only after it has happened, so the record button is always pressed too late. What you need is the t-30s window, and nobody is recording then.
That leaves one requirement. Every play session has to be recording, always. The question is how to actually run that. Writing whole sessions to disk is a real cost even on a QA machine, and almost none of those recordings are ever opened.
Three approaches
There are roughly three ways to get a moment back in a game.
| Approach | What it stores | What it requires |
|---|---|---|
| Deterministic replay | The input sequence | Randomness, physics, and networking all deterministic |
| State snapshot | A dump at one point in time | Serialization targets defined up front |
| Rolling buffer | The last N seconds of video, logs, state | A memory ceiling |
Deterministic replay has the highest fidelity — feed the inputs back and you get the same situation. The price is steep. Random seeds, physics steps, and network response ordering all have to behave deterministically, and that's hard to retrofit if the project wasn't built for it. One third-party asset calling Random on its own is enough to diverge.
State snapshots are light and easy to attach, but they capture a single moment after the fact. The t-30s window from the last post — how you got there — is missing entirely. It partly addresses lost conditions and does nothing for timing bugs.
The rolling buffer is the same idea as OBS's replay buffer. Fidelity is lower than deterministic replay, but it captures the t-30s window without imposing any structure on the project. For bolting onto an existing game client, it's usually the path of least resistance.
What a rolling buffer does
The mechanics are simple.
- keep the last N seconds in memory, continuously overwritten
- when someone sees a bug, commit that buffer to disk
- store video, logs, game state, and performance metrics aligned on one timeline
"Keep only what you need" is that second line. Recording runs constantly; disk writes happen only on commit. A ring buffer has fixed capacity, so memory doesn't grow over a multi-hour session, and any window you don't commit is simply overwritten. That's what keeps hundreds of never-opened recordings from piling up.
How large N should be depends on the bug. Frame races and UI glitches usually need only the immediate lead-up — 15 to 30 seconds is plenty. Bugs whose cause is further back, like quest state or accumulated inventory, want 60 seconds or more. In practice a 30-second default, tuned to the kinds of bugs your project actually sees, works well.
The shared time axis is the point
Of the three lines above, the last one is what actually changes how fast a bug gets diagnosed.
Video alone tells you what someone did, not what happened inside. Logs alone show the exception but not what the screen looked like. Kept separately, a developer has to line them up mentally — and that alignment work is reproducing the bug.
On a shared time axis, the questions change shape:
- which exception fired on the frame the screen froze
- whether GC ran just before the frame spike, or a load stalled it
- how many inventory items there were at the moment the UI broke
All of them answer by scrubbing the video and letting everything else follow. Instead of imagining the steps, a developer watches the moment again.
The ticket changes too. What used to be lost while translating a repro into prose never has to pass through prose at all.
That's the direction we took with Rekon: a rolling buffer running throughout Unity Play Mode, and one hotkey that saves the preceding window — video, screenshots, logs, and game state — as a single bundle. The argument here isn't really about a specific tool, though. It's closer to "a bug report should be something that remains, not something you write".
Once the approach is settled, the rest is implementation. The last post covers the minimum code to attach log and game-state capture to a Unity project.