This page is a work in progress and could be pending updates.
Coming From Bolt
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.
Here is a list of all major differences between
Photon Bolt and
- On Bolt, the general API can be accessed via either the static classes
BoltMatchmaking, in Fusion that is done using an instance of the
- 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-Serverarchitecture, Fusion also supports the
Shared Mode, which is more similar to how
PUNworks. Also, Fusion has support to both
Eventual Consistency, in comparison, Bolt only supports the latter.
- Fusion has full support for Physics prediction and rollback by using the built-in
NetworkRigidbody2Dcomponents, on Bolt, this needs to be handled/implemented by the developer. The same applies when dealing with
Character Controllers, Fusion has the
NetworkCharacterControllerthat works out of the box as a base implementation to move the player's character, while in Bolt, that also need a custom implementation.
Here is a list of all major similarities between
Photon Bolt and
- Fusion has the concept of a
NetworkObject, which represents a Unity
Game Objectthat has networked properties used to synchronize data across the peers, Bolt has the same concept under the name of
BoltEntity. The State of a
NetworkObjectcan be described on any
Networkedattribute, in order to do this on Bolt, it is necessary to create and configure properties using the
Bolt Assetswindow creating/editing a
Stateasset. 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
INetworkRunnerCallbacksassociated with a
- Both SDKs have the concept of
Input Authority, although it is called
Controlon 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
BoltEntity, in Fusion this is done sending
NetworkInputs from a peer that has
Input Authorityover a
NetworkObject, but differently of Bolt, where the rollback (State reset) is done manually (within an
resetState = true), in Fusion that is automatically at the beginning of a new Frame before the call of the
- For every controlled
BoltEntity, Bolt calls the
SimulateControllermethod on the respective
EntityEventListenerassociated with the
Entity. This is done differently on Fusion, as there are no multiple sources of
Bolt), and only 1
NetworkInputcan be associated with a specific
NetworkObjects. This is done via the implementation of an
INetworkRunnerCallbacks.OnInputcallback. more info.
- The well-known Remote Procedure Calls (
RPCs) on Fusion are called
Eventson 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 Assetswindow. 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 Propertyon Bolt. Both are used to synchronize the position and rotation of a
Game Objectwhile 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
Area of InterestAPI. more info.
- On both SDK there is the concept of a
Scene Object, which is a pre-created
NetworkObjectassociated 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 Checksused mainly to detect collisions with Raycasts considering the lag between shooters and targets. more info.
|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|