Multiplayer model

DRW is built for multiplayer from the ground up. This page is the mental model: what to expect, where authority lives, and which behaviours might surprise a first-time networked tester.

What’s authoritative on the server

• Vessel physics. All buoyancy, propulsion, and movement forces are computed on the server. Clients receive transform updates and interpolate.
• Wave time. The ocean’s spectrum time is replicated, so every client sees waves at the same phase.
• Wave state. Switching to a new WaveDataAsset or VisualDataAsset is a server-driven action. Clients receive the change with a smooth blend.
• Water body state (pools, lakes): replicated bEnable* flags and visual assets.
• Vessel input. Clients send their input to the server; the server applies it.
• Seat occupation. The current occupant of any VesselSeat is replicated.

What’s predicted / interpolated on the client

• Vessel transform. SmoothReplicationComponent keeps a state buffer and interpolates between server snapshots, with optional extrapolation when the buffer empties. The OnTeleport delegate fires when interpolation isn’t possible and the actor must snap.
• Wave display. Each client runs its own ocean simulation locally: only the spectrum time is replicated. This means visual waves are deterministic across clients but generated client-side, not streamed.
• Interaction effects (wakes, ripples, splashes). Each client computes these locally based on replicated source positions and velocities. Strokes are sent via unreliable multicast: occasional drops are expected but visually invisible.

What’s local-only (never replicated)

• The interaction render target itself. Clients don’t share GPU buffers; only the sources that feed the buffer are networked.
• Caustics, foam, normal smoothing: these are visual effects driven from replicated state but not transmitted directly.
• Camera state, post-process state.

Smoothness on remote clients

Remote vessels look smooth because of:

1. Interpolation render delay: clients render slightly behind the latest received state, giving the system time to fill in between snapshots.
2. Hermite interpolation: curve-fit between snapshots, not linear lerp.
3. Bounded extrapolation: if a snapshot is missing, the client extrapolates briefly before snapping.

These are all tunable on SmoothReplicationComponent. Defaults work for most projects.

Joining mid-game

A client joining an in-progress session will:

• Receive the current WaveDataAsset and VisualDataAsset via RepNotify (immediate visual sync).
• Sync wave time on first replication tick.
• See vessels populate as their replication establishes: a brief snap on initial appearance is normal.
• Not replay wake / splash effects from before they joined. Strokes age out at a few seconds and are visual-only.

What to verify in a multiplayer test

• The GridManager is in the level (it replicates automatically: no toggle to set).
• bEnableMultiplayer = true on each vessel.
• bEnableMultiplayerSupport = true on each vessel’s BuoyancyComponent (default).
• Realistic NetUpdateRate for vessels (default 30 Hz works for most games).
• Players are using the VesselPossessionComponent flow, not direct PlayerController possess from Blueprint (which can race with the input setup).

Caution

Dedicated servers skip the visual ocean sim entirely (waves cost compute the server doesn’t need). Run a listen server when testing visuals; switch to dedicated for performance / bandwidth tests.