Design Patterns: Object Pooling

Image result for Golf Story

Today’s image is from Golf Story, a Nintendo Switch Game that reminds me a lot of Mario Tennis, one of my favourite GBC games.

This article is going to talk about Object Pooling.  The idea behind Object Pooling is to improve Memory usage by reusing object from a “pool” of a fixed size instead of allocating and freeing them individually. I am going to put this in Unity terms as it is what I do professionally every day and the best way I can explain it.

In Unity you have Instantiate and Destroy methods that are used to Create and Destroy objects. For objects that have quite a long lifespan, these methods don’t cause a massive CPU overhead or at least don’t really interrupt the experience (there are of course various scenarios where this case be the case, but for this example let’s go with this). For objects with a short lifespan, this can cause issues. If you have a lot of objects that are created and destroyed per second then

You're going to have a bad time

The CPU needs to allocate more time to dealing with this creation and destruction. With Unity and also managed languages in general like C#, there is also the magic of Garbage Collection, i.e. a system that deallocates memory that is no longer in use. Depending on what you are working in, Garbage Collection can happen without you really knowing and also in ways under the hood you don’t expect. If you are calling Destroy a lot in Unity you are going to trigger the garbage collector. And triggering the garbage collector likes to slow down CPUs and can cause noticeable slowdowns in gameplay.

Object Pooling can be a way around this. The idea is to create all the objects you’ll need before the gameplay. Instead of actively creating new ones and destroying old ones, the objects get reused from a pool.

To put it another way, you are creating a pool that has a collection of reusable objects inside of it. Instead of creating and destroying these, the objects have a state of whether the game is actively using them or not. Before your gameplay you initialize the pool which creates all the objects you will need up front and sets them to the not being used state. When you need a new object, you ask the pool for one. It finds an available object that is not currently in use and returns it. When the game is finished with the object it is freed up again. Objects can be used without having to create and destroy them all the time.

There is a caveat to this though. You are essentially deciding how many you need of a certain amount of object before you run the game. You could get into one of two scenarios. You may have a smaller pool of objects that save on memory however when you get to your gameplay, you find you have too many. On the other hand, you may assign the number for the pool to create to be more than you will ever need, using more memory.

There is a way to get around this. You can make an object pool that expands if it runs out of objects. If you reach the maximum amount of objects in the pool, the pooling system can create one and add it to the current pool. Although there will be a very small overhead of creating the object, it is better than creating and destroying these object all the time like a maverick.

The thing we haven’t addressed though is when we should use them. Well, object pools are designed for when you need to frequently create and destroy objects that are of a similar size (ideally identical). If you look at a bullet hell game, you don’t want to be creating and destroying all those bullets all the time as it will most likely kill your performance. Similarly with particle systems. That continuous smoke cloud coming out of your Volcano will want to use pooling.

Essentially, that is a brief overview of Object Pooling. If you are creating and destroying lots of similar objects in your game, then Object Pooling is for you!


Leave a Reply

Your email address will not be published. Required fields are marked *

Verify that you are not a robot! (If you are unlucky) *