Unity Prefab Pooling memory optimization

Unity Engine
1

Hi guys!

I’ve been working on a Unity game on the iOS that I need to introduce some new elements to. We use the pooling technique to improve the speed at which objects are created and destroyed by not having to call instantiate, but instead simply pulling from and pushing the GameObjects back into a pool. However, this has memory ramifications that mobile games must watch, though we’ve managed to toe the line so far.

However, new design requirements have come up that threaten to overtop our memory limits. The game’s GameObjects are managed via prefabs, as you may expect, and the pool manager instantiates a certain number of the prefab on load. Say…
20 of Enemy A prefab
20 of Enemy B prefab
20 of Enemy C prefab
100 of Projectile prefab

However, the new design wants to introduce the concept of different kinds of projectiles and enemies, which, if we stick to the current method, doubles or triples the pool’s memory footprint, which is unacceptable.

The regular way to tackle this issue in a from-scratch game is simply to have a base Projectile class that gets customised to different kinds when created from the pool. One simple saves the customised behaviour and variables either in crude spaghetti switch codes or scripts or xml or what-have-you, and it switches on runtime based on, say, a single “ProjectileType” variable, so the pool memory footprint remains the same even if there are 200 different kinds of projectiles.

My question is how do you replicate this technique in Unity with prefabs while still maintaining the ease for the designer tweaking the prefabs within the inspector? I could have a Projectile prefab that I change values and textures on runtime, but that seems to defeat the purpose of prefabs in the first place.

Apologies for the long post, I wanted to get the details of the question down right. Thank you!

2

prefabs are just saved collections of components… an empty game object with a script attached to it which setups up the rest of the components based on a “type” selector in the inspector is still a prefab.

3

Like I said, if the prefab starts out as an empty game object that I then set up the components one by one, it’ll firstly defeat the purpose of prefabs (which is to have all these components set up so they can be readily duplicated), and it’ll compromise the speed of the pool, since each component need to be created and initialised on run-time instead of load time.

4

Using a single generic entity can work with a configuration library, which would be one object, prefab, or asset that contains a list of all possible configurations. Pick one and use it to configure each object when it is taken out of the pool. This won’t work if you have to add or remove components, as that defeats the optimization of pools. It is quite limited and tough make a nice workflow out of. In general I would avoid this approach.

Is pool memory really a problem here? A few hundred extra instances shouldn’t take much space, unless they’re very large for some weird reason. And do you really need 20 enemies of a single type? Won’t 1 or 2 suffice, combined with lazy loading when you need more? Make sure this is really something you should spend time on.