Hi Creators,
Today, we are expanding network simulation capabilities in Studio! Because testing on a high-speed local connection often masks connectivity issues, we’ve built these new capabilities to allow you to simulate real-world network conditions like latency, jitter, and packet loss. This is a critical tool for testing how your experience feels and behaves across varying conditions, especially for network-sensitive features like Server Authority and Unreliable Remote Events.
When To Use Network Simulation
Network simulation helps you identify and compensate for suboptimal gameplay behavior caused by different network conditions. Key use cases include:
-
Validate Server Authority: See how increased packet loss or jitter affects misprediction rates.
- Check out our Advanced Server Authority Techniques guide for inspiration on how to compensate for suboptimal conditions.
-
Test Unreliable Events: Observe how your experience handles out-of-order packet arrival to ensure your gameplay remains fluid.
-
Simulate Diverse Connections: Use Team Test with unique delay values for different players to see how someone with 20ms ping interacts with someone at 200ms ping.
- Note: For Team Test, latency and packet loss numbers are additive. If your natural ping to Roblox servers is 20ms and you configure a 50ms simulation delay, your total ping will be 70ms.
How to use Network Simulation
You can find these settings in the Studio Settings menu under the Network tab. They apply to all test modes with a client instance, including Test, Test Here, Team Test and Server & Clients.
Key Concepts & Configuration
-
Understand Perspective: “Inbound” and “Outbound” are always from the perspective of the Client.
-
Client-Side Settings: Simulation is applied client-side only, so your settings in Team Test won’t affect your collaborators.
-
Set Fixed Latency: Latency is a mix of an inbound and outbound delay, so we recommend picking the total latency and dividing the value between inbound and outbound (e.g., 50ms In/50ms Out for 100ms total). Though an asymmetric split can be leveraged to simulate upload or download congestion, symmetric inbound/outbound delay is fine for understanding the general impact of network latency.
-
Add Variable Latency (Jitter): Add how much jitter you want to simulate to your minimum inbound and outbound delays.
-
Simulate Packet Loss: Adjust the packet loss percentage to see how your game handles data gaps.
Pro Tip: You can also toggle these settings via scripts during a test session using the NetworkSettings class, making it easy to automate stress tests!
Recommended Network Conditions
For realistic network conditions, you can use these values as a starting point:
| Condition | Latency (50/50 Split) | Jitter | Packet Loss |
|---|---|---|---|
| Great | 30ms (15ms In / 15ms Out) | 0ms | 0% |
| Good | 100ms (50ms In / 50ms Out) | 10ms | 0% |
| Poor | 300ms (150ms In / 150ms Out) | 100ms | 0.5% |
Is this similar to Incoming Replication Lag?
Yes, but with key improvements. Unlike the legacy “Incoming Replication Lag” setting, Network Simulation applies conditions to each individual packet. This creates a much more accurate representation of network instability and its impact on game logic.
Though we will continue supporting IncomingReplicationLag, we recommend switching to the new Network Simulation tools for more accurate, packet-level testing.
Note: If both are enabled, the effects will stack, which may lead to unpredictable results during debugging.
Example Use Case
In the example below, we’re testing a dodgeball game where hits are calculated on the server with no lag compensation.
Scenario 1 & Scenario 2
- Scenario 1 (No Delay): The player dodges the ball successfully on both the client and the server.
- Scenario 2 (300ms Simulation): While the player appears to dodge on their screen, the 300ms round-trip delay means the server sees them get hit, leading to a “teleporting” damage effect.
To mitigate this, you can implement backward reconciliation (server-side rewind) by having the server keep a history of player positions and “rewinding” the hitbox to where the target was when the action actually occurred on the player’s screen. This ensures hit registration feels fair and consistent, even when players have high latency.
Otherwise, you can leverage Server Authority and have this work automagically!
Limitations
- Packet Loss Limits: Packet loss probability is currently constant and therefore capped at 0.5% to prevent interfering with standard congestion control.
- Scope: Network Simulation applies to Client-to-Server connections and does not currently affect voice, HTTP, or asset downloading.
What’s Next
- Improved Packet Loss: We will add more realistic, “bursty” (dependent) packet loss which will also allow higher packet loss limits.
- Network Presets and Bandwidth Simulation: We plan to add preset configurations (e.g., Ethernet, 5G, 3G) and bandwidth limits in future updates.
We’d love to hear how these new simulation capabilities help you improve your experiences! Let us know your feedback in the comments.
Thank you,
The Roblox Engine Team
