Multiplayer Gem Overview

In Open 3D Engine (O3DE), the synchronization needed for multiplayer support is performed through multiplayer components. Like other components in O3DE, these are attached to entities. Multiplayer components can receive remote procedure calls (RPC), which are function calls from a remote source. Multiplayer components also define the data to be synchronized across the network. Each multiplayer component, normally generated as an auto-component, defines its own requirements for other data to be present and defines which functions are available.

Some of the features offered in the O3DE Multiplayer Gem include:

• Role-based synchronization and replication rules
• Local prediction and backwards reconciliation (“rollback”)
• Server-authoritative asynchronous multiplayer

Multiplayer components

Multiplayer components are built on top of O3DE components and allow entities in O3DE to communicate with each other through the network. A multiplayer component may contain a variety of attributes that help define the component’s data and functionality, such as network properties, remote procedure calls (RPCs), network inputs, and archetype properties.

Multiplayer components are generated by auto-components, XML files that defines components’ states for network synchronization. For more information about generating multiplayer components by defining auto-components, refer to Multiplayer Auto-components.

Event-driven messaging system

Network properties and RPCs, which are defined in multiplayer components, are key attributes that provide the following data and functionality for network communication:

• Network properties: State information about the component that gets replicated between hosts.
• Remote procedure calls (RPCs): Allow messages to be sent to a particular component on an entity.

Together, these represent an event-driven messaging system. When a property changes on a network component, it triggers an event; Similarly, when an RPC is invoked, it sends a trigger to the relevant component. This means that the Multiplayer Gem uses a push-based model rather than poll-based model for synchronizing information across the clients and server. Using this model keeps code and entity management simpler and offers performance benefits by not requiring a network state check on a timer.

Important:

Multiplayer components are the only built-in way to communicate between entities in O3DE. Due to the engine’s ability to distribute and interact with entities across multiple hosts, there is no guarantee that any two entities have authoritative representations on the same host.

Network properties

The O3DE Multiplayer Gem uses delta replication to transmit property changes across hosts. The delta replication method uses a system where a server maintains information about both the last acknowledged state of each client and the current world state, and then sends the differences between the two states across the network. When the client receives this information, it updates the world state if the packet was received in the correct sequence.

One important consideration of this style of replication is that it requires the client to send an acknowledgement (ACK) message back to the server. The O3DE AzNetworking framework offers reliable UDP packets, including acknowledgement.

Without taking advanced networking features into consideration, a server checks for a delta on every frame by:

1. Inspecting a snapshot of the world state against each client’s acknowledged state.
2. If the world state is different from the last state that resulted in an ACK, generate a delta for that client.
3. Transmit the delta to the client.

Then, clients update themselves from a delta by:

1. Checking if the received delta is in sequence.
2. Extracting the delta information and updating the world state.

After, the AzNetworking layer becomes aware that the world was updated. This occurs automatically through ACK vector replication, and does not require any further action from the client.

Remote procedure calls (RPCs)

Developers can use remote procedure calls in O3DE to invoke a function on a remote endpoint. An RPC is a useful mechanism for signaling and notifying about events across networked endpoints. Unlike network properties, a developer chooses when to invoke an RPC. RPCs are not guaranteed to arrive in the order they are sent. O3DE offers both reliable and unreliable RPCs. By default, RPCs are reliable.

Reliable RPCs use a queue to guarantee the delivery of a message. When sending any reliable packet, the packet is also inserted into a priority queue and given a timeout value that’s related to the latency of the connection that the message is sent on. On timeout, if the reliable packet was not explicitly acknowledged, the packet will be retransmitted. On the receiving end, the O3DE client tracks every reliable packet received and guarantees that any packet will be delivered only once. While this feature provides guaranteed delivery, it doesn’t provide ordered delivery.

Unreliable RPCs are sent over a “fire and forget” method. The host sending the message has no way to ensure that the message was received.

Multiplayer entity roles

Because each entity with a multiplayer component is replicated across the network, you can think of them as existing on more than one host simultaneously. This consideration introduces the problem of authority over the network - which hosts have precedence to set the network state, define the replication rules, and determine which roles a host can play. In O3DE, these roles are intentionally compile-time enforced. The Multiplayer Gem assigns and handles the roles of multiplayer entities automatically.

The roles offered for O3DE multiplayer hosts are:

• Client (NetEntityRole::Client): The lowest privilege role for a component. The smallest possible subset of network properties are replicated to this role, and its behavior is strictly read-only. This role is used on client entities that are controlled by a host, and should contain only presentation logic and act as a proxy for invoking RPCs. Examples of entities that should use this role are AIs and other players moving in the world.

• Autonomous (NetEntityRole::Autonomous): A role with the illusion of write access. Autonomous roles are usually assigned to components directly under local user control. These roles receive a larger amount of network information than a Client role. Autonomous roles can also take advantage of predictive networking.

• Authority (NetEntityRole::Authority): The role with ultimate authority. It has full read and write access to all network properties on the component.

In addition to the previously described roles, O3DE has an additional role found only in multiserver instances:

• Server (NetEntityRole::Server): Provided to servers that don’t have authority over a particular entity. This role is strictly read-only, and all interaction with these entities should be handled using RPCs.

Related topics