Skip to main content

Clustering Configuration

This section will guide you through setting up your server network topology and configuring the replication of players and important actors across servers.

Configuring Network Topology​

NetCluster provides several types of servers to build your network topology:

  • Level Server: Each level has one Level Server. It manages the level’s logic, such as determining player spawn points, broadcasting elapsed level time, updating weather conditions, and more.
  • Visibility Server: A level can have multiple Visibility Servers. Each server manages a specific region, tracking the positions of inter-server actors and updating their visibility across servers.
  • Load Server: Multiple Load Servers can be assigned to a level. These servers can offload specific computations (e.g., AI/behavior tree logic) or host players and NPCs.

Designing Your Network Topology​

Before setting up your network topology, consider the following:

  • How many levels does your game have?
  • How many players/actors might be in a single level, and are there any regions with high actor density?
  • Have you identified any computationally or I/O-intensive tasks?

Guidlines:

  • For seamless player travel across multiple levels, consider using World Partition.
  • If players and NPCs are evenly distributed across a level, multiple dedicated servers can host them. For small, high-density regions, set up a specific dedicated server and migrate players to it when they approach that region to improve performance by reducing inter-server RPC calls and property replications.
  • For resource-intensive tasks, define a set of servers to handle them using proxy actors, returning results via server RPC calls.

Once you’ve determined the number of Visibility Servers and Load Servers needed, create the configuration files for these servers.

Server Configuration Details​

For each server, you’ll need the following information:

  • ServerUID: A unique identifier for this server within a level.
  • LevelServerUID: The identifier of the Level Server to which this Load Server should connect. Required for Load Servers and Visibility Servers; ignored by Level Servers.
  • DomainID: The domain server that this server will access. Each domain server can host multiple levels.
  • ServerFlags: Specifies the server type, such as LevelServer (for Level Servers), HostVisibility (for Visibility Servers), or HostStaticActors.
  • RegionID: A unique identifier within a level, starting from 1

Example Configurations​

  • Level Server Configuration
{
    "ServerUID": "Luna-LevelServer",
    "DomainID": "LyraNetClusterTest1",
    "ServerFlags": "LevelServer",
    "RegionID": 1
}
  • Visibility Server Configuration
{
    "ServerUID": "Luna-visibility",
    "LevelServerUID": "Luna-LevelServer",
    "DomainID": "LyraNetClusterTest1",
    "ServerFlags": "HostVisibility",
    "RegionID": 7
}
  • Load Servers Hosting Static Actors Each inter-server static actor defined in a level should be unique across servers. A Load Server with HostStaticActors will treat these as local actors; otherwise, they will be treated as proxy actors. Only one Load Server should host static actors per level.
{
    "ServerUID": "Luna-npc",
    "LevelServerUID": "Luna-LevelServer",
    "DomainID": "LyraNetClusterTest1",
    "ServerFlags": "HostStaticActors",
    "RegionID": 6
}
  • Normal load Server
{
    "ServerUID": "Luna2",
    "LevelServerUID": "Luna-LevelServer",
    "DomainID": "LyraNetClusterTest1",
    "RegionID": 3
}

Configuring Inter-Server Actors​

Configuring an inter-server actor is straightforward.

For C++, simply add NetClusterActor to AActor::Tags:

Tags.Add(FName("NetClusterActor"));

For Blueprint actors, you can add the "NetClusterActor" tag directly in the editor:

Add Inter-Server Tag in Blueprint Actor

With this configuration, the actor is ready to be replicated across servers.