Photon Quantum 3 vs Fusion 2 in Unity
Minh Khoa
Author
---
Conclusion in 60 seconds
Just remember two sentences:
- Quantum 3 synchronizes input: all clients receive the same input and run the same deterministic simulation themselves.
- Fusion 2 synchronizes state: the peer with authority creates the official state and then sends that state to the other peers.
| If you prioritize | Lean toward |
|---|---|
| The same result every frame, many entities, natural replays | Quantum 3 |
| Familiar Unity workflow, Unity Physics, plugin, multiple topologies | Fusion 2 |
| Do not want to operate a Unity gameplay server | Quantum 3 standard |
| Full server authority and secret data do not reach the client | Fusion 2 Dedicated |
| Co-op small, social, or rapid prototypes | Fusion 2 Host/Shared |
There is no SDK absolute winner. The right choice depends on what the game needs to synchronize: input or state.
1. The fundamental difference: what is synchronized?
Quantum 3: every machine solves the same problem
All clients have the same rules, initial state, and input for each tick. Because the simulation is deterministic, they independently compute the same result:
Initial State + Input 1 + Input 2 + ... = Same Result
Photon collects, orders, and distributes input. Each client runs the entire gameplay with ECS, fixed point, and deterministic physics. When the real input differs from the prediction, Quantum rolls back and simulates again.
One client locally correcting its position cannot directly force the other clients to receive that position. They still compute state from input and the game rules themselves.
Fusion 2: one peer publishes the official state
In Fusion, a peer with State Authority writes the state of the network object. The other peers receive snapshots and display or predict that state.
Client Input -> Authority Simulation -> State Snapshot -> Clients
Authority can live on a Unity Dedicated Server, the Host machine, or be distributed among players in Shared Mode.
Fusion still has prediction, rollback/resimulation and interpolation. The difference is that the final source of truth is still the state published by authority.
A short example
Suppose the player presses the button to move right:
| Quantum 3 | Fusion 2 |
|---|---|
Input Right is sent to every client | Input Right is sent to the authority |
| Every client computes the new position themselves | The authority computes the new position |
| The machines must produce the same result | The authority sends the position/state to the client |
| A difference is a desync error | The client that is wrong will be corrected by the official state |
2. Overview comparison table
| Criterion | Quantum 3 | Fusion 2 |
|---|---|---|
| Main model | Deterministic input sync | State synchronization |
| Code architecture | Entity, Component, System | GameObject, Component, NetworkBehaviour |
| Simulation arithmetic | Fixed point | Usually uses familiar number types and Unity API Physics |
| Deterministic Physics | of Quantum 2D/3D Unity Physics integration | Authority 2D/3D |
| All clients run the same simulation | Dedicated, Host, or Shared authority | Default gameplay server |
| No Unity gameplay server needed | Only needed when choosing Dedicated | Primary transmitted data |
| Small per-tick input | State, delta, | and input RPC }]} |
| Increase the number of entities | Increase CPU simulation on every client | Increase state replication and CPU authority |
| Replay | Very naturally from input + initial state | Needs to design recording state/input appropriately |
| Hidden information | Harder because of perfect information | Dedicated Server may not send secret data |
| Use the Unity plugin | Only View; simulation must be deterministic | Easier to integrate if the plugin supports it runtime/server |
| Familiarity with Unity dev | Higher learning curve | Closer to the traditional Unity workflow |
| Prevent local state tampering | Strong by input-sync design | Depends on topology; Dedicated is strongest |
Do not read the table as “yes or no.” Both SDK can solve many game genres, but the difficulty, cost, and technical risk will differ.
3. How does the Unity developer workflow change?
When using Fusion 2
You still think quite close to Unity:
GameObject
└── NetworkObject
└── NetworkBehaviour
├── [Networked] state
├── FixedUpdateNetwork()
└── RPC
Key points to remember:
NetworkRunner: manages sessions, ticks, input, and replication.NetworkObject: the identity of an object on the network.[Networked]: state is snapshotted and synchronized by Fusion.State Authority: the peer is allowed to decide state.Input Authority: the player is attached to the object to send input and prediction.FixedUpdateNetwork(): where gameplay runs according to the network tick.- RPC: a message at a point in time, not a replacement for persistent state.
You can continue using scenes, prefabs, Animator, Rigidbody, and many familiar Unity packages. However, important gameplay still must follow the authority model.
When using Quantum 3
You split the project into two worlds:
SIMULATION VIEW
Entity + Component + System GameObject + MonoBehaviour
Frame + FP + deterministic API Camera + VFX + Audio + UI
Nguồn sự thật gameplay Biểu diễn state lên màn hình
Key points to remember:
Frame: the entire state of the simulation at a tick.- Entity/Component/System: gameplay structure ECS.
.qtn: declares components, input, and data for code generation.FP,FPVector2,FPVector3: the fixed-point type used in the simulation.- Predicted Frame: a frame that may still use predicted input.
- Verified Frame: a frame that has been confirmed by official input.
- Event: tells the View to display effects, not where gameplay state is kept.
The simulation should not call arbitrarily UnityEngineruntime or rely on nondeterministic results. Camera shakes, particles, and audio are in the View; damage, movement, and win/lose rules are in the Simulation. float With Fusion, you learn
network authority . With Quantum, you also learn anew gameplay architecture 4. The rollback of the two.
is not the same SDK Quantum 3
| Fusion 2 | Predict remote input when the real input has not arrived yet |
|---|---|
| The client predicts its own state in advance | If the real input differs from the prediction, roll back to an old frame |
| If the authority snapshot differs from the local state, reconcile | Rerun the deterministic world |
| Rerun the predicted simulation part | is the confirmed input marker |
Verified Frame The authority state is the official result | Both sides use rollback to hide latency. The shortest way to remember it: |
Quantum rolls the world back from input. Fusion reconciles state around authority.
5. Physics,
and performance AI Topic
| Quantum 3 | Fusion 2 | Physics |
|---|---|---|
| Physics | dedicated deterministic 2D/3D Integrate Unity Physics | Usually runs on every client |
| AI | Usually runs on the authority | Network |
| reasoning | Mostly small input | State delta, input, and RPC |
| Many entities | Increase CPU across all clients | Increase CPU authority and replication |
| Optimize traffic | Less dependent on the number of changed transforms | Delta compression and Area of Interest |
| The cost of rollback | Frame history and resimulation | Predicted state and resimulation |
Quantum is suitable when many entities all follow a compact simulation. Fusion is advantageous when you need Rigidbody, the Unity plugin, or want to offload AI heavy work to the server.
Neither side is always lighter. Quantum can be heavy on mobile because every client runs the whole world; Fusion Dedicated can be heavy on the server and bandwidth. Profile the vertical slice on real devices and the actual topology.
6. Anti-cheatThe most easily misunderstood part:
Quantum is not by default a server-authoritative simulation
In the standard Photon Cloud configuration, the server coordinates input but does not necessarily run the gameplay simulation.
- Changing local HP or position does not change other players' state.
- Deterministic rules still block results that the simulation does not allow.
- Bots, input automation, and client-sent data still need to be protected.
- Rank, rewards, and economy should be validated by webhook, replay/resimulation or by custom server simulation depending on the level of risk.
The major trade-off is perfect information: each client usually has the data needed to simulate the world, except for future inputs from opponents.
Fusion depends on topology
| Topology | Typical trust level |
|---|---|
| Dedicated Server | The server holds state and validates gameplay, the strongest |
| Host Mode | The host can modify the game or view data |
| Shared Mode | Authority lies with the client, suitable for less competitive games |
Fusion Dedicated also has a major advantage with hidden information: the server only sends state that the client is allowed to know. This matters for:
- Unrevealed cards.
- Truly secret fog of war.
- Anti-cheat logic that should not be moved to the client.
Quantum protects well against one client modifying state and then spreading it. Fusion Dedicated is stronger when you need a server that runs the rules itself and keeps secrets from the client.
7. Hosting and cost
| Option | Gameplay hosting | Trade-off |
|---|---|---|
| Standard Quantum | Photon coordinates input, no Unity server needed per match | Every client simulates, perfect information |
| Custom Quantum server | Separate simulation infrastructure | Higher trust, more operational cost |
| Shared | No separate simulation server | Distributed trust |
| Host | One player acts as the server | Cheap, but the host has an advantage |
| Dedicated | Separate fleet of headless Unity instances | Full control, more operational cost |
Standard Quantum still has Photon and game backend costs. Fusion Dedicated requires an orchestrator to provision machines, ports, regions, health checks, and shutdown processes; Photon Cloud does not automatically host Unity server builds for you.
8. Choose by game genre
| Game | Usually the better choice | Why |
|---|---|---|
| Many-unit RTS | Quantum 3 | Deterministic AI/pathfinding, small input, natural replay |
| Fighting, sports, arena | Quantum 3 | Collision frame-sensitiverollback is the foundation |
| FPS ranked | Fusion 2 Dedicated | Server validate hit/damage, lag compensation, hidden state |
| Co-op four players | Fusion 2 Host/Shared | Fast workflow, not necessarily needing a server fleet |
| Card game with hidden cards | Fusion 2 Dedicated | Server keeps cards that are not yet allowed to be revealed |
The examples above are trends, not hard rules. Prototype a vertical slice and measure before locking the architecture.
9. Decision checklist
### Choose Quantum 3 when most answers are “yes”
- Does the game need a deterministic result per frame?
- Are there many entities running under the same ruleset?
- Want to avoid operating a Unity gameplay server?
- The team accepts ECS, fixed point, and separation Simulation/View?
- Is the gameplay data mostly able to appear on the client?
Choose Fusion 2 when most answers are “yes”
- Does the team want to keep a GameObject familiar workflow?
- Does the game depend on Unity Physics or Unity plugins?
- Need Dedicated, Host, and Shared for different modes?
- Must the server keep data or logic secret?
- Need full server authority for rank/economy?
The deciding question
Nếu mọi client có cùng input, game của bạn có thể và nên
tự tạo ra cùng một kết quả tuyệt đối không?
- Yes: study Quantum seriously.
- No, or do not want to be constrained like that: Fusion is usually more natural.
10. Moving from Fusion to Quantum is not a package change
This is usually a one-time rewrite of the gameplay architecture:
| Fusion 2 | Quantum 3 |
|---|---|
NetworkObject | Entity |
NetworkBehaviour | System |
[Networked] property | Component data in Frame |
float, Vector3 | FP, FPVector3 in Simulation |
| Unity Physics | Quantum deterministic physics |
| Authority peer runs the gameplay | All clients run the same simulation |
| RPC/state event | Input, command, signal, and event according to their proper roles |
Prefab, animation, VFX and UI can be reused in the View. Movement, combat, physics, AI and game rules usually have to be redesigned, so choose the simulation model early.
Conclusion
Choose Quantum 3 when the game fits deterministic simulation and input sync. Choose Fusion 2 when you need state sync, a familiar Unity workflow, or flexible authority; use Fusion Dedicated when the server must act as the referee and keep secrets from the client.
Final takeaway:
Quantum 3 = Cùng input -> Cùng simulation -> Cùng kết quả
Fusion 2 = Gửi input -> Authority xử lý -> Đồng bộ state