Dedicated Servers

Overview

Fusion enables the development of games using the client-server topology. In this case, a dedicated game session instance runs on a dedicated server provided by a hosting provider which players connect to with their client.

There are several parts involved in leveraging the dedicated server topology, these include:

• the Fusion Headless build;
• the Dedicated Game Session Instance running on the Dedicated Server;
• the Dedicated Server Machine from your preferred Hosting Provider;
• the Photon Cloud with the Fusion Cloud Plugin; and,
• the Clients that will connect to the Dedicated Game Instance.

Host Mode vs Server Mode

The first step when developing a with Client-Server architecture in Fusion is chosing between Host Mode and Server Mode. Both offer the same feature set and work identically as far as the codebase is concerned. The only difference to be conscious of is the following:

• In Host Mode, the "server" will have State Authority and a player with Input Authority; whereas,
• In Server Mode, the "server" will have State Authority but no player or Input Authority attached to it.

This means development can start with Host Mode as it is simpler to test and later move to Server Mode once the project team is ready to tackle the server orchestration aspect necessary for running game session instances on one or multiple dedicated game servers.

Dedicated Server

To run Fusion in Server Mode a dedicated server is needed to host the headless game build.

There are two types of dedicated servers in the context of Fusion:

1. Dedicated Game Session Servers; and,
2. Dedicated Photon Cloud Servers.

Dedicated Game Session Servers

Dedicated Game Session Servers are offered by hosting providers to host the headless game build. To spin up game session instances upon request for players to join, an orchestration service needs be involved (usually offered by the hosting providers as well).

Dedicated Photon Cloud Servers

Dedicated Photon Cloud Servers are offered by Photon. To request one, an Enterprise subscription is needed. Dedicated Photon Cloud Servers provide and allocate dedicated cloud resources to a game's needs.

The Photon Cloud handles:

• connection handling;
• relay fallback; and,
• state backup for server migration;

Additionally, the enterprise subscription offers:

• the ability to run custom version of the Fusion Cloud Plugin (not available yet);
• Dedicated IPs;
• SLA;
• 24/7 NOC team;
• and more.

To run a game in Server Mode a dedicated game server is needed as well as a Photon Fusion Cloud subscription.

Game Session Hosting Providers

Popular hosting providers include but are not limited to:

• Multiplay
• Gameye
• PlayFab
• GameLift

It is of course possible to use custom solutions and standalone docker instances if so desired.

Game Session Instance

A game session instance is spun up on the dedicated server upon request by the orchestration service. How this process works is independent from Fusion and tied to the Game Session Hosting Provider and Orchestration Service's own systems. Please reach out to them and read through their documentation on this subject.

Creating a Headless Build

Fusion Headless builds support all 64-bit platforms Unity is able to build towards. To create a headless build, simply:

1. Navigate to the File > Build Settings... in the Unity Editor.
2. Select the Target Platform.
3. Ensure the Architecture is set to 64-bit.
4. Click on Build.

Game Server Orchestration

Server Orchestration refers to the way Game Servers are being managed; this includes spinning them up and down on demand, as well as creating Game Sessions on them upon player request. As such a server orchestration service's main purposes can be summarized as a set of rules or systems which will control the availability of servers for players to join and play on. This will also help keep cost as low as possible by saving computing power when the player demand is low (e.g. during the middle of the night or day).

An Orchestration Service is responsible for:

1. Storing a copy of the Game Server build, so it can be used for deployment using.
2. Managing an infrastructure of machines able to run the Game Server. The model used by each provider can vary and can be bare metal servers or virtual machines and even Docker containers. There is no right or wrong model, as they suit the needs of different games with different servers environment requirements.
3. Providing a spawn and destroy control system that enables the developer to choose which Game Server to deploy, where (usually it can be deployed in several regions), and with which settings (so it suits players). This system can be managed either manually, via APIs, or automatically by a set of trigger rules.

From the perspective of Fusion, this is all transparent as at this level of management, it is being dealt with how to run the instance and where, so it does not impact the development directly.
On the other hand, most of the orchestration and hosting providers make use of internal integrations on the Game Server itself in order to extract information like:

• Information about the match, like game mode or map, for example;
• The current number of players and max number of players;
• Server health status (e.g. starting, ready for players, shutting down);
• and more.

These pieces of information are used by the orchestration system in order to know which servers are available for joining, which ones can be recycled, and to create statistical data over time such as the number of servers to be increased in certain regions over a period of the day when there are more active players.

The Fusion SDK provides all the information and means to easily expose it in order to facilitate the integration with each each own provider's SDK.