Some of the hardest bug reports we receive are also the shortest:

“That judgement was wrong.”

The player may be completely right, but the final judgement alone does not tell us where the problem happened.

An input passes through several parts of OutFox before it becomes a result on screen. The engine receives it from a device, maps it to the correct panel, relates its timestamp to the song, selects a chart object, applies the rules for the active game mode, and then updates scoring, life, effects and theme behaviour.

A fault anywhere along that route can make the final result look wrong. We are therefore designing a gameplay flight recorder for the newer timing and input systems.

This is not simply a replay file. Its purpose is to record enough information to explain how OutFox reached a particular gameplay decision.

That can include the input the engine received, how it was mapped, the quality of its timestamp, the chart position involved, which note or other object was selected, and why the resulting judgement was accepted or rejected.

It will also help with cases that are difficult to reproduce from a normal replay, such as held-state decisions, repeated input events, row crossings after a delayed frame, or timing changes around warps and seeks.

The first use is straightforward: inspect what a particular build observed and decided during the original play.

The longer-term use is comparison. The same recorded input evidence can be passed through a newer build to check whether it still produces the same result. If it does not, we have a much narrower place to begin looking for the regression.

This does not mean every unusual judgement is an engine fault.

The recording may show that a backend only provided estimated timing, that fallback behaviour was used, or that the input genuinely fell outside the active timing window. The important part is that we can distinguish those cases instead of trying to reconstruct them from a screenshot or a description after the event.

The gameplay flight recorder is still planned work, but all the StillRiver hooks are in place as we use them for debugging and testing at the moment, so it is a work in progress, rather than a completed player feature.

Its purpose is to make difficult timing and judgement faults easier to reproduce, explain and fix, without relying on either the player or developer to guess what happened inside the engine.