Pooling#

PoolManager reuses game objects instead of destroying and recreating them. It provides the runtime behavior behind Instantiate from Pool and exposes the same pool directly to C#.

Getting an object#

This call creates a prefab pool on first use, then returns an instance for 0.2 seconds:

GameObject instance = PoolManager.Pick(
    prefab,
    position,
    rotation,
    count: 8,
    duration: 0.2f,
    TimeMode.GameTime
);

Pick activates and returns one pooled instance at the requested position and rotation.

Parameter	Is
`prefab`	The prefab to pool. Each gets its own pool.
`position` / `rotation`	Where to place the instance.
`count`	How many to prepare when the pool is first created.
`duration`	Seconds before it returns automatically. Zero or negative means manual.
`timeMode`	Whether that duration follows game time or real time.

The pool is created on first use, so there's no setup step. Simpler overloads omit the position and duration.

PoolManager.GetLastPicked(prefab) returns the most recent instance handed out for a prefab. Use it when the next operation targets the newly spawned object.

The duration#

A positive duration returns the object automatically, so you don't need to track that instance for a later return.

For objects with no fixed lifetime, such as a projectile returning on impact, use a duration of 0 and return them explicitly.

Pooled objects are reused#

State persists between uses

A pooled object is disabled and re-enabled, so it retains its state between uses. This includes modified variables, changed materials, animator state, active particle systems, and rigidbody velocity.

Reset any state that shouldn't carry over to the next use.

Reset reusable state in OnEnable, which fires whenever the object leaves the pool:

private void OnEnable()
{
    this.m_Health = this.m_MaxHealth;
    this.m_Renderer.material.color = this.m_DefaultColor;
}

Each activation restores m_Health and the renderer's color before the object is reused. For designer-facing objects, an On Enable Trigger can perform the same reset.

Sizing the pool#

The count is how many instances are prepared up front.

A pool that's too small grows during gameplay, moving allocation into a busy moment.
A pool that's too large holds memory for instances that never run.

Estimate the peak number alive simultaneously. A weapon firing ten times a second with a half-second effect peaks around five; eight gives headroom.

What to pool#

Repeatedly spawned objects benefit from pooling, while objects created once usually don't need it:

Pool when	Instantiate when
Projectiles and effects	The player
Damage numbers, floating text	Level geometry
Decals and footsteps	Objects created once
Wave-spawned enemies	Unique story objects

Pool objects created several times per second. For an object created once per session, pooling adds lifecycle and reset logic without avoiding repeated creation.

Pooled runners#

Separately from game object pooling, RunnerInstructions and RunnerConditions can pool their execution instances. See Events and Runners.

Where to go next#

Pooling — inspect the designer-facing lifecycle and capacity choices.
Events and Runners — pool Instruction execution separately from game objects.
Components — reuse cached component lookups on pooled instances.