Multiplayer testing under latency and packet loss

To test multiplayer properly, reproduce the same player actions under controlled delay, variable delay and packet loss, then inspect whether shared state remains correct and feedback remains understandable. Record the build and network settings for every run. A smooth localhost session is a useful baseline, not evidence of reliable internet play.

A player presses interact and sees nothing happen. They press it again. A moment later the object disappears, but the inventory still looks unchanged. Is that slow confirmation, a failed request, duplicated input or a presentation bug? Without a repeatable test and evidence from both sides, a team can spend hours arguing about the wrong symptom.

This article proposes an original testing workflow using documented Unreal tools. It does not report that AneeMate, QORPO or another named game has passed these tests. It also makes no claim about the availability of a specific cooperative or multiplayer mode.

Give delay, loss and jitter different jobs

Latency is the time data takes to travel. Packet loss means some packets do not arrive. Jitter describes variation in delay. They can occur together, but changing all of them at once makes an initial failure harder to explain.

Epic's Network Emulation documentation describes introducing lag and loss for incoming and outgoing traffic, with editor settings and other configuration methods. It also documents jitter-related controls. Select the documentation appropriate to the engine version used by the build.

In your own test record, distinguish configured delay from observed round-trip behaviour. Write down which side and direction received the impairment. Do not label a setting simply “100 ms ping” if the value actually represents one stage of the emulation. The label should explain what was changed, not suggest a measurement that was never taken.

Begin with a known baseline

Use a short scenario that works reliably under the initial setup. Record the build identifier, server configuration, number of clients, map, account or test-data state and input sequence. Keep private account details out of public reports.

Repeat the scenario before introducing impairment. If the baseline already fails, investigate it separately or mark it unstable. A test that alternates between unrelated starting states will not tell you whether a network setting caused the new symptom.

Give the scenario a precise ending. “Played for a while” is not enough. “Client requests an interaction, both clients observe its result, and the resulting state remains consistent after reopening the interface” defines something another tester can repeat. The mechanics involved depend on the actual game under test.

This distinction is central to production readiness beyond a prototype. An entertaining session is valuable feedback, but it answers a different question from a repeatable state test.

Build a small impairment matrix

Start with a few deliberately different conditions rather than a large spreadsheet nobody can finish. The following is an original illustrative matrix, not a statement about average player connections or a universal release requirement:

• Baseline: no added impairment, using the documented local setup.
• Delay only: a fixed configured delay on one named direction.
• Variable delay: a specified minimum and maximum on that same direction.
• Loss only: a chosen loss percentage with added delay disabled.
• Combined stress: an explicitly recorded combination after individual checks.

Choose actual values based on the product's requirements, deployment regions and observed connection evidence where available. Include a harsher diagnostic case if useful, while keeping it separate from a claim about supported conditions. Epic describes severe conditions as a way to reveal bugs; that does not make every severe configuration an appropriate user-experience target.

Keep the matrix short enough to rerun after a fix. Expand it when a failure, new architecture or launch requirement justifies another condition.

Test the moments when state changes hands

Movement matters, but do not restrict testing to running around a map. Identify actions where the player expects a clear commitment: submitting a choice, acquiring an item, confirming a trade in a game that supports one, or completing a shared objective.

For each real mechanic, ask four questions. What does the requesting player see immediately? What does the authoritative system decide? What do other relevant players observe? What remains true after the interface refreshes or the scenario continues?

Original hypothetical example: a shared supply box. Two clients attempt to claim one resource. The test checks that the final resource count follows the game's rules, each player receives an understandable result and a delayed visual update does not invite accidental repeated claims. This is a fictional mechanic used to explain a test, not an announcement of a QORPO feature.

Run the same sequence under each condition before adding spontaneous play. A repeatable core makes it easier to compare sessions; exploratory testing can then uncover paths the planned sequence missed.

Review feedback as well as final correctness

A server can reach the right final state while the client gives a confusing experience. Look for an action that appears available while an earlier request is unresolved, a success message that appears before confirmation, or a spinner that never explains what the player can do next.

Describe observed behaviour without jumping to a solution. “The button remains active after submission, and a second click shows another pending state” is stronger evidence than “add a debounce”. The appropriate fix may involve state ownership, request handling, presentation or several systems.

Evaluate wording too. An error that tells the player an action failed must match what actually happened. Avoid telling them to repeat a potentially committed action until the system can determine the outcome. These are design questions that emerge from the test; this article does not prescribe one networking architecture for every game.

Capture enough evidence to investigate

Epic's Networking Insights documentation describes network trace capture and views for packets, replicated objects, properties and remote function calls. Use its current setup instructions for the build and environment rather than assuming all builds collect the same data automatically.

Pair relevant traces with timestamps, a short recording and observations from the clients involved. Mark the start of the repeatable action so an engineer can align the symptom with the trace. Keep a small evidence package rather than an unlabelled collection of large recordings.

A useful defect report names the scenario, impairment, expected result, observed result, repeat count and evidence location. State whether the issue reproduced after returning to baseline. That last comparison can reveal a persistent state problem without proving its root cause.

Separate the emulator from the product

Test tooling has versions and limitations too. Epic's public UE-167187 issue record documents a historical network-emulation loss problem affecting Unreal 5.0.3 and lists a target fix of 5.5. It is not evidence that every current networking symptom comes from that issue.

Record the engine version and exact emulation target. If results appear inconsistent with the settings, investigate the setup before treating the configured percentage as measured real-world loss. Also distinguish an editor run from a packaged client against the intended server deployment. Passing one environment does not establish the other.

For a related example of evidence-driven implementation review, read our AI-generated game code checklist. Neither a tool setting nor a code change substitutes for a verified result.

Define what passing means before rerunning

Write acceptance criteria around the mechanic and experience. They might require consistent final state, no duplicated commitment, clear pending feedback and an explicit recovery path. Add time limits only when the product team has defined a justified requirement and a way to measure it.

After a fix, rerun the failing case and the baseline, then relevant neighbouring conditions. Record the outcome honestly: passed this scenario on this build, failed, or still awaiting validation. This creates useful release evidence without claiming universal reliability.

Frequently asked questions

Is packet loss the same as high ping?

No. Missing packets and delayed delivery are different conditions. Test and record them separately before examining combinations.

Does passing local emulation prove internet readiness?

No. It provides evidence for the tested scenario and setup. Packaged builds, real deployment environments and representative sessions require their own validation.

Does this article confirm AneeMate co-op is available?

No. Availability must come from current product and release evidence. This is a general development guide, independent of any game's mode announcements.

Follow the development work

Read QORPO's development blog and studio information, then use documented product updates to distinguish released features from plans. Useful testing starts with a question you can reproduce and ends with evidence another person can inspect.