Sprocket Tools – Memory Pooling Quick Start Guide

Hello and welcome to this short introduction to our memory pooling package. We have a sample scene set up to walk you through using GameObject pooling. It contains a cube fountain, that spawns cubes and throws them every which direction. The completed scene is included in the Asset Store package, and we encourage you to check it out. To start, we are going to import the Unity package and set it up. Notice the automatically created Singleton[KDispatcher] object in the scene. We are going to move the folders ‘Editor Default Resources’ and ‘Gizmos’ out to the Assets root. To ensure consistency, we are going to also save the scene and do a ‘Reimport all’. Next, we are going to add the KPoolableGameObject component to the Cube object.

Notice the warning in the inspector prompting us to move the prefab. For a closer look at things, we’re going to open the GameObject Pool Manager window. As we switch to Play Mode, a pool of cubes is created using default values, but the cubes are still using Instantiate. Time to set up the code. Using the included code snippet we are going to create a boolean configurable setting to toggle the use of GameObject pooling. Note the ample comments dropped in. They outline steps that need to be completed for the setting to be functional, some alternative use patterns and a couple of cautions.

Once we’ve run through the ‘to do’ checklist, we can get rid of them. Now, based on the setting we created, we need to grab an object from the pool. This only takes one line of code. Recovering the object back into the pool also only takes one line of code. Making our behaviour inherit from KPoolableMonoBehaviour allows us to define initialization and reset methods that are automatically invoked by the GameObject Pool Manager. Initialize will be called only once, when the object is initially created, whereas Reset will be called everytime the object is requested from the pool. With the code in place, let’s open up the Config Editor and enable GameObject pooling via the setting we created. Switching to play mode again, we can see the objects marked as ‘Pooled’ instead of ‘Clone’.

Also note the (E). This means the pool was initially too small and needed to expand to cope with the number of objects we requested. Note the KGameObjectPool in the scene hierarchy. This is a container for unused pooled objects. We can use the setting to enable or disable pooling at runtime. Stopping Play Mode, the scene hierarchy is cleaned up. Switching to the GameObject Pool Manager window we can see the learned data has changed. This new value will be used as the initial size for the pool on subsequent runs of this scene.

Now let’s see what happens if we forget to recover some objects. We need to set logging to be more verbose, and make sure debugging and logging are enabled. With that done, when stopping play mode any unrecovered objects will be logged, listing the type and method that requested the object and forgot to return it. Our tools keep their own logs under Unity’s Persistent Data Path in the folder ‘kxlogs’. As we improve the package we hope to add more precise debug data. Let’s see what happens if we try to Instantiate an object that’s not in the right location. The Pool Manager will try a few alternatives and warn if it comes up empty. The inspector notices the faulty location and offers to move the prefab. Now, let’s try instantiating an object that is lacking the poolable component. The Pool Manager will warn of the issue and resort to using GameObject.Instantiate to supply the object. When trying to recover one of these objects, there will be another warning and GameObject.Destroy will be called.

That wraps up the basic functionality when dealing with GameObject pools. We encourage you to check out the sample scene and the documentation. Thank you for your time, and have a great day!.

As found on Youtube