Skip to main content

Inter-Server Replication Examples

This section provides two examples of inter-server replication to help you understand how actors are synchronized across multiple servers within a level.

A level in NetCluster runs simultaneously on multiple servers. The actors on each server are replicated to their corresponding servers by the NetClusterPlugin, creating a unified, expansive world across all servers.

Simple Replication Example​

Simple Level Replication

In this example, we explore a straightforward replication scenario in a multiplayer game with two servers—Load Server 1 and Load Server 2—both hosting the same level.

tip

For details on actor ownership in Unreal Engine, refer to RPCs in Unreal Engine

Player Connections​

  • Player 1 is connected to Load Server 1.
  • Player 2 is connected to Load Server 2.

Actor Types​

  • Black icons: These represent client-owned, server-owned, or unowned actors. Created locally by the server when a remote client logs in or placed within the level, these are referred to as Local Actors in NetCluster.

  • Green icons: These represent client-owned or server-owned actors. They are created locally or replicated by Unreal Engine Server.

  • Blue icons: These represent inter-server-owned actors, also known as Proxy Actors in NetCluster. They are synchronized across servers when the VisibilityServer determines that actors on one server should be visible to actors on another server.

Replication Process​

  • Player 1 controls an actor (Player1) hosted on Load Server 1, and Player 2 controls an actor (Player2) hosted on Load Server 2. Since they are close enough to see each other, their actors are relevant for replication.

  • Load Server 1 replicates Player1 to Load Server 2, and Load Server 2 replicates Player2 to Load Server 1. This ensures that both Player 1 and Player 2 see each other’s actors in their respective game worlds.

Complex Replication Example​

For a more intricate scenario, consider the structure of LevelA: Level Composition

Player Connections​

  • Player 1 and Player 3 are connected to Load Server 1.
  • Player 2 is connected to Load Server 2.
  • Player 4 and Player 5 are connected to Load Server 3.
  • Player 6 is connected to Load Server 4.

For clients of Players 1-6, it feels as if they are all connected to the same server, seamlessly interacting with actors from different servers.

Visibility Servers​

  • VisibilityServer1 manages the visibility of actors in Zone1.
  • VisibilityServer2 manages Zone2.

Zones 1 and 2 overlap partially, allowing actors near the boundary to see each other across zones.

Replication Process​

GameStateSync​

Created by LevelServer1, GameStateSync is responsible for facilitating message exchanges between servers, such as clock synchronization and team allocation. This actor exists only on the server and is not synchronized to clients.

NPC and Player Distribution:​

  • NPC1 and NPC3 are created by NPC Server1 and are distributed across Zones 1 and 2.
  • NPC1 is synchronized with VisibilityServer1, while NPC2 is synchronized with VisibilityServer2.

Players​

Players are similarly synchronized based on their zones, with Player5 in the overlapping region of Zone1 and Zone2.

Actor Visibility and Synchronization:​

  • NPC1 and Player2 are visible to each other, triggering synchronization of Player2 on NPC Server1 and NPC1 on Load Server1.

  • Similarly, Player1, NPC2, NPC3, and Player3 are synchronized on their respective servers.

  • Player6, isolated from others, sees no one, so no other server synchronizations occur on Load Server4, except for GameStateSync.

Visibility and Relevance Control​

Actor visibility and relevance across servers are controlled similarly but require different mechanisms. Managing visibility requires using the NetClusterActor tag.