Spawner and Pool Integration

How we use pooling in the Runtime Spawner

The Runtime Spawner doesn’t call Instantiate() directly. Instead, every spawn and despawn request passes through its Factory → Pool Adapter chain.

This abstraction makes the system flexible across both local and networked gameplay modes.

---

1. Integration Overview

flowchart LR
  A[RuntimeSpawner] -->|Spawn request| B[ObjectFactoryAsset]
  B -->|Create instance| C[IObjectFactory]
  C -->|Allocates from| D[IObjectProvider / PoolAdapter]
  D -->|Returns reused instance| E[GameObject]

At a high level:

1. The Spawner requests a new instance.

2. The Factory Asset (e.g., SinglePlayer, Fusion, PUN) delegates to its runtime factory.

3. The factory calls into an Object Provider (local pool or network pool).

4. The provider returns a pre-instantiated object.

When despawned, the same instance returns to the pool for later reuse.

---

2. Default Local Mode

In single-player or offline projects, the SinglePlayerPoolFactory uses a shared PoolAdapter:

var factory = new SinglePlayerPoolFactory(new PoolAdapter());

• Instances are spawned and reused locally.

• Each prefab has its own sub-pool.

• The pool automatically expands as needed.

• You can prewarm objects by calling:

  PoolAdapter.Prewarm(prefab, count);

---

3. Networked Modes

Photon Fusion

• Uses the FusionPoolObjectProvider.

• The host’s spawner calls NetworkRunner.Spawn().

• Fusion manages synchronization across clients while reusing objects via pooled NetworkObject instances.

• Pooling is fully deterministic — all clients see the same spawn order.

Photon PUN 2+

• Uses the PUNPoolPrefabProvider.

• The Master Client controls spawning; other clients receive synchronized instantiation events.

• Prefabs are registered with the pool automatically via:

  PUNPrefabRegistrar.RegisterFromScene(provider);

In both cases, pooling ensures that repeated spawns don’t cause bandwidth or allocation spikes.

---

4. Lifecycle Integration

When you pause or end a mission:

Spawner Lifecycle	Pool Behavior
Init()	Prewarm or allocate initial pools
Pause()	Suspends active spawn loops
Resume()	Continues deferred spawn processing
End()	Returns all active objects to the pool

This automatic cleanup prevents leaks or lingering objects after transitions.

---

5. Diagnostics

You can monitor pool activity via the Spawner Diagnostics HUD or the Object Pool Inspector.

Typical runtime output:

[PoolAdapter] Prewarmed 10x Enemy_Grunt (total=25)
[RuntimeSpawner] Returned Enemy_Grunt to pool (active=8)

---

Next Steps

• Custom Pooling Systems — how to implement your own provider or adapter.