Tutorial Tuesdays! – Object Pooling.

Object Pooling. In some ways, game development is a puppet show. You parade your characters across the stage, they hop about, and you swap them out for others. Obviously, unused puppets aren’t scrapped, they get reused. And you wouldn’t stitch together an entirely new puppet each time it needed to reappear, would you? Of course not. It’s too expensive.

Yet often, when new ‘devs need a GameObject, they’ll instantiate it from scratch and think nothing of destroying it when it is no longer needed. After all, a GameObject’s materials are ethereal, and the machine is doing all the work. But a GameObject’s creation and destruction is still expensive.

In the old days, when data was created, a programmer had to manually assign where in the memory it went. Thankfully, Unity handles memory allocation automatically. But it still has to contend with limited amounts of memory. So it continually searches through the heap to find and free up unused memory in a process known as Garbage Collection (GC). This process requires significant work by the CPU; it’s expensive.

Since Garbage Collection is all about finding and freeing up unused memory, the work done by the CPU is exasperated with every GameObject instantiation and every GameObject destruction. The CPU has to figure out what still exists and what has been deleted, what can be reallocated, and what is still needed. It’s far better for the Garbage Collector, and system performance, if GameObjects in particular occupy a space in the memory heap and then just stay there.

Enter Object Pooling. Object Pooling, like Static Batching, is an optimization process that even the most novice of developers should know about and implement. In this strategy, instead of instantiating and deleting GameObjects, GameObjects are re-used. Instead of being destroyed, GameObjects are deactivated. Instead of being created, they are activated. As a result the GO never moves from the memory heap and the GC never has to bother with it. The end result is improved system performance.

A rudimentary Object Pooling pattern is not especially difficult to script. It can be tricky to implement in Playmaker, however, because many of the native Actions don’t anticipate the need. Get Random GameObject, for instance, does not work on deactivated GameObjects. Instead, Playmaker-centric developers rely on fourth-party middleware Object Pooling assets that have Playmaker functionality. Some are paid and some are free (we’ll look at a free option on Freebie Friday!).

In summary, creating and Deleting GameObjects is expensive. It creates more work for the Garbage Collector thereby undermining system performance. It’s far better to reuse GameObjects by activating and deactivating them. This process is known as Object Pooling, and using Unity and Playmaker, is simplified with fourth-party made middleware. Even novice developers should use Object Pooling to optimize their games.

Leave Comment

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