Blueprints in multiplayer kart games

The kart itself needs no replication code. It sends its inputs, predicts itself and gets corrected on its own. Your game features on top of it follow two patterns:

• Something happens to a kart (boost pad, item hit, checkpoint): run it on the server, behind Has Authority.
• The player does something (button press, drift release boost): run it on the owning client, behind Is Locally Controlled.

Which call goes where

In Blueprint, the names show with spaces: SetBoost is Set Boost, bIsDrifting is Is Drifting.

Call	Where to call it	What happens
SetAcceleration, SetTurn	Owning client, from input events	Recorded every physics tick, sent to the server and replayed during corrections.
JumpOrDrift, StopJumpOrDrift	Owning client, from input events	Presses are never lost or doubled, even with packet loss.
SetBoost	Server for world objects (boost pads, items). Owning client for input boosts (drift release).	Server calls are final for any kart. Client calls are predicted and checked by the server.
Kart Intents: SetKartLinearDamping, ClearKartLinearDamping, AddKartImpulse, AddKartAngularImpulse, StunKart, ClearKartStun	Same rule as SetBoost	Networked automatically, just like SetBoost.
TeleportKart	Server only	Calls on a client are ignored. Use a Run on Server event or Has Authority.
Reading state: bIsDrifting, bInAir, ControllerTurn, SpringCastHits, AsyncVelocity	Any machine	Every machine simulates every kart, so these values are live everywhere, also on other players’ karts.

Input events only fire for the player who owns the kart, so calling the driving functions from your input events is already correct.

On a client, calls to SetBoost or a Kart Intent on another player’s kart are ignored (development builds print a warning in the Output Log). The server’s call is what moves that kart.

Gameplay effects: run them on the server

Overlap events (boost pads, item boxes, checkpoints) fire on every machine that sees the overlap. Apply the effect only on the server:

1. In your boost pad Blueprint, add On Component Begin Overlap for the trigger.
2. Cast Other Actor to KartPawnBase. This works for BP_KartPawn and every kart Blueprint based on it.
3. Optional: play the sound or particles here, before the switch, so every player sees and hears them.
4. Add a Switch Has Authority node.
5. From Authority, call Set Boost (or a Kart Intent) on the kart. The plugin handles the rest. Leave Remote empty.

A full boost pad walkthrough is in Boosts and items.

Input-based boosts

A boost that comes from the player’s own input, like a drift release boost, is the one exception. Call Set Boost on the owning client, behind a Branch on Is Locally Controlled.

• The boost is predicted on the player’s machine, so it feels instant.
• The server checks it before applying it (see Cheating below).
• Without the check, every machine would run your drift logic for every kart and try to boost it.

The example project’s drift boost works this way.

Cosmetics everyone should see

Some effects must show for other players too, like a drift stage spark color that your Blueprint computes. There are two ways.

Work it out on every machine (best)

The kart’s state is live everywhere, so every machine can compute the same effect by itself. No replication is needed, and players who join late see it correctly too.

Example for a drift stage:

1. When bIsDrifting turns true, reset a local timer.
2. Count the timer up while drifting.
3. Map the time to a stage.

Use RepNotify

Set the Blueprint variable’s Replication to RepNotify (in the variable’s Details panel), set it on the server, and play the reaction in the generated OnRep_ function. The kart pawn already replicates, so this works out of the box.

One-shot effects

For a stage-up shockwave or a landing sound, detect the change locally: on Event Tick, compare the value with a stored previous value and fire when it changes.

OnKartBump (Arcade Bump mode) fires on every machine, so it is safe for bump sounds, effects and animation. See Kart collisions.

Camera shakes only for the local player

Camera shakes, rumble and screen effects belong to one player. Branch on Is Locally Controlled before playing them. Otherwise your camera shakes when another player’s kart lands.

Cosmetic in-air checks and traces

On your screen, another player’s kart can look slightly different from its collision body, for example during a hop. For purely cosmetic logic, use these instead:

Function	Use instead of	Good for
IsVisuallyInAir	bInAir	Wheel in-air pose, air effects
GetVisualBodyLocation	The collision body’s location	Cosmetic traces that should follow the visible kart

For your own kart, on the server and in single player they return the same as bInAir and the body location. Never use them for gameplay or physics decisions.

Async Physics Tick is for single player

More about the physics tick itself: async physics in Unreal Engine, on the blog.

Race logic

Laps and positions use standard Unreal multiplayer:

• Count checkpoints and laps on the server (checkpoint overlaps behind Switch Has Authority).
• Store each player’s results in the PlayerState, and race-wide state (countdown, finish order) in the GameState.
• Never trust a lap reported by a client.
• To respawn a kart at a checkpoint, call TeleportKart on the server.

Cheating

Set Boost and the Kart Intents called on the owning client travel with the player’s input, and the server checks them:

Value	Server limit
Throttle and steering	-1 to 1
Boost speed	At most 3 times the kart’s MaxSpeed
Boost decay	At least 0.05, so a client boost lasts about 20 seconds at most
Linear damping	0 to 100, duration at most 600 seconds
Impulse	At most one MaxSpeed worth of velocity change
Stun	At most 10 seconds

If boosts decide races in your game, trigger them from the server only (boost pads and items on server-side overlaps).

Next steps

• Set up the project for multiplayer in Multiplayer setup.
• Build pads and items with Boosts and items.
• React to bumps in Kart collisions.