Discussion Best place for an object pool?

What is the best location for an object pool? I see several options (Im just starting with Unity, I come from a web/business background):

1) Store the pooled objects in a static field (a list) of some class.
2) Store the pooled objects in an object for which there is only one instance (singleton pattern)
3) Create a game object with a script that holds the pooled objects in an instance field and add references to said object in the scripts that need the pool

As far as I can see option 3 would make sense if my objects will be used only in one scene. Options 1 or 2 would work best in other cases. Any thoughts?

 

In the trash can.

The costs and issues associated with object pooling / pools:

https://forum.unity.com/threads/object-pooling.1329729/#post-8405055

https://forum.unity.com/threads/object-pooling-in-a-tower-defense-game.1076897/#post-6945089

If you insist on thundering ahead with it, it doesn't really matter where it lives. The entire point of a pool is to be as transparent as possible to the client app. Think of it like the wiring in your house. You don't really care where the main drop comes in as long as all the lights and outlets work.

 

If you'll be using it to create instances based off of prefabs, then a scriptable object asset could be a convenient option. It would make it trivial to drag-and-drop prefabs into its serialized fields, and then the scriptable object asset could be dragged into any scene objects, prefabs or other scriptable objects that need it.


If you don't need the inspector for configuring the object pool, then I would use a plain old C# object. This can be used to achieve best encapsulation, and hide the object pool as just an implementation detail of some other class that is responsible for object creation (e.g. EntityManager creating entities, Gun creating bullets, Tilemap creating tiles etc.).

As an additional bonus, you could make the object pool generic with this approach, which wouldn't be possible if the pool was a scriptable object or a component.

Code (CSharp):

1. public sealed class EntityManager
2. {
3.     private readonly ObjectPool<Entity> objectPool;
4.  
5.     public EntityManager() => objectPool = BuildObjectPool();
6.  
7.     public Entity Create(EntityId entityId) => objectPool.Get(entityId);
8. }

 

Personally I use a static List of the classes, as if using gameObjects you'd have to get the class all over again anyway. So two birds one stone, and what not.

 

I read both threads, you make some very good points. I had given some thought to the complexity of managing object state when activating/deactivating and what would happen if forget which objects are supposed to be pooled an which are supposed to be created and destroyed. My take would be: dont use pools unless you actually have to.

 

I didn't know a bout scriptable objects! They look super useful. Love it when you ask about X and end up learning about Y... Thanks!