한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game Lag White Paper › Netcode design

Server rejects after client-side feedback Client-side feedback rejected by server

Cause ID sy-optimistic-reject · Primary owner Game team (Client development) · Also Game team (Server development)

Open the interactive card with figures and simulations →

When the server later refuses a hit or skill your screen already showed, the result you clearly saw never happened.

Why Hit effects and skill animations play before the server confirms (client-side feedback) → Effect The server rechecks range, target position, cooldown, and resources and rejects the action → On screen Blood sprays but there’s no damage, the skill animation plays with no effect, only the cooldown runs

Symptoms
Dropped action / rollback, Rubber-banding
Factors
Latency
Who’s affected
Just me, One feature only
When
During specific actions
Owner
Primary owner Game team (Client development) · Also Game team (Server development)
Game team action items
Client: show only what needs confirming (damage numbers, deaths, rewards) from server results, check common rejection reasons locally first, when rejected refund the cooldown and resources and show the reason. Server: leave slack for ping in range and target position checks, include the reason in rejection responses, collect rejection rate per skill as a metric.
Ballpark numbers
The rejection arrives ping + tick wait after the press. At 150 ms ping, you think you hit for about 0.2 s.
On the graph
Outliers only · Server rejection rate per skill (by ping bracket)
Where to look
Server-side rejection rate and rejection reasons (range, target position, cooldown, resources) per skill, broken down by player RTT bracket. On the client, a count of actions shown with client-side feedback that were then rejected
Confirmed if
Rejections concentrate on specific skills with range or target position as the reason, and the rejection rate rises with ping
Ruled out if
Rejection reasons are cooldown or resources and unrelated to ping: check whether client and server data values (cooldown, cost) differ. No rejections but feedback starts only after the server responds: points to “Feedback only after the server responds (request-response)”
Check with
Game server or client logs and metrics
Learn more
Client-side feedback is the best way to hide ping. However, the more the information the client and server use to decide (enemy position, remaining resources) differs, the more often rejections happen. Collecting rejection rate per skill as a metric makes it easy to find where the calls disagree.

Sources

  1. Using Gameplay Abilities in Unreal Engine Epic Games
    Local Predicted abilities run immediately on the client, but the server makes the final decision and can reverse the result
  2. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
    Weapon fire is predicted on the client and its effects play first; server results then correct prediction errors

See also

Same layer: Netcode design

Same symptom (Dropped action / rollback), other layers

View the interactive card with figures and simulations