Coming From Bolt

Introduction

This document will describe the major differences between Photon Bolt and Photon Fusion in terms of API, and how you can port sections of your Game written in Bolt into a Fusion project.
Bolt and Fusion share a lot of concepts, but the usage, API, and mainly the general behaviors are different.

Fusion Modes

What is very important to understand when coming from Bolt to Fusion is that Bolt only offers server/host topology while Fusion offers and additional Shared Mode which is fully client authoritative (Similar to Photon Unity Networking).

Most concepts that exist in Bolt are transferable to Fusion Host/Server Mode but NOT to Shared Mode.
This page explains how to migrate your Bolt knowledge to Fusion Server/Host Mode.

Differences

Here is a list of all major differences between Photon Bolt and Photon Fusion:

• On Bolt, the general API can be accessed via either the static classes BoltNetwork and BoltMatchmaking, in Fusion that is done using an instance of the NetworkRunner.
• Fusion can run multiple peers from the same executable, while Bolt can run only one. This means that it's possible to run several clients from the same instance of the game. This is useful for testing and debugging purposes.
• Fusion has full support for Physics prediction and rollback by using the built-in NetworkRigidbody and NetworkRigidbody2D components, on Bolt, this needs to be handled/implemented by the developer. The same applies when dealing with Character Controllers, Fusion has the NetworkCharacterController that works out of the box as a base implementation to move the player's character, while in Bolt, that also need a custom implementation.

Similarities

Here is a list of all major similarities between Photon Bolt and Photon Fusion:

• Fusion has the concept of a NetworkObject, which represents a Unity Game Object that has networked properties used to synchronize data across the peers, Bolt has the same concept under the name of BoltEntity. The State of a NetworkObject can be described on any NetworkBehaviour using the Networked attribute, in order to do this on Bolt, it is necessary to create and configure properties using the Bolt Assets window creating/editing a State asset. More info.
• All main SDK Events (start, shutdown, disconnect, among others), are handled in Bolt using instances of GlobalEventListeners, Fusion exposes this kind of event via the implementation of INetworkRunnerCallbacks associated with a NetworkRunner.
• Both SDKs have the concept of State Authority and Input Authority, although it is called Ownership and Control on Bolt, they have exactly the same meaning. More info.
• Fusion is also a predict-rollback system, similar to Bolt. While in Bolt there are Commands sent by the Controller of a BoltEntity, in Fusion this is done sending NetworkInputs from a peer that has Input Authority over a NetworkObject, but differently of Bolt, where the rollback (State reset) is done manually (within an ExecuteCommand with the resetState = true), in Fusion that is automatically at the beginning of a new Frame before the call of the FixedUpdateNetwork method.
• For every controlled BoltEntity, Bolt calls the SimulateController method on the respective EntityEventListener associated with the Entity. This is done differently on Fusion, as there are no multiple sources of NetworkInput (Command on Bolt), and only 1 NetworkInput can be associated with a specific Frame for all NetworkObjects. This is done via the implementation of an INetworkRunnerCallbacks.OnInput callback. More info.
• The well-known Remote Procedure Calls (RPCs) on Fusion are called Events on Bolt. They have very similar controls (who can send, who can receive, and reliability) but can be defined directly via code on Fusion, while in Bolt it is necessary to set them up using the Bolt Assets window. More info.
• Fusion has a lot of built-in components that help with the synchronization of common types of data, one example of this is the NetworkTransform, which can be mapped to a Transform Property on Bolt. Both are used to synchronize the position and rotation of a Game Object while providing a smooth transition between snapshots, capable of interpolating between data points. More info.
• Fusion is also capable of synchronizing only the desired set of NetworkObject using the Area of Interest API. More Info.
• On both SDKs there is the concept of a Scene Object, which is a pre-created NetworkObject associated with a Scene. When that particular scene is loaded, these objects are automatically attached to the simulation.
• Another solution implemented on both SDKs is the Lag Compensated Physics Checks used mainly to detect collisions with Raycasts considering the lag between shooters and targets. More info.

Reference Table