Design Action-Game Frame Synchronization With Prediction, Authority, and Rollback

An action game sends player transforms every render frame. It looks smooth on a local network, but under 80 ms latency the owner feels delayed, remote players jitter, and a modified client can report impossible movement.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: separate render and simulation clocks, sequence player inputs, keep a rollback history, reconcile against server authority, and smooth remote actors.

What the symptom narrows down

• Render FPS is incorrectly treated as the authoritative simulation and network send rate.
• The client sends final positions instead of sequenced inputs the server can validate and reproduce.
• Every small server difference causes an immediate visible snap rather than bounded reconciliation and smoothing.

The branches are ordered to protect the strongest evidence around this possibility: render FPS is incorrectly treated as the authoritative simulation and network send rate. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Real-time game networking is a timing and authority problem; render frames, simulation ticks, input packets, server updates, and persistence do not need the same frequency, but their ownership and buffers must be explicit; in this guide, the practical goal is to separate render and simulation clocks, sequence player inputs, keep a rollback history, reconcile against server authority, and smooth remote actors.

Evidence to collect before the fix

1. Define separate render, fixed simulation, input sample, and server snapshot rates, plus the bandwidth budget per client.
2. Record input sequence, simulation tick, acknowledgement, predicted state, authoritative state, and correction magnitude.
3. Replay a recorded input stream on client and server to test determinism or explicitly quantify acceptable divergence.
4. Emulate latency, jitter, duplication, reordering, and loss while graphing correction rate and rollback depth.

The sequence moves from observation toward intervention. Preserve the result of the final check—emulate latency, jitter, duplication, reordering, and loss while graphing correction rate and rollback depth—because it provides a useful comparison after the repair.

Apply fixes in the safest order

1. Run gameplay at a fixed timestep; send compact sequenced inputs and let the authoritative server validate and simulate them.
2. Predict the owning player locally, retain unacknowledged inputs, then restore the server state and replay remaining inputs after a correction.
3. Interpolate remote snapshots behind real time and reserve hard snaps for teleports or errors beyond a defined threshold.

Before applying “Run gameplay at a fixed timestep; send compact sequenced inputs and let the authoritative server validate and simulate them,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can test movement, collisions, abilities, and moving platforms under a matrix of latency, jitter, and packet loss; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Prove recovery

• Test movement, collisions, abilities, and moving platforms under a matrix of latency, jitter, and packet loss.
• Confirm the server rejects speed, timestamp, and impossible-state manipulation without penalizing ordinary jitter.
• Measure server frame p99, correction distribution, bandwidth, input-buffer age, and visible snap rate.

One successful refresh is not closure. Keep the incident open until you can also confirm the server rejects speed, timestamp, and impossible-state manipulation without penalizing ordinary jitter, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Capture build and protocol versions, region, match size, simulation and send rates, latency/loss/jitter profile, correction count, server frame time percentiles, bandwidth per client, disconnect reasons, and load-generator saturation; include the result of this first observation: define separate render, fixed simulation, input sample, and server snapshot rates, plus the bandwidth budget per client.

State what was tested, including the result of “Define separate render, fixed simulation, input sample, and server snapshot rates, plus the bandwidth budget per client,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

void OnServerState(ServerState authoritative) {
    state = authoritative.player;
    pending.RemoveAll(i => i.sequence <= authoritative.ackSequence);

    foreach (InputFrame input in pending) {
        state = SimulateFixedTick(state, input, fixedDelta);
    }

    visualCorrection = predictedTransform.position - state.position;
}

Shortcuts that create a second incident

• Do not trust client positions for authoritative collision or combat.
• Do not promise lockstep determinism when engine physics, floating point, or third-party code has not been proven deterministic.

Primary references

• Unreal networked character movement — official reference consulted for this guide.
• Unreal Mover and network prediction comparison — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Run gameplay at a fixed timestep; send compact sequenced inputs and let the authoritative server validate and simulate them”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.