Photon Fusion Networked Transform: Syncing Fast‑Moving Objects Without Manual State Management

The problem: jittery movement in multiplayer

\n

When you replicate a GameObject’s position across the network, naïve solutions (sending the transform every frame) quickly saturate bandwidth and still leave clients with visible stutter because each packet arrives at a slightly different time. Photon Fusion’s NetworkedTransform component was built to remove that boilerplate: it records a snapshot each frame, interpolates deterministically on the client, and optionally runs a lightweight prediction step so fast‑moving objects feel responsive.

\n\n

Why Networked Transform solves it

\n

\n
• Automatic snapshots – The component captures position, rotation, and scale in FixedUpdate without any custom code.
\n
• Deterministic interpolation – Clients replay snapshots using Fusion’s shared tick clock, so every client renders the same interpolated state.
\n
• Configurable delay – InterpolationDelay (in ticks) lets you trade a few milliseconds of perceived lag for smoother motion.
\n
• Optional prediction – Enabling the Prediction flag runs a client‑side physics step ahead of the authoritative snapshot, reducing jitter on high‑speed objects at the cost of extra CPU.
\n

\n\n

Configuring interpolation delay

\n

The InterpolationDelay property is expressed in Fusion ticks (default 2). A lower value reduces the time between the authoritative snapshot and what the client renders, but any network jitter shows up as micro‑stutters. A higher value smooths those out but adds a constant latency that players may feel on twitch‑style gameplay.

\n\n\n\n\n\n\n\n\n\n

InterpolationDelay (ticks)	Typical smoothness	Perceived lag
1	Sharp, occasional jitter	~16 ms (60 Hz tick)
2 (default)	Balanced	~32 ms
4	Very smooth	~64 ms

\n

Pick the smallest value that still hides your network’s jitter profile. Test by artificially adding latency with NetworkRunner.LagSimulation in the Unity Editor.

\n\n

Enabling prediction and its cost

\n

Set NetworkedTransform.Prediction = true on the component. Fusion will run a client‑side prediction step using the same physics scene as the server. This works well for kinematic objects (e.g., player‑controlled characters) but adds a measurable CPU spike: expect ~0.3 ms per predicted object on a modern desktop CPU (Unity 2022.3, Fusion 2.1). Profile with the Unity Profiler (Window → Analysis → Profiler) while the scene runs with two local clients.

\n\n

Worked example: two‑player test scene

\n

\n
1. Create a new Unity 2022.3 LTS project and import Photon Fusion 2.1 via the Package Manager.
\n
2. In a fresh scene, add two empty GameObjects named PlayerHost and PlayerClient.
\n
3. Attach a NetworkObject component to each, then add NetworkedTransformBehaviour (this auto‑adds the NetworkedTransform component).
\n
4. On PlayerHost, set NetworkedTransform.InterpolationDelay = 2 and leave Prediction unchecked.
\n
5. On PlayerClient, set the same delay but enable Prediction.
\n
6. Add a simple movement script (see below) to both objects so they move forward at 10 m/s.
\n
7. Enter Play mode, open the Fusion Debugging console (Window → Photon Fusion → Debugging), and start a Host + Client session (use the Start Host and Start Client buttons).
\n
8. Observe the positions in the Scene view: the host object follows the authoritative path; the client object interpolates smoothly. Toggle Prediction on the host to see the extra CPU usage in the Profiler.
\n

\n

using UnityEngine;\nusing Photon.Fusion;\n\npublic class ConstantMover : NetworkBehaviour\n{\n    [SerializeField] float speed = 10f;\n    public override void FixedUpdateNetwork()\n    {\n        transform.position += Vector3.forward * speed * Runner.DeltaTime;\n    }\n}\n

\n

Where to run: Unity Editor (Play mode) with two local Fusion runners. Permissions: Editor play‑mode access; no special OS privileges. Placeholders: Replace speed with your gameplay value. Expected checks: In the Fusion Debugging console, snapshot timestamps for both objects should be within one tick of each other. Risks: Running two local runners can consume ~2 GB RAM on large scenes; close other heavy applications.

\n\n

Trade‑offs and limits

\n

\n
• Bandwidth – Each NetworkedTransform sends a snapshot per tick (default 60 Hz). For 100 moving objects that’s ~100 KB/s upstream; consider disabling interpolation on static props or batching updates via NetworkedTransform.SnapshotRate.
\n
• Clock drift – Fusion synchronizes clocks at session start, but long sessions (>30 min) can accumulate drift. Periodically call Runner.ResynchronizeClocks() if you notice growing interpolation error.
\n
• Prediction artifacts – When the server corrects a predicted state, you may see a brief “snap”. Test with your specific mechanics (e.g., collisions) before shipping.
\n
• FixedUpdate dependency – The component assumes a fixed timestep. If you change Time.fixedDeltaTime at runtime, snapshots become inconsistent; keep the timestep constant or manually reset the component.
\n

\n\n

Actionable next steps

\n

\n
1. Add the test scene to your project and verify snapshot alignment in the Fusion Debugging console.
\n
2. Profile CPU with prediction on/off for your target object count.
\n
3. Adjust InterpolationDelay until jitter disappears without noticeable input lag.
\n
4. If bandwidth spikes, mark non‑essential objects with NetworkedTransform.Enabled = false or lower their SnapshotRate.
\n
5. Schedule a clock‑resync call for sessions longer than 20 minutes.
\n

\n

With these steps you’ll have a deterministic, low‑maintenance transform sync that scales from a handful of players to dozens of fast‑moving entities.