Overview
NetCluster is a networking plugin for Unreal Engine 5. With this plugin, developers can network multiple Unreal Engine dedicated server processes, where each server process handles different computations. Communication between servers is achieved through extended Unreal Network RPC and property synchronization. By making minimal modifications and utilizing existing Unreal Engine modules, plugins, it becomes possible to build a game world that supports a large number of players.
A typical server network structure is as follows:
Specifically:
The game consists of LevelA, LevelB, and LevelC, each identified by an ID. This ID is unique within a DomainServer. The DomainServer needs to be started before the game servers through the provided tools.
Each Level runs independently on multiple servers, coordinated by LevelServers and VisibilityServers to form the same world. Each server also has an ID, unique within a DomainServer. For example, LevelA consists of:
- 4 LoadServers that provide services to connected players, handling all player-related logic.
- 2 NPCServers responsible for running AI and other NPC-related logic.
- 2 VisibilityServers responsible for determining actor visibility across servers.
- 1 LevelServer managing overall logic.
All servers connect to a DomainServer, identified by an account. Each game uses one or more DomainServers. The DomainServer is responsible for managing the interconnection logic between servers.
The LicenseServer verifies account information before servers connect to the DomainServer.
Servers also have connections between them. Through these connections, one server can synchronize actors and invoke RPCs on another server. Specifically, the connection between the LevelServer and other servers (NPCServer, LoadServer, and VisibilityServer) is known as the Control Connection, through which global control information can be sent.
Generally, only LoadServers can be directly connected by the game clients.
Level Composition
A level runs simultaneously on multiple servers. The actors on each server are replicated to their corresponding servers by the NetClusterPlugin, forming a relatively large world on each server.
Simple replication example
In this example, we have a simple replication case in a multiplayer game environment with two servers, namely Load Server 1 and Load Server 2, both hosting the same level.
Please check RPCs in Unreal Engine | Unreal Engine 5.2 Documentation for Unreal engine actor's ownership.
Two players are connected to the game servers: Player 1's client is connected to Load Server 1, and Player 2's client is connected to Load Server 2.
Actors in the game can be categorized into three types based on their ownership and replication behavior:
- Black icons: These can represent client-owned actors, server-owned actors, or unowned actors. These actors are created locally by the server when a remote client logs in or placed within the level. In NetCluster, they are referred to as Real Actors.
- Green icons: These represent client-owned or server-owned actors. They are created locally or replicated by the Unreal Engine server.
- Blue icons: These represent Interserver-owned actors, also known as Ghost Actors in NetCluster. They are actors synchronized to a server when the VisibilityServer determines that all actors on that server should see actors on other servers.
Player 1 controls their actor, represented as Player1 actor, which is hosted on Load Server 1, and Player 2 controls their actor, represented as Player2 actor, which is hosted on Load Server 2. As they are close enough to see each other, their actors are relevant for replication.
To ensure both players see each other's actors, Load Server 1 replicates Player 1 actor to Load Server 2, and Load Server 2 replicates Player 2 actor to Load Server 1. This way, both Player 1's client and Player 2's client have the other player's actor replicated and visible in their game worlds.
Complicated replication example
For a more complicated case, taking the structure of LevelA as an example:
Where:
VisibilityServer1 is responsible for the visibility of actors in Zone1, and VisibilityServer2 is responsible for Zone2. Zone1 and Zone2 should have partially overlapping regions, allowing actors to be seen by actors on the other side when they reach the boundary.
LevelServer1 creates GameStateSync, used to send and receive messages to other servers, such as synchronizing clocks, allocating teams, and so on. This actor exists only on the server and is not synchronized to clients.
NPC1 and NPC3 are created by NPC Server1 and distributed across Zone1 and Zone2. Therefore, NPC1 is synchronized to VisibilityServer1, and NPC2 is synchronized to VisibilityServer2. Similarly, Player2 in Zone1 and Player5 in Zone2 are synchronized to VisibilityServer1, while Player1, Player3, Player4, and Player5 in Zone2 are synchronized to VisibilityServer2. Player5 is located in the overlapping region of Zone1 and Zone2.
NPC1 and Player2 are visible to each other, so there is synchronization of Player2 on NPC Server1 and synchronization of NPC1 on Load Server1. Similarly, Player1, NPC2, NPC3, and Player3 are visible to each other, with corresponding synchronizations on their respective servers.
Player4 and Player5 are visible to each other. Player4 is synchronized to Load Server3, and Player5 is synchronized to Load Server2.
Player6 doesn't see anyone, so apart from GameStateSync, there is no synchronization of other servers on Load Server4.
The visibility between servers and the relevancy of actors within a server are similar but controlled differently. Controlling visibility also requires the use of the NetClusterActor tag.
For clients of Player1-Player6, it is as if they are connected to the same server and can see actors from different servers.
Actor Synchronization
To synchronize actors during service using NetCluster, the following tags need to be added to the actor's Tags field:
NetClusterActor: Actors with this tag can be synchronized to other servers under the management of VisibilityServer.NetClusterActor.ServerOnly: Actors with this tag will only synchronize between servers and will not be synchronized to clients.NetClusterActor.ControlConnection: Actors with this tag will automatically synchronize between Control Connections. No VisibilityServer management is required.NetClusterActor.AlwaysRelevant: Actors with this tag will automatically synchronize to all servers connected to the same server.NetClusterActor.Manual: Actors with this tag will not synchronize by default and require synchronization through the OnActorReplicating delegate.
RPC Invocation between Servers
Invoking RPCs from the server:
| Actor Ownership | Not Replicated | NetMutlicast | Server | Client |
|---|---|---|---|---|
| Client-owned actor | Runs on server | Runs on server and all observed servers and clients | Runs on server | Runs on actor's owning client |
| Server-owned actor | Runs on server | Runs on server and all observed servers and clients | Runs on server | Runs on server |
| Unowned actor | Runs on server | Runs on server and all observed servers and clients | Runs on server | Runs on server |
| Interserver-owned actor | Runs on invoking server | Runs on invoking server | Runs on server where this actor is replicated from | Runs on invoking server |
The behavior of the client RPC remains unchanged.
In addition to the defined extensions, Interserver Only RPC invocation has been implemented,
restricting its invocation to the server. To define this type of RPC, the function name needs to be
prefixed with the InterServerOnly_ prefix.
Note: The translation assumes that the given text explains that while there are no additional RPC
invocation extensions for clients, there is a specific type of RPC called "Interserver Only" that
can only be invoked on the server. To use this type of RPC, the function name should be prefixed
with InterServerOnly_.