- Home /
Pooling everything...or not?
I've got a mobile game that I'm building a pool of all game objects to be used when the game is loaded (currently 147 different objects). The objects are all set to be persistent. Before I just built the pool at the start of the level (so less objects were created, then stored, and finally destroyed each level). I'm wondering if anyone sees any potential problems with this approach or has tried something similar.
I'd do that only if my framerate was lagging (because I don't like experimenting with things if I don't absolutely have to, it's just me) and if I needed to save cpu power, but other than that, nah. Though it's a good experience.
I think I'll take your advice. It quickly becomes a pain trying to manage persistent objects that have differing tasks per level.
Answer by Kiwasi · Nov 30, 2014 at 12:13 AM
Pooling really depends. The advantages of pooling are
You only load once
You avoid unpredictable garbage collection
Disadvantages
A little more code to set up
Unused objects remain in memory. This can cause problems on memory limited platforms. Especially if there are large spikes in the number of pooled objects
Ultimately pooling should be used when you have a large number of identical objects being frequently instantiated and destroyed. Bullets are a classic example. Obstacles in a infinite runner and enimies in a space shooter are other good candidates.
You shouldn't use pooling for unique objects, or objects that are never destroyed. Players in a FPS or unique boss monsters are good examples.
Your answer
Follow this Question
Related Questions
How do you use a pool of objects rather than creating and destroying repeatedly? 8 Answers
Pooling object performs the same or worse than instantiate/destroy? 1 Answer
Instantiate and Destroy optimization 1 Answer
Destroy A Certain Instantiate On Tap Help? 1 Answer
Firing only a single projectile at a time, then adding a second. 2 Answers