Outcome
The publisher demo shipped on its original date three weeks after engagement start, with zero gameplay-critical desyncs across the demo period, on an ability pipeline rebuilt from client-authoritative to server-authoritative with prediction.
Client name, project title and identifying detail are withheld under mutual NDA. Figures are as reported at handoff. Everything documented below is technique, which is the part that transfers.
Three Weeks Out
A multiplayer shooter had a publisher demo scheduled in three weeks and a build that desynced every few minutes of play. Abilities activated on the firing client and told the server afterwards. Damage was applied wherever the hit was detected, which was also the client. The server was, functionally, a message relay.
This is not an unusual state for a project that prototyped in single player and added networking later. It is fast to build, it feels responsive, and it is correct exactly until two clients disagree — at which point nothing in the system is empowered to decide who is right.
Three-week fixed runway to an external publisher demo. Existing UE5 project on GAS, dedicated server topology. Scope was explicitly the demo, not shipping hardening. Client withheld under mutual NDA.
The Authority Inversion
The rebuild inverted one rule: the server decides, the client asks. Every ability activation became a request. Every cost, cooldown and damage application became a server-side decision with a validation step attached.
Concretely, per ability:
- Activation moved to a server-validated path — the client calls
TryActivateAbility, and the server evaluates cost, cooldown, tag requirements and range before committing. - Costs and cooldowns applied through Gameplay Effects on the server, so the authoritative record and the replicated record are the same object rather than two systems that can diverge.
- Hit detection moved server-side. Client traces remain, but only to drive immediate cosmetic feedback; they no longer apply damage.
- Damage applied exclusively through Gameplay Effects with server-side sanity bounds on magnitude and range, so a malformed or hostile client request is rejected rather than trusted.
Client authority is not a shortcut that costs you security later. It costs you the ability to resolve a disagreement now, which is why the symptom is desync long before anyone tries to cheat.
The Prediction Boundary
Server authority alone would have made the game correct and unplayable. At any real ping, waiting for a round trip before an ability visibly starts is felt immediately as input lag. Prediction is what makes authority survive contact with players, and where the prediction boundary sits is the actual design work.
The rule applied, and documented for the team:
| Predicted on the client | Confirmed by the server |
|---|---|
| Ability activation and animation start | Damage application |
| Cooldown visual start | Elimination and score |
| Local VFX, SFX and camera feedback | Ammunition and resource consumption |
| Predicted movement effects | Anything granting or removing a persistent item |
The boundary is drawn by cost of being wrong, not by how responsive a thing feels. A prediction that turns out wrong should cost the player a corrected animation — never a resource they watched themselves spend, or a kill they watched themselves score.
Rollback handling was made explicit rather than implicit. Predicted Gameplay Effects were created inside a prediction window so that a server rejection removes them automatically, and every predicted cue was written to be idempotent: safe to reverse, safe to re-apply, never accumulating state.
A cue that increments a counter, spawns a persistent component or toggles a boolean will drift the moment a prediction is rolled back and re-run. Cues under prediction must describe a state, not a change to one.
Latency Compensation
With authority on the server, a client shooting a moving target hits where the target was on their screen, not where the server currently believes it is. Without compensation, accurate play at ping is punished, and playtesters describe it as the guns being broken.
Scoped to the runway, the implementation was deliberately minimal:
- A short rolling history of hitbox transforms per replicated character, sampled at the server tick rate and bounded to a fixed window rather than an unbounded buffer.
- On server-side hit validation, rewind the candidate target to the requesting client’s acknowledged view time, test, then restore.
- A hard cap on how far back a rewind is permitted, so a client reporting an implausible timestamp is rejected rather than granted a hit against a stale world.
That last bound is the part usually added after a demo rather than before it, and it is a few lines. Without it, the compensation system is a validated path for exactly the thing server authority was introduced to prevent.
Scoping to the Runway
Three weeks does not buy a shipping-hardened netcode layer, and pretending otherwise is how demos get missed. Scope was set explicitly at the start, in writing:
- In scope. Authority inversion across every ability in the demo build, prediction on the abilities the demo actually exercises, rewind-based hit validation with bounds, and a written record of the prediction boundary.
- Explicitly out of scope. Abilities not present in the demo, full anti-cheat, bandwidth optimisation, and reconciliation edge cases outside the demo’s network conditions.
- Verified against. The demo build specifically, under simulated publisher-representative latency — not a general correctness claim about the game.
Naming what is not being fixed is what makes the runway real. The out-of-scope list became the first page of the post-demo work plan.
What Transfers
Independent of this project:
- The server decides, the client asks. Client authority’s first symptom is desync, long before anyone attempts to exploit it.
- Draw the prediction boundary by cost of being wrong. Predict feel, confirm consequence.
- Cues under prediction must be idempotent, or rollback becomes drift.
- Bound every rewind window. Unbounded latency compensation is a validated cheat path.
- On a short runway, write down what is out of scope. It is the only thing that keeps the date.