Multiplayer setup checklist

DRW is built for multiplayer from the ground up: wave time, vessel physics, water-body state, and seat occupation all replicate. This is the practical checklist for taking a working single-player scene to listen-server and then dedicated-server multiplayer.

Read Multiplayer model first to understand what’s authoritative and what’s predicted. This page is operational, not conceptual.

Pre-flight checklist

1. GameMode wired. Project Settings → Maps & Modes → Default GameMode is set to BP_DRWGameMode (or your own GameMode that spawns the Drone or your own pawn).

2. GridManager replicates automatically. BP_DynamicRealWater (and any subclass of ADRW_GridManager) sets bReplicates = true in its constructor: there is no toggle to flip. If you’ve subclassed and overridden the constructor, make sure you call Super:: so this setup runs.

3. bEnableMultiplayer = true on every vessel. Each VesselPawn (and ADRW_Vessel base) has its own toggle: verify on each.

4. Replication graph or default replication. For most projects the default replication driver is fine. If you’re using a custom replication graph, add ADRW_GridManager, ADRW_Vessel, ADRW_VesselPawn, ADRW_VesselSeat, and your water bodies to it.

5. No Construction Script wave configuration. Spectrum settings authored in Construction Script don’t replicate: clients will see different waves than the server. Always assign a WaveDataAsset (which does replicate) instead.

6. Vessels possessed via the right path. Use VesselPossessionComponent → RequestPossessVessel. Don’t call PlayerController::Possess directly from Blueprint mid-frame: it can race with input setup.

Listen-server test

The fastest dev loop. Editor → top toolbar → Net Mode → Play As Listen Server, Number of Players: 2.

What to verify:

• Both clients see waves: and the same waves at the same phase. Drop a buoy at (0, 0, 0): both clients should see it bob in sync.
• Possess a vessel as Player 1. Player 2 sees it move smoothly. Possess as Player 2: Player 1 sees the swap.
• Switch wave preset on the server. Both clients blend together.
• Drive into a pool (BP_DRW_Pool). Both clients see the pool boundary working.

If any of these break, fix before moving on.

Dedicated-server test

Net Mode → Play As Dedicated Server, Number of Players: 2 in the editor.

What changes vs listen server:

• The server PIE window is non-graphical: it skips the visual ocean simulation entirely. Don’t expect to see waves there. This is intentional and saves significant compute.
• Visual sync is identical between clients (they each run their own ocean).
• Replication bandwidth is lower: input is quantized, transforms are interpolated, only meaningful state replicates.

Verify clients still see synchronised waves, vessels move smoothly, and joining mid-game brings a new client up to current state cleanly.

Common issues

Symptom	Cause
Client sees flat ocean while server sees waves	Spectrum was set in Construction Script (doesn’t replicate); use a WaveDataAsset instead. Or a subclass of GridManager skipped Super:: in its constructor and lost bReplicates.
Vessel snaps / jitters on remote clients	Network update rate too low, or server tick rate too low; check NetUpdateRate on the vessel and project frame rate
Possessing a vessel works in single-player but not multiplayer	Custom pawn override of Possess / Restart / OnRep_Controller: call Super::
Wakes don’t appear on remote clients	PhysicsBodyComponent.bEnableWaterInteraction = false on the vessel, or stroke replication is being filtered out by a custom replication graph
Joining mid-game shows wrong wave preset briefly	Expected: WaveDataAsset replicates with RepNotify on the next replication tick. Visual catches up within one frame

Tip

When you ship, run a real multi-machine test, not just listen-server PIE. PIE shares state across instances in ways that hide replication bugs.