Game Object stacks

Hello fellow unity devs !

So I'm currently creating an IOS game using Unity. To keep the ressources allowed to creation/destruction of object as low as possible, I'm actually creating a stack handler that will keep instances of my object instead of destroying them for future usage.

At this point my question is, what should be the right size of my stacks ? How many objects of this kind can I safely keep in memory without actually affecting my game performances due to a large amount of objects stored ? As I display a lot of little effects at the same time on the screen, I'm currently keeping stacks of 50 objects of the same kind, so that would be something like 30-40 dictionnary, each one storing up to 50 objects for future use, is that too much for an Ipad ? Does this affect the number of polygon I'll be able to display to keep things smooth ?

Ps: I'm turning active to false, I read somewhere that it desable the object from rendering / receiving events and doing updates, but I don't know exactly what is the amount of memory that object still takes.


Regards

 

the term you are looking for is an "object pool", not stack. An object which is set to "setactive=false" is still in memory. "how many" is going to depend on what your objects are, and what the rest of the load, and whatever else...

 

Ha thanks for the right term "Object pool" I'll be able to dig a bit more on web for it.

I understand that an object "setactive=false" is still in memory, what is the best way for me to estimate the memory amount taken by each object instance I'm keeping in pool ?

Thanks.

 

Pooling is what this is called. The basic idea is to keep existing objects so that you don't have to create/destroy them repeatedly which is more expensive. Typically the pool for each GameObject should only be as big as necessary. You can either assume it beforehand by guessing how many possible instances of that GameObject could exist at any given time, this is entirely possible for some things but not for others... Otherwise you can check the pool to see if any disabled instances are available and either create (and add to the pool) or enable one. This scales up to the max number naturally and your pool will be efficient once you create enough of the items.

Most of the time you can have fairly large pools and just pre-fill them during loading time unless you have a more complex game with lots of different items. Its always good design to have the safety net of checking the pool and creating if necessary so you don't run into an issue where the pool is empty and you have no solution in such a case.

 

Hello LaneFox,

As far as I found there seems to be two different approach like you said. 1 Create a static number of instance in pool, 2 Create a pool that can be filled on needs without a real limit.

My current system is a bit of the two worlds, starting with an empty pool, that is filled up to a maximum number of instances. This mean I do not create any instances during loading time, instead I create objects when necessary and store then into the pool if there is still space available, if no space is available I destroy them.

Is that a good approach also, or should I really create a set of instance at loading time to get things efficient ?

I'm also wondering if I could add a system that would clean up the pool based on the amount of object really used. Let's say for some reason there is a spike of use and my pool sudently grow up to 100 instances, but my game usually need only 60 instances, after a time I would clean thoses 40 unecessary instances from the pool. But that mean the garbage collector will be called from time to time. I guess it's not a big deal as far it is not called permanently ?

 

That really depends on where your optimization needs are: Memory or CPU. If you have plenty of space left in memory just load up the pool and forget about it but if you don't then you have to fallback on the CPU with a smaller pool and more create/destroy.

You should profile it on the device to see where it stands.

 

@Willy The Kid

If you need a pool that manages itself and grows, it would be a good idea to create a custom class for that:

Use a GetOrCreateObject method and a ReleaseObject method.

List<T> ActiveObjects
List<T> FreeObjects

The GetOrCreateObject method should check the FreeObjects and then move it over to the ActiveObjects.
The ReleaseObject can do the opposite.

In most cases that is all that is needed.

However, if you do need to Destroy objects because of unusual spikes, you can also do the below:

In the release object method, you could keep track of the time when the free object limit is reached and then after so many seconds later in another release call, if it still has a large number of inactive objects, Destroy the FreeObjects over the limit.