You're halfway through a drift when another kart brushes your rear corner. You expect a nudge. Instead, it suddenly shifts into your lane, your kart jerks sideways, and the corner is gone.
That is the kind of moment we're calling a ping slap: a network disagreement arriving with the force of a collision. The classic KartRider experience is a useful point of comparison here—the reported sudden corrections and outsized shoves that make a small contact feel much bigger than it looked.
For our racing, the goal is to keep the kart responsive in your hands while preventing a delayed update from turning a routine bump into an unreasonable shove. That takes several systems working together.
Take the corner now
When you steer or start a drift, your computer moves your kart immediately. It doesn't wait for the server to approve the button press. Waiting for that round trip would put the connection delay directly between your hands and the road.
This is called prediction. Your computer knows what you pressed and simulates the result while sending those controls to the server.
The driving simulation runs 120 times per second. The server sends race updates 60 times per second, and your computer fills in the movement between them. Those are simulation and network rates, not a requirement to run the game at 120 frames per second.
Prediction makes local driving responsive. Keeping everyone else's view in agreement is the next problem.
An update is a picture of the past
By the time a server update reaches you, you've already driven a little farther. Comparing that old position directly with your current kart would mistake ordinary movement for an error.
Instead, the game starts from the older update and replays your recent controls: turn, drift, release, boost. That brings the update forward to the moment you've already reached. Now it can make a fair comparison.
The room's networking mode decides how to handle any disagreement. When a correction is needed, the simulation can change immediately while the visible kart eases out the difference over a short period. Large corrections and resets can still snap; a kart shouldn't glide through a building just to hide a teleport.
Compare the same moment.
An update from the past is replayed forward before it corrects the present.
PREDICTION
+ REPLAY
Replay your recorded controls for ticks 101–105 from the received state. Now both positions describe tick 105 and can be compared.
Fix the state. Ease the picture.
For an ordinary 1-metre correction, the corrected simulation is adopted immediately. Only the visible offset fades away.
Why smoothing alone doesn't stop a ping slap
There are two different ways a late update can hurt.
One is visual: a kart suddenly jumps to a corrected position. Easing that correction makes it less abrupt on screen.
The other is physical. An updated opponent position can suddenly overlap your kart. The collision system then has to separate them. If it tries to remove the entire overlap in one instant, your kart can be shoved a long way—even without an unusually large impact force.
Several opponents arriving together can make this worse. A modest push from each can add up to one enormous displacement.
We limit how much predicted contact can push your kart out of overlap in a single simulation step. That allowance is shared across the opponents you touch during that step, rather than handed out again for every kart. It is tied to how far two karts could close on each other at maximum boost speed during that interval.
The added spin from an off-centre collision also has a limit, and the chassis turns through a short response instead of instantly changing its facing. The ordinary impact still depends on the karts' relative motion; we don't apply a blanket extra cap to every collision force.
These details matter because smoothing what you see and limiting what moves you solve different problems. A beautifully animated correction can still leave you with an unreasonable physical shove if only the visuals were fixed.
Seven small pushes can become one big shove.
Imagine a late update puts several opponents inside your kart. Each overlap asks to move it 1.2 metres. Add opponents to see the total request.
The allowance is shared across the step. It doesn't reset for each opponent.
What the KartRider comparison tells us
The peer-to-peer, or P2P, comparison is useful here. In a P2P race, players exchange race information with one another. If those players receive updates at different times, their local views can disagree about where a collision happened and how to respond.
Our race information travels through a central server, which manages the room, race clock, and standings. But having a server does not automatically eliminate ping slaps. Prediction can still be wrong, a correction can still arrive suddenly, and private room modes still give drivers substantial control over their own movement.
For the reported KartRider behavior, the important contrast is the experience: a sudden correction and a shove or rotation that feels out of proportion to the contact. A visible snap alone doesn't establish whether KartRider uses no smoothing, and an extreme shove doesn't prove its forces or torque are literally unbounded. Position correction, overlap removal, and impact response can look similar from the driver's seat.
The concrete choices we can describe are our own: ease ordinary visual corrections, limit the combined overlap push, and cap the added collision spin. Those are safeguards against that kind of experience, not a promise that every collision will look identical to both drivers.
Two drivers can see two different bumps
Your computer knows your controls immediately. It only learns another driver's controls when they arrive over the connection.
Between updates, opponents move using their latest known inputs. When available, the server also forwards controls it has already received for their upcoming steps. But if someone suddenly brakes during a connection stall, your computer can't know until that information gets through.
In server-authoritative rooms, lag compensation can look back at recent opponent positions to help resolve a collision closer to what each driver was seeing. That look-back is capped at a quarter of a second and needs suitable history. Otherwise, the server uses current positions.
Each driver can receive their side of the response based on their own view. This accounts for some delay, but it cannot make two different views perfectly consistent. In private mixed and client-authoritative rooms, each human driver's computer instead determines its own collision response.
Where rollback fits
The game uses replay in limited ways. It replays your recent inputs when checking your predicted kart. In mixed rooms, the server can also redo a short stretch of estimated movement and boost calculations when a delayed report arrives.
That keeps a correction from accidentally counting the same boost gain or spend twice. The server returns to a saved checkpoint and redoes that short interval with the information it now has.
It does not rewind the entire race, recalculate everyone's collisions, or rewrite the finishing order whenever someone lags.
Messages also include a short history of recent controls, giving later messages another chance to deliver a missed transition. In server-authoritative racing, that recovery must reach the server before it passes the intended moment. Otherwise, the input takes effect late.
Different rooms, different tradeoffs
New rooms default to mixed authority. Your computer controls your movement, while the server checks large disagreements and tracks drift and boost resources. These rooms are intended for groups joining by room code. Their movement tolerance helps absorb disagreement, but it isn't a substitute for strict server enforcement.
Server authority gives the server the final say on movement and collisions. Local prediction still makes your controls respond immediately, but disagreements can lead to corrections. This mode supports publicly listed rooms.
Client authority gives each driver's computer the final say over its own kart, avoiding ordinary movement corrections. It is also intended for trusted groups joining by room code.
When the connection really stalls
Prediction can cover a short gap. It cannot recover information that never arrived.
During a longer stall, opponents may follow an outdated path before shifting when updates return. In mixed and client rooms, the server carries a reporting kart forward for up to 200 milliseconds after its latest report, then stops estimating further movement. Otherwise it could invent a drive around corners that the player never took.
Bad connections can still cause late actions, visible jumps, and disputed bumps. The aim is to contain those mistakes while preserving the part you feel every second: steering when you steer, drifting when you press, and getting a collision response that stays proportionate to the race.