Skip to content

Network Emulation for Beginner Replication Checks

Network Emulation is the "does this still work when the network is not perfect?" pass. Use it after the basic server/client ownership path already works, not as a substitute for proving replication setup.

At a glance

Use this for: latency, packet loss, reliable-spam, prediction, and timing checks in local multiplayer tests - Main setup: Play settings can apply Average, Bad, or Custom emulation to server, clients, or everyone - Beginner rule: first prove the feature with no emulation, then add repeatable lag/loss tests - Official docs: Network Emulation, Play In Editor Settings, and Testing Multiplayer

The one-minute version

  • Local PIE multiplayer usually runs under unrealistically clean conditions: no real internet latency and no packet loss.
  • Network Emulation adds simulated packet lag and packet loss for editor, command-line, console, or config-file tests.
  • In the editor, enable it under Play/Multiplayer options, choose an emulation target, and use an Average, Bad, or Custom profile.
  • Test no-emulation first. Emulation exposes fragile networking; it does not fix missing ownership, missing replicated variables, or code running on the wrong machine.
  • Start with a repeatable action: press fire once, pick up one item, open one door, take one hit, respawn once.
  • Record expected server result and expected client presentation before adding lag/loss.
  • Emulation is especially good at exposing reliable RPC spam, client-only state, missing prediction, stale UI assumptions, and racey "value arrives immediately" logic.

When to turn it on

Use this order:

1. Standalone/single-player behavior works.
2. Two-player PIE works with labels and no emulation.
3. Remote client works, not only listen-server host.
4. Server changes the authoritative replicated state.
5. Clients receive the state/event you expect.
6. Now enable Network Emulation.

If step 2 or 3 fails, emulation will only make the failure noisier. Fix authority, ownership, replicated variables, relevancy, and UI binding first.

Editor setup

Open the Play settings:

Play dropdown or Editor Preferences
-> Level Editor
-> Play
-> Multiplayer Options
-> Enable Network Emulation

Then choose:

Setting Beginner meaning
Emulation Target Apply the simulated network conditions to Server Only, Clients Only, or Everyone.
Network Emulation Profile Use Average, Bad, or Custom settings.
Incoming traffic Add latency/loss before received packets are processed.
Outgoing traffic Add latency/loss before sent packets leave.
Minimum / Maximum Latency A range of delay in milliseconds.
Packet Loss Percentage Chance that a packet is dropped.

Pair this with clear PIE windows:

Number of Players = 2
Net Mode = Play as Listen Server or Play as Client
New Editor Window (PIE) for visible labels

Use Play as Client or a dedicated-server setup when the question is "does this work for a real remote client?"

Console, command-line, and config

For repeatable tests outside one editor toggle, Unreal exposes packet simulation settings through command-line values, console commands, and DefaultEngine.ini.

Common fields:

Field Meaning
PktLagMin / PktLagMax Outgoing packet latency range.
PktIncomingLagMin / PktIncomingLagMax Incoming packet latency range.
PktLoss Outgoing packet loss percentage.
PktIncomingLoss Incoming packet loss percentage.
PktLag / PktLagVariance Constant or variable lag style settings.
PktDup / PktOrder Duplicate or reorder packet simulation.

For beginner Blueprint work, prefer the editor UI first. Use console/config settings when you need a test you can rerun exactly or share with another developer.

First profiles to try

Use escalating passes:

Pass 1:
    No emulation

Pass 2:
    Average profile

Pass 3:
    Bad profile

Pass 4:
    Custom harsh profile for stress

Harsh settings are useful because they force hidden assumptions to break in a short local test. Do not tune your beginner feature only for the harsh profile, but do use it to find reliable spam and missing prediction.

Write down the profile before judging the result:

Test: Client 1 picks up ammo
Mode: Play as Client, 1 visible client, dedicated server background
Emulation target: Clients Only
Profile: Bad
Expected server result: ammo pickup consumed once, ammo count +30
Expected client result: pickup may feel delayed, but final ammo/UI correct

What bugs emulation exposes

Reliable spam

Held input sends Reliable ServerFire every Tick
-> packet loss creates backlog
-> old fire requests arrive after release

Fix the request rate and server validation. Do not just remove emulation.

Client-only state

Client opens door locally
-> looks instant with no lag
-> under emulation, server later disagrees or other clients never see it

Move the real state change to the server and replicate door state.

Missing prediction

Client fires weapon
-> waits for server before any sound/crosshair feedback
-> under latency, weapon feels broken

Keep server authority, but add safe local presentation for the owning player: muzzle flash, animation, camera kick, pending UI state.

Fragile UI timing

Widget BeginPlay reads PlayerState immediately
-> works in clean PIE
-> under latency, PlayerState or replicated value arrives later

Bind/retry and do an initial refresh when the replicated object/value exists.

One-time event state

Server multicasts objective complete once
-> delayed/lost/unrelevant client misses it

Replicate objective state in GameState or an objective actor. Use the RPC only for the transient cue.

A repeatable beginner test card

For each multiplayer feature, keep one tiny card:

Feature:
PIE mode:
Number of players:
Emulation target:
Profile / custom values:

Action:
    exact input sequence

Expected server truth:
    actor/value that should change on authority

Expected owning-client feedback:
    immediate local feedback, pending state, final confirmed state

Expected other-client view:
    replicated state, remote animation, UI/nameplate/scoreboard

Debug labels:
    print fields and Blueprint debug object/world selected

The card matters because networking bugs are easy to "fix" accidentally by changing test timing. Repeatability saves time.

What to test first

Good first features:

  • one press-to-interact door;
  • one pickup added to inventory;
  • one weapon shot with cooldown and ammo;
  • one damage event updating a HealthComponent and HUD;
  • one replicated projectile spawn or impact;
  • one ready button updating PlayerState and GameState;
  • one respawn with HUD rebinding.

Avoid starting emulation with a whole match flow, three weapons, AI, inventory drag/drop, and travel all at once. Make the smallest network promise fail or pass visibly.

When it fails, and what failure looks like

Symptom Likely cause
Feature fails only under packet loss Unreliable event used for durable state, or reliable backlog/race exposed.
Feature fails only with latency UI/input assumed instant server response or immediate replicated object arrival.
Host works, client fails Authority/ownership bug hidden by listen-server host.
Player sees action late but final state correct Missing local prediction/presentation, not necessarily replication failure.
Final state differs between clients Server truth not replicated, actor not relevant, or local client mutated state.
Release input arrives too late Held input reliable spam or missing rate limiting.
Debug prints are unreadable Prints lack net mode, authority, actor name, and client/window label.
Bad profile breaks everything Start with one feature and prove whether the design expects too much bandwidth or too little state.

Debug with the same labels from the normal PIE pass: actor name, net mode, authority, local control, owner, relevant value, and whether the server accepted the request.

What Network Emulation does not do

  • It does not prove the actor replicates.
  • It does not fix ownership or Server RPC eligibility.
  • It does not make widgets replicate.
  • It does not replace Play as Client or dedicated-server checks.
  • It does not model every real-world platform, matchmaking, NAT, or session problem.
  • It does not tell you which Blueprint instance is running unless your prints are labeled.
  • It does not mean every delayed response is wrong; sometimes the missing piece is local prediction.

Lookalikes - which one do I want?

Tool / setting Use when Not for
Multiplayer PIE You need multiple local server/client worlds. Simulating poor network by itself.
Play as Client You need remote-client behavior with a background dedicated server. Host-only UI/camera checks.
Network Emulation You need lag/loss/jitter-style stress after basics work. Fixing missing replication setup.
Print String / Output Log You need proof of world, actor, authority, and value. Measuring bandwidth in detail.
Network Debugging tools You need traffic/channel/bandwidth clues. Understanding which Blueprint branch ran.
Local prediction Owning client needs immediate feel before server confirmation. Final authoritative state.
RepNotify state Clients need current values after delay/loss/relevance changes. A one-frame cosmetic cue by itself.

The quick path is to test only on the listen-server host because it feels faster. The concrete cost is that real remote-client latency, ownership, and UI timing bugs survive until much later. Add emulation once the basic labeled client/server pass is already green.

Going deeper