Using the Client/Server model for peer to peer game instead of ListenServer

Development Programming & Scripting Multiplayer & Networking
, ,
1

Hi Epic team,

We are currently developing a multiplayer co-op title in Unreal Engine. Our team has been building client-server games for some time and is comfortable with dedicated server architectures. While this particular game is primarily local and peer-to-peer in nature, which makes Listen Server an obvious choice, we are looking to avoid it due to some technical and bandwidth concerns.

Specifically, we have observed the following issues with the Listen Server approach:

  • Increased CPU and memory overhead from rendering both the client and server in the same process.
    • One relevant UDN thread highlights this: [Listen server rendering perf/memory [Content removed] The findings confirm that Listen Servers incur a measurable performance hit, particularly in complex levels or when using world partitioning and streaming.
  • Limited replication coverage during local testing. Since the Listen Server is also a client, it bypasses key parts of the replication pipeline. To properly verify replicated behavior, we must launch a second client in the editor, which significantly increases iteration time and hardware load.
  • Divergence from a true client-server runtime model. This can mask desync issues and edge cases that only appear when client and server are in separate processes with real network conditions.
  • Higher QA burden. Even basic multiplayer flows must be tested with two players during development, including for solo or LAN use cases.
    • While remote multiplayer testing will still be necessary with a dedicated server model, we have higher confidence in the results. This is because, even during local testing, the game is exercised from the perspective of a true client rather than a privileged Listen Server.

Our Goal:

We are looking to implement a system where the game launches a dedicated server instance internally (either in-process or as a subprocess), and the local player connects to 127.0.0.1. Remote players can then connect to the local player’s dedicated server.

Our Questions:

  1. Does Epic recommend or support the approach of running a dedicated server for local play instead of a Listen Server?
  2. Are there best practices or known limitations with this approach, particularly regarding Online Subsystems like Steam or EOS, port binding, or API usage across both processes?
  3. Is there any engine-level support or tooling to facilitate this setup more cleanly?

We appreciate any recommendations or insights you can share.

Thank you.

2

Hi,

To answer your questions:

  1. I believe we do generally recommend using a listen server for the case where a local client needs to also act as a match’s host. However, when playing from the editor, the engine does support launching a dedicated server for local play, even within the same process if needed, so it’s possible you could modify this functionality or implement something similar to suit your project’s needs. I don’t believe this has been tested for use in a shipped project though, as this functionality is only available in the editor.
  2. I believe the Steam OSS does not support running a client and server on the same machine, but because this is not something we’ve tried outside of the editor, it’s hard to provide specific advice on best practices and known limitations. It’s also worth noting that the dedicated server process will still incur a CPU and memory cost, as it still needs to load the level and stream in the connected clients’ cells. It’s possible that this approach could be just as expensive as a listen server, if not more so due to needing a separate server and client process on the same machine.
  3. You can see where the editor kicks off the PIE process in UEditorEngine::StartPlayInEditorSession, which calls into functions like CreateNewPlayInEditorInstance/CreateInnerProcessPIEGameInstance. These may be a useful starting point when investigating how to implement something like this.

Thanks,

Alex

3

Thank you Alex for the detailed reply!