Let’s define some simple naming conventions we will use later on. Object pool collection is represented by group of object pools storing instances of similar object type and we will mark it shortly as a “collection“. Collection can contain object pools (just “pools“ for simplicity) containing only instances of type derived from collection’s object type. Every poolable object instance stored in pool will be named as an “instance“.The object requesting instances from the collection will be marked as a “consumer“.
The main reason we decided to use such a design approach was our need of possibility to change the visual representation of objects at runtime. For example in our game Clumzee: Endless Climb the player can choose from various worlds. Each world consists of objects with exactly same behaviour, but the visual representation of objects is always different. Thus we have designed our collections to handle access to required collections at runtime according to the world player has chosen to play.
Each consumer needs references to certain amount of pools with instances of similiar object types. Thus collection represents some sort of mediator between consumer and pools. Every collection can store references only to pools with instances defined by object type derived from the base type.
In the next sections of the article we will describe two types of collections we were using by now. The first one is just simple collection which can be activated / deactivated in respect of the game requirements. For example, there are different visual interpretations of the same object types used in different environments and you need to effectively switch between particular collections to ensure that each environment will be build with correct instances.
The second type is so called “ranked collection“. This collection type allows us to effectively handle a dynamic difficulty of the game. It contains pools with different instance settings, visual styles etc.. These pools may be activated / deactived according to predefined rules and / or conditions.
If there is a lot of collections and consumers this concept can be extended with some sort of collection manager. Consumers will not have direct access to particular collections, instead they will send requests to the collection manager.
Simple Object Pool Collection
Main aim of the simple collection is to provide access to objects of particular pools. Collection can contain defined amount of pool references which can be also added / removed at runtime. The overview of simple collection parts is presented by Fig. 1. Each pool of subtype x (where x = 1, 2, … , n) is implemented via description in the previous article Object Pooling in Unity.