Optimizing with Pools
Garbage collection in our everyday lives is generally the same as garbage collection in your program. You purchase an item from the store and make room for it in your home (instantiate a new game object and allocate space in memory), get use from that item (game object, do this thing), toss out or recycle that item once you’ve used it all or it breaks (sorry game object, you’ve been destroyed), and, finally, your trash is automatically taken away by the indispensable neighborhood waste collector, clearing room for your next purchase (the memory allocated to that game object is released by the garbage collector, and room is made on the heap for more game objects). Unfortunately, each time you instantiate and destroy a game object in your scene, garbage is created that must be managed. However, one way to better optimize and design your program is by working to avoid that garbage collection altogether through object pooling and recycling.
The object pooling design pattern is the process of pre-instantiating a set amount of repetitive game objects that you may need during runtime, and then organizing those objects into pools which can be pulled from at any time. A common example of this is with bullets where those game objects are constantly being fired. If you were to instantiate each bullet when it was fired, not only would CPU performance suffer from having to rapidly create that game object, but once it was destroyed, garbage collection would be required to free up that memory. Instead, with object pooling, a set amount of bullet objects are created prior to any gameplay, and then simply activated or deactivated from the pool as needed via GameObject.SetActive(true) or GameObject.SetActive(false), respectively. If any additional bullets are required outside the scope of what was initially instantiated, then you can create logic which would instantiate however many objects you need and then add them to that initial pool for future use.
I’m currently working to enhance this design pattern with my project for GameDevHQ’s intensive program, and although I’m constantly mulling over its organization, I now have three pools configured for enemies, turrets, and decoy turrets. Each pool is set up as a scriptable object with a name, index, buffer, and list of available game object prefabs for that specific pool. Each pool is also contained within a PoolManager singleton which is attached to a game object in the scene. Using some type of index and buffer is important here because that maintains a global ID (index) for each particular pool as well as an amount of each type of game object within it to keep ready (buffer). The PoolManager also stores a list of each pool’s respective pool container because above all else, gotta keep that Hierarchy clean!
As previously mentioned, having the program organized in this way allows for simple SetActive() calls to be made against objects already stored in a pool instead of having to allocate CPU power to their creation and destruction at runtime. Once deactivated, either by “destroying” them or having them reach their target, enemies merely go back to waiting in their pool until they’re forced to suffer the wrath of my turrets again, allowing my program to skip out on having to collect their garbage!
I’m sure we’ve all experienced annoying performance issues causing us to curse devs so just try to be mindful of what actions your program will be performing, what platform you’re program is being developed for, and what potential platform(s) you may want to expand into. Small optimizations here and there can really add up, and some may be drastically more impactful than others.
Cheers!
