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.

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.
• While both solutions support the Client-Server architecture, Fusion also supports the Shared Mode, which is more similar to how PUN works. Also, Fusion has support to both Delta Snapshots and Eventual Consistency, in comparison, Bolt only supports the latter.
• 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 an 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 the set 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 SDK 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

Bolt	Fusion	Description
BoltNetwork, BoltMatchmaking	NetworkRunner	Main API entrypoint
BoltEntity	NetworkObject	Represents a Networked Game Object
BoltEntity State Properties	Networked Properties	Set of synchronized properties
GlobalEventListener	INetworkRunnerCallbacks	General Event handling
EntityEventListener	NetworkBehaviour, SimulationBehaviour	Networked Game Object Event handling
BoltNetwork.Instantiate()	NetworkRunner.Spawn()	Creates a new Networked Game Object
BoltNetwork.Destroy()	NetworkRunner.Despawn()	Removes a Networked Game Object from the simulation
BoltEntity.IsOwner	NetworkObject.HasStateAuthority	Signal if the peer can modify the State of a Networked Game Object
BoltEntity.HasControl	NetworkObject.HasInputAuthority	Signal if the peer that can push inputs to a Networked Game Object
Commands	NetworkInput	Control Structure used to predict on Client and alter the State on the Server
Objects	NetworkStructs	Reusable data structures that contain Networked Properties and can be used in more than one State
Events	RPC	Communication method used to transfer pieces of information that does not need to be part of the simulation
Transform Property	NetworkTransform	Built-in support to synchronize the Transform (position and rotation) of a Networked Game Object
BoltNetwork.LoadScene	NetworkSceneManager	API for switching/loading scenes in a synchronized manner

Back to top