0
\$\begingroup\$

The mobile game I am developing consists of one to four players and different agents that are being spawned and act in their own way. All those Agents (Car, Animal and Powerup) derive from the same base class 'Agent' which in turn has a field called 'rank' which represents something like 'low', 'medium' and 'high'. So an agent with rank 'high' will look and behave different than one being tagged 'low'.

The thing is - the 'rank' of the agent is determined at random. The max count of agents active simultaneously is known but this number is not in regard to their 'rank'. When objectpooling, this would lead to the follwing case:

There's a max agent count of, say, 6. This would require 6 instances of each agent with rank 'low' to 'high' to be created, altough some of those instances would never even be used.

So my idea was to create only 6 gameobjects holding the components that each agent requires and use reflection to set the components fields according to the type. The problem is that some compoents which are unique to rank and type would need to be added and removed at runtime.

What solution would be better in terms of runtime and memory performance?

\$\endgroup\$
1
\$\begingroup\$

Object pools should be used when you constantly create and destroy a large number of very similar objects. When retrieving and reinitializing an object from the pool requires some costly operations, like adding and removing components and performing reflection calls, then you are defeating the whole purpose of object pools.

So if you have 3 different types of objects you want to pool, then create a separate object pool for each type of agent.

A compromise would be to work with one pool, but to add the whole set of components to each agent. Instead of destroying and adding the components, you just enable and disable them. Performance-wise, enabling and disabling is far cheaper than adding or removing.

However, reading between the lines of your question, i get a bit sceptical if object pools are actually useful to you in the first place. You say you only have 6 simultaneous objects in the game. How many of these objects get destroyed and reinitialized per second? Object pooling is useful when you have a large number of short-lived game objects (like bullets in a shoot-em-up, for example). When you have few game objects and they usually live for several seconds, then object pooling is unlikely to really do much for you.

\$\endgroup\$
  • \$\begingroup\$ 6 was an arbitrary number I pulled out of thin air. The game may have 20, 30 or more objects active at the same time. When creating a seperate pool for each of those objects, I would have 30 ore more instances for each type and as I just said a lot of those instances would not even be used. This ends up requiring a lot more memory than necessary. \$\endgroup\$ – Roman Stadlhuber Nov 10 '18 at 11:00
  • \$\begingroup\$ @RomanStadlhuber Object pooling is always a tradeoff of memory for performance. That's their purpose. The question is, is it a good trade in your particular circumstances. This depends on how much memory each game object in the pool actually consumes (did you check?) and how often you are using the pool. \$\endgroup\$ – Philipp Nov 10 '18 at 11:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.