This page is a work in progress and could be pending updates.
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.
The Photon Server SDK is NOT related to the Dedicated Server topology in Fusion!
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:
Host Mode, the “server” will have State Authority and a player with Input Authority; whereas,
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.
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:
- Dedicated Game Session Servers; and,
- 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
A subscription to the Photon PUBLIC CLOUD is sufficient!
A Photon ENTERPRISE CLOUD subscription is only necessary to access the features & services which can only be offered in a dedicated environment.
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;
- 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:
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:
- Navigate to the
File > Build Settings...in the Unity Editor.
- Select the
- Ensure the
Architectureis set to 64-bit.
- Click on
Game Server Orchestration
Photon does NOT offer dedicated game session server orchestration. Orchestration services are usually offered by game session hosting providers themselves and focus on maintaining the Game Server binaries linked to their systems for management.
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).
Orchestration Service is responsible for:
- Storing a copy of the
Game Serverbuild, so it can be used for deployment using.
- 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.
- Providing a spawn and destroy control system that enables the developer to choose which
Game Serverto 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.