Simulate game lag and packet loss
Netcode is written on a local connection with 1 ms of ping and tested by players on hotel WiFi. This closes that gap on your own machine, on the game process only, while the rest of the computer stays usable.
Start here
Aim at the game client, give it a realistic bad connection, and let it stop itself after five minutes:
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 3 --target mygame.exe --duration 300There is a ready timeline for this too - overloaded-game-server.json in the
scenarios folder walks a connection into congestion and back out, so you can watch
the client handle both directions of the change. See
timed scenarios.
Why a game shows loss when a browser does not
Most game traffic is UDP, and UDP has nothing to hide loss behind. A web page over TCP quietly retransmits and just takes longer, which is why a browser can feel fine at 5 percent loss while a match at the same 5 percent stutters, rubber-bands and desynchronises.
That makes a game the honest place to test loss: what you set is what the client actually experiences.
What to set, and what it looks for
| Setting | Try | What it exposes |
|---|---|---|
| Latency | 80 to 250 ms | Prediction and interpolation. Does your character slide back after a shot? |
| Jitter | 40 to 100 ms | Buffering. A steady 200 ms is easier to hide than a ping that keeps moving. |
| Loss | 2 to 10 percent | Missing state updates, and whether the client recovers or drifts. |
| Spikes | 1 second, rarely | The stall a tower handover causes. Usually the ugliest one. |
| Link on and off | 10 s cycle, 30 percent down | Reconnect and rejoin. |
Measure jitter as the gap between the 95th percentile and the median rather than as an average - jitter barely moves an average, which is why a run can look identical on paper and play differently.
Comparing two builds needs a seed
Random loss makes two runs different, so "the new build feels worse" is not evidence. The same seed replays the same loss and the same jitter, which turns a feeling into a comparison:
BeanNetworkTester.exe --latency 120 --jitter 60 --loss 5 --seed 42 --target mygame.exe --duration 180What it cannot do
This shapes the traffic of your machine. It does not slow the server down, it does not change its tick rate, and it does not put other players on a bad connection - so it tests your client against a bad link, not your server under load. For the server side you want load testing, and for a lobby full of bad connections you want more than one machine.