State Transfer

Introduction

Fusion supports many network architectures, all of which rely on state transfer. Fusion is built with simplicity in mind and integrates naturally into the Unity workflow, while offering advanced state transfer features such as delta compression, client-side prediction and lag compensation straight out of the box.

State Transfer Primer

The term "state-transfer" refers to how the game state is distributed to all clients. In a state transfer architecture, the game state is transmitted from the server to the clients. The state contains everything needed for the client to replicate the game state locally. Fusion exposes the game state through properties on specialized MonoBehaviourss known as NetworkBehaviours. The full set of [Networked] properties of all networked game objects at a specific moment in time (tick) is called a Snapshot.

The two state transfer modes used by Fusion are:

1. Delta-Compressed, or DC, which sends compressed full world snapshots; and,
2. Eventual Consistency, or EC, which uses interest-management filters to decide what part of the full game state will be included in the snapshot sent to each client.

In either case, due to network latency, the reconciled state is already outdated by the time the client receives it. To compensate Fusion will re-simulate the state of the local [Networked] properties from most recently received state up to the last predicted tick from previous updates (approximately snapshot tick plus RTT). From here Fusion may further predict a new future state to match where the server is expected to be when it next receives input from the client.

In Eventual Consistency mode, the data received represents only a subset of the total network state. This is transparent to the application as the state is always exposed by the same properties on the given set of NetworkObjects.

Client- vs. Server-Authority

Fusion can run in two different authority modes:

• server-authority mode: a strict Client/Server setup with a dedicated headless Unity instance where one of the clients is acting as both server and client (Host);
• client-authority mode: each client has full authority over its own objects.

In client-authority mode there are no re-simulations, all clients always simulate forward and must accept the state snapshots they receive from other clients as the present truth.

Compression

The obvious downside to state-transfer is bandwidth usage. Fusion goes to great length to reduce package sizes by only sending changes to the networked game state and by selecting a minimal bit-level representation for that data; in the case of Eventual Consistency, it is reduced even further to only include changes relevant to the recipient.

Accuracy

A key aspect of compressing data efficiently is Accuracy. In Fusion, this can be set on a global level in the NetworkProjectConfig > Accuracy Defaults or for each individual variable using the [Accuracy] attribute.

Accuracy is used by Fusion to convert floating point numbers into integers. For example, instead of having a float between 0.00 and 1.00 with two decimals accuracy, Fusion will store a single integer between 0 and 100. Although the value is still requires the same amount of memory usage (4 byte), it can be compressed much more efficiently thus saving in bandtwith. The application can reduce its transfer footprint by selecting meaningful accuracies for all networked properties.

Delta Compression

Using the previously defined accuracy, the delta is compressed in a way that reduces the number of actual bits that needs to be transmitted; this is where the 4 byte float which has been converted to a 4 byte integer can be reduced to just a few bits thanks to its much more dense bit representation.

Delta compression calculates the difference between the total state of the last tick the client is known to have received, and the total state of the current tick. For example, if the server has confirmation from the client that it has received Tick 95 and it is itself currently at Tick 100, the next delta will be calculated across 5 ticks.

The delta will grow until the server receives confirmation from the client; this usually renders several of the transmitted packages redundant. While this may appear inefficient, the massive advantage it confers to Fusion is that it never has to worry about lost packets. Whatever delta a client receives, it can always be applied to whatever state the client happens to be in. If an older delta appears late, it is simply dropped without consequences to the current state or need for latency inducing recovery procedures.

Fusion is effectively trading a bit of bandwidth for a very large reduction in worst-case latency.

Interest Management

When Fusion is set to run in Eventual Consistency mode, it possible to further reduce bandwidth requirements by utilizing the API to controlling what data is sent to each player; this is commonly referred to as "Interest Management".

This can dramatically reduce the amount of data sent across the wire without affecting the individual player's perception of the world. This is especially true in large game worlds with many players, where interest management is often essential in order to make the game playable.

See the Interest Management documentation page.

Network Topologies

Fusion supports several network topologies.

Dedicated Server

Deploy Unity headless instances with full server authority. This is a classic Client/Server setup which benefits from having a trustworthy authoritative entity with full knowledge of the game world, including physics objects and rendering primitives (even if these are not used). Since dedicated servers are usually hosted on public static IPs there is no need for UDP hole punching or network relays.

The major downside to dedicated servers is the cost of spinning up complete Unity instances for every game session.

Player Hosted

The Player Hosted server mode comes with built-in punch-through and relay as a fallback including full host migration support provided by Photon Cloud. If UDP hole punching fails and Fusion cannot establish direct connections between peers, players will have to connect through a relay; this is a sporadic occurrence and only happens to approximately 1 in 10 players. Although the relay introduces a potential source for additional latency in Player Hosted, it is rarely noticeable in terms of gameplay.

In Player Hosted mode, the local instance is a server, NOT a client. This mode still allows the use of a local player and will poll input for it and interpolates on rendering as expected. Overall the mode is equivalent to a dedicated server (i.e. no noticeable change in game code). It gets rid of the dedicated server cost at the expense of a trustworthy authority; in other words a rogue host can cheat.

Single Player

Fusion allows the network code to run locally without changes. The logic is executed as in Player Hosted mode but without opening an external network conneciton. This frees the application from having to do endless switching on game mode.

Shared Mode

Client authority over photon-cloud with data-driven server-managed snapshots using Eventual Consistency (EC) and interest management also scales to high player counts. Shared mode uses the Photon cloud to achieve some of the advantages of the dedicated server without the massive overhead of running complete Unity instances.

Back to top