Skip to main content
PlayServ SDKV2PlatformV1
The live game

Not translated yet — showing English.

Predicting Your Own Motion

You act on your own input before the server has answered, and where the two disagree your client corrects itself. A mistake here costs a small visual correction and nothing else, which is why this is the one of the three prediction mechanisms it is safe to be aggressive about.

Prediction replays the declared rules, it is not a second copy of them

Your client does not run a parallel implementation of your movement. It runs the same declared model the platform runs — the model belongs to Locomotion, and prediction only applies it earlier. That is why the two sides agree most of the time: one set of rules, applied twice.

So there is no "predict" operation to call and no "correct" operation either. Prediction happens because the aspect was declared predictable.

What predicts is declared per aspect

Predictability is a declaration on the entity aspect, not a global switch:

  • An aspect the client can compute — position under your own input — may be predicted.
  • An aspect the authority changes by rules the client does not have must not be predicted. If the client cannot derive it, guessing at it produces a rollback the player reads as the game lying.

The correction protocol, and the two numbers that shape it

your machinethe server input applied at once, locally — the declared rules, run earlythe same inputthe same rules, laterthey agree — nothing happens, and you never knewthey disagree — your client is moved to the server
Your input applied at once locally, the same rules run later on the server, and your client corrected only where they disagree

Authoritative state arrives carrying the number of the last input it applied, so your client knows exactly how much of its own buffer is still unconfirmed. From there:

  1. Accept the authoritative state.
  2. Replay the buffered inputs that came after the one it acknowledges.
  3. Reconcile the result against what you were already showing.

Two declared numbers decide how that feels. The divergence threshold: below it the correction is smoothed, above it your client snaps and replays. And the unconfirmed-input buffer's bound: overflow is not undefined — the degradation is declared and observable, so a client on a bad connection knows it has stopped predicting rather than quietly drifting.

Divergence is observable to the client that had it, and only to that client. You can tell that your prediction was corrected and by how much — useful for tuning, and for showing the player an accurate connection indicator. You cannot read someone else's divergence: the size of a misprediction is information about their connection, not about the game. Correction is client-side, because the authority's state is what everyone else was already being shown.

If you are arriving from somewhere else

  • Unreal's Mover 2.0. The shape is familiar: tick-stamped inputs, a movement model, corrections from the authority. The difference is where the model lives — here you declare it and the platform simulates it, so there is no movement component of ours for you to subclass or replace.
  • Rollback-and-replay netcode, as in Photon Fusion. Replaying your own unconfirmed inputs after a correction is the same mechanism, and it is fully here. What is deliberately not here is re-running the world after the fact — see Lag Compensation for what happens instead, and why.

What this does not cover

Other players' entities are not predicted, they are displayed — that is Showing Other Players. Judging a shot in the shooter's timeline is a server mechanism and lives in Lag Compensation. And none of the three applies at all when the room's authority mode is external: then the tick belongs to whoever runs it, and so does the prediction.

← PreviousPrediction & Lag CompNext →Showing Other Players