Unreal Engine vehicle replication: lessons from kart netcode

Unreal Engine vehicle replication is where multiplayer physics gets hard. Unreal Engine 5 gives you a solid base in Physics Prediction: the server decides, your machine predicts your own vehicle, and the engine rewinds and replays when the two disagree. Out of the box, though, the engine only knows about the physics body. Every other value that decides how your vehicle drives is yours to define, network and test.

I make Kart Racing Drifting Physics, an arcade kart plugin for Unreal Engine. I had a first networked build in July, and the version I am happy with came together in late September. Below are the problems I ran into in between, and how to test for each one. None of it needs my plugin.

Why vehicles are the hard case for netcode

Search for “client side prediction Unreal Engine” and most of what you find is about characters, abilities and projectiles. A physics vehicle is harder in four ways:

It is fast, so small errors grow. Half a degree of heading error at racing speed turns into tens of centimeters of sideways error every second.
Its state is more than a position. Velocity, spin, which wheels touch the ground, and gameplay state like a drift or a boost all decide the next frame.
Its input changes all the time. Throttle taps, steering and late braking reach the other machines a round trip later.
It touches other players. Two vehicles in contact are simulated on different machines, at different points in time, and every machine has to agree on the result.

The model in plain terms

Unreal’s Physics Prediction uses client-side prediction with server reconciliation. It works in four steps:

The server is the authority. It simulates every vehicle with the inputs it receives, and its result is final.
The owning client predicts. Your machine simulates your vehicle from your input right away, so there is no input lag, and it saves each frame’s input and result in a history.
The server sends its state for each frame back to the client.
The client rewinds and replays when needed. If the server’s state for a frame differs too much from the saved one, your machine goes back to that frame, takes the server’s state and simulates forward again with the saved inputs, up to the present.

Your machine runs a few frames ahead of the server. When the server's state for frame 10 arrives, it is compared with the saved frame 10. Too far off, and the client replays up to the present.

Epic’s fundamentals tutorial adds two details. Only clients resimulate, since the server never corrects itself. And a resimulation runs on the physics thread without being drawn, so the player only sees the rendered body blend toward the corrected position.

What Unreal Engine physics prediction gives you, and what it leaves to you

Unreal Engine 5 ships this model as Physics Prediction, still marked Experimental in the 5.7 Project Settings. You switch it on with three settings:

Where	Setting	Value
Project Settings > Physics > Framerate	Tick Physics Async	On
Project Settings > Physics > Framerate	Async Fixed Time Step Size	`0.016667` (60 Hz)
Project Settings > Physics > Replication > Physics Prediction	Enable Physics Prediction	On

Networked physics needs Chaos to run with a fixed delta time, and Unreal only does that when physics runs async. For why the fixed step matters even offline, see Async physics in Unreal Engine.

Here is how the work splits between the engine and you:

Piece	What Unreal Engine 5.7 does	What is left to you
Physics frames	Keeps client frames matched to server frames	Keep the fixed step
Rewind and replay of the body	Done in the Resimulation replication mode	Set that mode on your vehicle
Input and state history	The Network Physics Component records, sends and replays it	Decide what goes in, in C++, and keep it complete
When to correct	Position and rotation thresholds in Project Settings	Decide which gameplay differences count too
Showing a correction	Blends the rendered body toward the new position	Other players’ vehicles, where that is not enough
What clients send	Leaves the values to you	Check every one on the server
Contacts between players	Normal physics contacts	Everything that makes them work online

Epic’s docs call the Network Physics Component a low-level system that you implement yourself in C++.

For Chaos vehicle replication, Epic has done part of the work: the Chaos Modular Vehicles docs list native support for the Network Physics Component and Resimulation, so the vehicle itself is covered. A drift or boost system you add on top still has to follow the rules below. I explain why arcade karts usually skip Chaos Vehicles in Arcade kart physics vs Chaos Vehicles.

Lessons from building kart multiplayer on Unreal Engine networked physics

These took me the longest to find. None of them shows up offline, and most stay hidden on a perfect connection too.

Gameplay state has to rewind with the body

Driving straight looks clean. Start a drift and the corrections come in bursts, each one setting off the next.

A correction puts the physics body back to an earlier frame. If the drift angle, the boost timer or the charge level keep their present values, the replay runs old frames with new gameplay state. The result differs from the server again, and the next correction follows. Epic’s tutorial asks for networked input and state that are minimal but complete: “Everything that affects the simulation must be in there, or a resimulation will desync.”

To track it down:

List every value your vehicle code reads to compute the next frame. Anything that is neither an input nor the body is state you have to network and restore for the right frame. A drift has plenty of it (see How arcade kart drifting works).
Log it: on the first replayed frame, your gameplay state must equal what that frame had live, not the values from just before the rewind.
Decide whether a gameplay difference alone should trigger a correction. The thresholds only look at the body.

A drift carries its own timers and angles, and every one of them has to rewind with the kart.

Only code that replays can drive the vehicle

The vehicle drives perfectly offline. Online, the corrections never settle, as if some force went missing after each one.

A replay reruns the physics steps, but not every piece of code that ran during them. In Unreal Engine 5.7 the Blueprint Event Async Physics Tick fires in multiplayer but does not run again during a replay, so a force you add there is missing from every replayed frame.

Make sure the code that pushes your vehicle also runs during resimulation (Epic’s fundamentals tutorial covers the options). When one correction follows another right away, compare a replayed frame with the live frame it replaced.

Replicated movement precision matters for a body you rewind to

After a correction the vehicle points very slightly off, and a fraction of a second later the next correction arrives. This repeats endlessly, even on a straight road.

The replay starts from the state the server sent, and Unreal packs replicated movement to save bandwidth. By default each rotation axis fits in one byte, which gives steps of about 1.4 degrees. My corrected kart could end up 0.7 degrees off its real heading. At racing speed that is about 35 cm of sideways error per second, enough to cross the default 10 cm correction threshold again within about 17 frames.

Epic’s Pawn Tutorial tells you to raise the replicated movement quantization levels for a resimulated pawn. Then measure it: right after a correction, the position and heading error against the server should be close to zero. Glenn Fiedler makes the same point about state synchronization in general. The received state is simulated forward, so it needs far more precision than in snapshot interpolation, where it is only drawn.

One-shot inputs fire twice, or not at all

A jump sometimes does nothing, or a boost fires twice. It gets worse at extreme frame rates and with packet loss.

Physics runs at a fixed 60 Hz and the game thread does not. One rendered frame can span two physics steps, or none, so a “pressed this frame” flag can land on zero steps or on two. On top of that, the server guesses an input when a packet is late, and a replay applies the saved inputs again. A held throttle survives all of that, and a single press does not.

So test presses, not holds. Spam jump at 30 FPS and at 200 FPS or more, then again with packet loss, and count the jumps on the server and on the client. Both counts must equal the number of presses.

The example kart in the air above desert sand, boost flames in its exhausts — A jump is a one-shot input: it has to happen exactly once on every machine, at any frame rate.

Contacts between players are the hardest part

Pushing another player’s kart turns into a stream of corrections. The other kart does not move when you push it, or both slide into each other.

Your kart lives in the predicted present. The other kart, on your machine, is shown in the past or predicted from inputs you do not have yet. A contact joins two bodies on different timelines, and your prediction of the push is checked later against what the server did with the real inputs.

My first bump switched the physics contact off between karts and scripted the push instead. That made things worse: the other kart never moved for a push, every contact frame mispredicted, and each push turned into a rewind storm.

Keep plain physics collision as a mode you can switch to. If karts behave online with plain collision and not with your custom bump, the bump is the problem. That comparison is how I found this one. Test from each client, against standing and moving karts, and next to walls. The plugin’s own collision modes are described in Kart collisions.

Unreal Engine 5.7 needs one setting for contacts during a replay

After a correction, two karts that should have bumped sit inside each other, and then one climbs onto the other.

Unreal Engine 5.7 keeps a physics cache of which bodies are near each other, and it does not refresh that cache while it replays a correction. Two bodies that first meet during a replay get no contact at all. When the replay ends they overlap, and the solver pushes them apart upward.

I only believed it once I reproduced it in an automation test on a bare Chaos scene, without any plugin code. Two bodies that met only in a replay ended up 64 cm inside each other. With the cache off, the replay matched the live run exactly. So it is engine behavior, and the fix is one line in Config/DefaultEngine.ini:

[ConsoleVariables]
p.Chaos.AccelerationStructureCacheOverlappingLeaves=0

It must be active when the physics scene starts, so put it in the ini file and restart the editor. Typing it into the console at runtime is not enough.

Never trust what the client sends

Everything a client sends is a request, as Gabriel Gambetta’s series explains from its first article. Before a value touches the simulation, the server should replace it if it is not a finite number, clamp throttle and steering to -1 to 1, and cap anything else a client can ask for, such as a boost’s strength or length.

Events that decide races, like boost pads or items, are safer on the server. The cost is a short correction for the driving player, whose machine could not predict the server’s decision. Epic’s tutorial suggests giving such actions a short delay where you can, so every machine hears about them in time. For where each call belongs in a kart game, see Blueprints in multiplayer.

Other players’ vehicles: every option has a visible cost

Showing everyone else’s vehicle took me longer than everything above. I tried three approaches:

Approach	What works	What breaks
Interpolate them (Predictive Interpolation)	Smooth driving	Shown in the past, about a round trip plus the input buffer behind your kart: around 200 ms with the Average emulation profile. After a bump, the other kart rolls on, then gets pulled back.
Predict them (Resimulation, with the inputs the server relays)	Same timeline as your kart, so contacts agree	Their input arrives a round trip late, so every throttle tap, brake or steering change mispredicts. Without extra work they look laggy and teleport.
Physics Replication LOD (predict nearby bodies, interpolate the rest)	Best of both, in theory	Experimental in 5.7. Standing karts near the switch distance jittered, a kart braking ahead teleported, and a bump went kick, pull back, throw forward.

No setting makes this go away. Epic’s tutorial is plain about the predicted option: other players’ objects are predicted without their real inputs, so they always drift apart and depend on corrections. On top of that, Unreal smooths the position of a correction but not its speed, so a corrected remote vehicle seems to surge forward or snap back.

In a kart racer contacts matter most, so the upcoming version 1.1 predicts other players’ karts with the inputs the server relays. Coming in 1.1 Much of the work went into making their corrections look calm, and the settings for that are on Visual smoothing.

Judge these approaches only once your contacts work. My first attempts ran on the broken contact setup described above, and I had to test them all again.

How to test with Unreal Engine network emulation

You do not need a second computer, because the editor opens one window per player:

Click the three dots next to Play. Set Number of Players to 2 or 3 and Net Mode to Play As Listen Server.
In Advanced Settings… (Editor Preferences > Level Editor > Play > Multiplayer Options), tick Enable Network Emulation, set Emulation Target to Server Only and Network Emulation Profile to Average.
Press Play and type stat net in a client window to see the real ping.

Profile (Unreal Engine 5.7)	Delay each way	Packet loss	Ping with Server Only
Average	30 to 60 ms	1%	about 60 to 120 ms
Bad	100 to 200 ms	5%	about 200 to 400 ms

Pick Server Only because the profile delays incoming and outgoing packets on each machine it targets. With Everyone, the server and the client both add the delay, the round trip roughly doubles, and you end up tuning against a worse connection than your players have.

Epic’s tutorials list the engine’s debug views:

Command	What it shows
`p.Chaos.DebugDraw.Enabled 1`	Nothing alone, but the two below need it (I learned that the hard way)
`np2.Resim.DrawDebug 1`	What triggered each correction: position, rotation or velocity
`p.RenderInterp.DebugDraw 1`	The correction offset as it blends away
Chaos Visual Debugger	Server and client physics recorded on synced timelines, corrections included

Add one log of your own: the difference between your prediction and the server’s state for the same frame. Then run the same routine from each client, watching both your own vehicle and the other one:

Drive straight for 15 seconds, then drift.
Cross rough ground.
Spam jumps and boosts at low and high frame rates.
Bump a standing vehicle and push a moving one.
Repeat all of it with Bad.

These are healthy results for my kart under Average:

Situation	Healthy result
Smooth road and drifting, 15 seconds	No corrections, position error under 1 cm, heading error 0.00 degrees
Rough offroad	About 0.3 to 0.5 corrections per second, each a nudge of 10 cm or less
Bad profile	Occasional small tugs from lost input packets, still playable

If smooth road is not at zero, fix that first. The usual causes are missing state, low precision or code that does not replay. When you suspect the engine, prove it in a small automation test with a bare physics scene. That is how I found the replay contact problem, and the same test now tells me whether a newer engine still needs the setting.

A checklist for Unreal Engine vehicle replication

Ask these questions of any replicated vehicle, yours or one you are about to buy:

Does physics run on a fixed step, the same on the server and every client?
Is every value that decides the next frame an input, part of the body, or networked state?
On the first replayed frame, does the gameplay state equal what that frame had live?
Does all code that pushes the vehicle run during a replay?
Does a corrected body start where the server’s body is, heading included?
Does each press fire exactly once, at 30 FPS, at 200 FPS and with packet loss?
Does the server check every value a client sends?
Do world events run only on the server and player actions only on the owning client, never both?
Do contacts between players stay live physics contacts, even during a replay?
Is smooth road at zero corrections under Average with Server Only?
How do other players’ vehicles look when they brake, tap the throttle and steer?

Skip the hard part

If your vehicle is a kart, you do not have to solve all of this yourself. The upcoming version 1.1 of Kart Racing Drifting Physics brings replicated, server-authoritative multiplayer on Unreal’s Physics Prediction. Coming in 1.1

Your own kart reacts instantly, and a correction keeps its drift and boost state intact.
Other players’ karts run the same simulation on your machine, so their drifts and bumps show on your screen too.
Presses are never lost or doubled, and the server checks what clients send.
Setup takes three steps, and the kart needs no replication code.

It will run on Unreal Engine 5.7 as a free update for owners. The multiplayer setup guide shows every step, the free Windows demo lets you try the handling, and the plugin is on Fab.

Unreal Engine vehicle replication: what building kart multiplayer taught me