• entries
19
41
• views
22563

# The GameObject Pooler

1227 views

So another fellow was doing a journal and was a little nervous about posting code for review. It got me thinking that I should post some code up as well. (I do have a game update that I could do as well, but I'll save that for later)

When I first read your code, I thought you should make your class a Generic, something like:

// I just typed this, I didn't run it through a compiler.
// I leave getting this working as an exercise to the reader...
GameObjectPooler <GeameObjectType> : MonoBehaviour where GameObjectType : MonoBehaviour
{
List<GameObjectType> pooledObjects;

{

}
// etc. etc.
}

Then you'd have strongly typed values stored and wouldn't have to cast them to their real types. But after thinking about it, I don't know which is better for you.

I'm also not sure you want your Pooler to inherit from MonoBehaviour (or if Unity supports generic MonoBehaviour scripts). Instead the pooler could be a regular class that's contained by a different component.

Thanks for the feedback!  I could implement a generic method for the GetObject<GameObjectType> for those instances where I want to return the specific type.  That might be an easy win as far as modifications go, though I could see other games where having separate pool management might be the better way to go.

Good point on the possible removal as a monobehaviour.  I could easily stick this in my GameManager class and get rid of one behavior. If I was going for separate pool managers per object spawner, that would make even more sense.  (LaserRifle could own the pool of laserbeams)  Though I do lose being able to access the pooler directly from the Editor, but I could expose that functionality in the class that holds the pool.

(Though thinking on it, a static pool for a class like LaserRifle could be the way to go, probably depends on the game.  Might be a bit more of a nightmare if Unity was multi-threaded, but it's not, so don't have to worry about it)

Honestly, if I was going for more sustainable/reusable code without singletons, I probably should go with a pool<t> for each thing that spawns.  It would be a bit more work to do the PoolAll(), but not a huge amount.  And that is functionality that most other game types probably wouldn't need.

My tank tactics game, funnily enough, I didn't need an object pooler, at least yet.  Tanks only shoot one shell at a time =)

And thanks again for the feedback, as you can see, it got me thinking, which is always good.

Food for thought, yeah. I don't use Unity but it's interesting to see how you're grappling with static vs dynamic types & pooling. These same issues come up everywhere.

Yup, everywhere.  Random anecdote:  Back when I was working on a PS2 game, we had very strict memory budgets for each level.  I think it was something like 7MB.  Then about halfway through development the programmers bumped it to 9MB.  Why?   Well someone had declared a static 2MB buffer that no one was actually using.