Existing Fusion Project? Read This First

Integrating the Runtime Spawner into an existing Fusion project

If your project already uses Photon Fusion with a custom pooling setup, please read this section before enabling Runtime Spawner’s Fusion integration.

Fusion Pool Provider (Optional, Recommended)

Runtime Spawner does not require a custom Fusion pool provider in order to function.

You can use Runtime Spawner with Photon Fusion’s default spawning behavior or your existing custom pooling solution without enabling any additional provider.

However, Runtime Spawner also includes an optional Fusion Pool Provider that can simplify pooling and lifecycle management in many projects.

---

When You Do Not Need the Pool Provider

You do not need Runtime Spawner’s Fusion Pool Provider if:

• Your project already uses:

  • Fusion’s default NetworkObjectProvider, or

  • A custom INetworkObjectProvider, or

  • A project-specific pooling system that already works reliably

• You are happy with how objects are currently:

  • Spawned

  • Despawned

  • Reset

  • Recycled

• You only need Runtime Spawner for spawn logic, population control, and orchestration, not for pooling ownership

In these cases, Runtime Spawner will operate correctly without replacing Fusion’s provider.

---

When the Pool Provider Is Useful (Recommended)

Runtime Spawner includes an optional component:

FusionPoolObjectProvider

When enabled, this component becomes the single INetworkObjectProvider for the NetworkRunner.

Fusion only allows one provider at a time.

Enabling it means:

• Any existing provider (custom or default) is replaced

• Fusion continues to handle network lifecycle

• Runtime Spawner becomes responsible for object pooling and reuse

This setup is recommended if you want:

• Unified pooling for:

  • Runtime Spawner–spawned objects

  • Network-spawned objects

• Consistent despawn → recycle behavior

• Centralized population tracking

• Network-safe cleanup before objects return to the pool

• Fewer edge cases around “half-despawned” or reused network objects

---

What Changes If You Enable It

If you enable FusionPoolObjectProvider:

• Runtime Spawner becomes the pooling authority

• Fusion still owns:

  • Network state

  • Replication

  • Authority rules

• Runtime Spawner manages:

  • Object reuse

  • Reset timing

  • Pool warmup and expansion

This ensures:

• Correct reuse of pooled network objects

• Deterministic despawn behavior

• Clean reset before objects re-enter the pool

• Better alignment with Runtime Spawner’s population systems

---

If Your Project Already Has Pooling Logic

If your Fusion project already uses custom pooling behavior, you have three supported options:

Option 1: Prefab-Level Pool Logic (Recommended)

Move spawn / reset logic onto the prefab itself using:

• OnEnable

• OnDisable

Runtime Spawner guarantees these are called at the correct times when objects are spawned or returned to the pool.

This is the simplest and most robust approach.

---

Option 2: Runtime Spawner Events

If you need global visibility over spawned objects:

• Subscribe to Runtime Spawner’s spawn/despawn events

• Apply custom logic there (telemetry, bookkeeping, gameplay hooks)

This keeps pooling centralized while still allowing customization.

---

Option 3: Advanced — Wrap the Provider

If you must keep provider-level behavior:

• Implement a wrapper INetworkObjectProvider

• Forward calls to FusionPoolObjectProvider

• Inject custom logic before or after forwarding

This approach is advanced and only recommended for projects with very specific integration requirements.

---

TL;DR

• Runtime Spawner does not require a custom Fusion pool provider

• The Fusion Pool Provider is optional but recommended

• Use it if you want Runtime Spawner to own pooling and reuse

• Skip it if your existing Fusion pooling setup already works

• You can always migrate later if your needs change