Photon Fusion 2 Host Mode vs Shared Mode for an 8-player co-op game worried about host-migration glitches

Direct answer

In an 8‑player physics‑heavy co‑op session, host‑migration in Fusion 2 Host Mode will usually produce a visible tick jump when physics interpolation (or extrapolation) is enabled on NetworkRigidbody objects. The jump appears as a brief stutter or position shift because the new host resumes the simulation from the last persisted snapshot, which can be ahead of or behind the current tick.

There is no public Fusion 2 API to customise the state‑reconciliation step during migration, so the only supported ways to mask the effect are client‑side techniques such as input replay, physics smoothing, or temporarily disabling interpolation during the migration window. If you can guarantee that interpolation is disabled for all NetworkRigidbodies, the tick jump is far less noticeable and Host Mode may be acceptable.

Confirmed facts

• Host Mode stores authority on a client; on host loss the new host reconstructs the simulation from the most recent snapshot and continues at that snapshot’s tick.
• Shared Mode uses a Photon‑managed game server as permanent authority, eliminating host migration but adding per‑CCU server CPU cost and one extra network hop.
• Fusion 2 does not expose a callback or hook to intervene in the migration state‑reconciliation process.
• Photon Cloud pricing models show a typical cost crossover toward Shared Mode when sustained CCU exceeds roughly 50–100 (depending on region and tier).

Likely explanation

The visibility of the tick jump depends on how your physics is presented:

1. With interpolation enabled, each frame renders a smoothed position between ticks. When the host changes and the tick count jumps, the smoothed position must be recomputed, causing a noticeable snap or stutter.
2. With interpolation disabled (pure fixed‑step rendering), the visual update follows the simulation tick directly; a tick jump results in a single‑frame position correction that is often less perceptible, especially if the fixed timestep is small.

Steps to evaluate for your project

1. Check the Interpolation property on your NetworkRigidbody components (enabled/disabled).
2. If enabled, run a local test: simulate a host disconnect with 8 NetworkRigidbodies, record tick counts and visual output with interpolation on.
3. If the jump is objectionable, either disable interpolation for those objects or implement a client‑side smoothing buffer that ignores the first few frames after a migration event.
4. If interpolation is already disabled, Host Mode is likely acceptable; monitor host‑disconnect frequency in playtests to confirm.
5. Estimate your expected sustained CCU (peak concurrent users). If it regularly approaches or exceeds 50–100, compare the per‑CCU server cost of Shared Mode against the risk/cost of handling migrations.

Missing diagnostic detail

Whether you are using physics interpolation/extrapolation on NetworkRigidbody changes the recommendation: if interpolation is enabled, Host Mode’s migration tick jump is likely noticeable and you should consider mitigation or Shared Mode; if interpolation is disabled, the jump is usually tolerable and Host Mode may be sufficient. Please confirm your interpolation setting.