Code Mules

We want to talk about our approach/philosophy for Object Pooling. It is the underpinning of our feature requirements, as well as the template for our design and implementation.

We want a design that is simple, highly effective, extensible, and versatile

We want a design that works really well for .NET objects (POCOs)

We want a design that extends to work well for Unity Game Objects

We want a low-latency mechanism that enables concurrency for .NET objects

Simple

The code doesn't need to be overly complicated or contain extraneous features that are not part of our core requirements. Anything difficult to understand should be re-factored, and anything tricky should be re-thought. The less moving parts, the more efficient and higher quality the components will be. Most importantly, the usage model should be simple and easy. It needs to be easy for other developers to setup, manage, and use object pooling correctly and effectively.

Highly Effective

The components need to meet the objective, and because we will be changing other components and system to leverage the object pooling components it needs to add clear value thru increased efficiency and performance.

Extensible

Although we want the core to be simple, we may need to ability to specialize for  some use-cases and, we want to maximize our ability to build the Unity Game Object pooling on top of the POCO pooling. In addition, we may want to add a variety of more advanced features as add-ons, rather than via derived classes, so we need to provide opportunities for future code to make observations of pool operations. Getting this correct can be tricky as we can’t know all the possible things we might want to do in the future, but at the same time we need to resist the urge to increase the complexity of the components in anticipation of a future feature that may never happen.

Versatile

The components need to be effective and adaptable to a large number of use cases. We do not want to be limited/constrained to only a few ways of using the  components. As an example, we want to avoid having our object pool be a singleton as this pattern results in an extremely limiting usage model. As another example, we do not want to be restricted to having a single object pool for the same type. For example, we might want two or more pools for StringBuilder instances where we group instances by capacity.

POCOs and Concurrency

Unity generally only allows access to Unity game objects and components on the main thread, so there is little or no need for concurrency for object pooling of game objects. However, with every release the Unity team works to increase the overall parallelization and distribution of work across all available cores. This means that in the future the we will be able to run more of our code off the main thread and that will require us to write code that can manage concurrency. In addition, we already use a lot of background threads for processing network requests, large data sets, etc. It would be nice if we could have a simple mechanism that gave us concurrency without the overhead of acquiring and releasing locks. Strictly speaking, concurrency is not required because our object pooling for Unity game objects does not require it, but it would be really, really nice to have.

Unity Object Pooling

The first step beyond identifying the need for new functionality is conceptualization of the functionality and how it will intersect with your existing system. This conceptualization is generally just identifying what you want, what you expect it to do, and how you expect it to help you achieve a specific goal.

Once we have identified the need for a feature and we determine that the scope of the feature exceeds a certain threshold we start looking for how other people have solved the same or similar problem. In the process we may find a great solution we can use directly. This can save a lot of time and cost. This doesn't happen very often but it is really nice when it does. More often, reviewing features and implementations from other authors helps us fine tune our feature requirements, and more importantly, allows us to clearly identify things that we don’t  like and want to avoid in our design/implementation.

Object Pooling is no exception; there is a lot of prior art. Both Github and the Unity Asset Store are littered with projects that provide some form of object pooling. In addition, there are a number of blog posts related to the subject, most of which include code. There are packages on the asset store that cost enough $$$ that we didn't bother to check them out even though the feature sets seemed reasonably robust. As is to be expected we didn't find a lot of things we liked, but we did find a few things we didn't hate. 

Anytime we are writing production worthy code an emphasis should be placed on efficiency and performance. This is especially true when developing games with Unity. With games, memory footprint and/or performance issues are often exaggerated and lead to degradation of the overall user experience. Object Pooling is a form of reuse/recycling of resources which allows for better efficiency and performance by reducing the number of resource allocations/deallocations, and as a result, the amount of memory used and the amount of garbage collection performed by the system. By making more efficient use of resources you can do more with less, allowing you to take your game experience to the next level.