Copy gameobject approach - could this work?

I have a generic object pool I made I’ve used a few times now. It’s just a fifo stack. It also does one neat thing, it self-populates by instantiating a provided object periodically but also immediately does so if it has fallen behind requests for them, while also preventing you from overpopulating the stack.

Anyways I digress:

I’m making a RandomFood prefab- when instantiated it’s active and randomizes itself to match some other provided FoodPrefab then disables/destroys itself. It’s practically speaking just a constructor.

This might seem counter-intuitive but it does localize designing the FoodPrefab(s) and also encapsulates the randomization separately from both the pool and any other script. Later if I want to tailor that behavior for any reason it’ll be clean.

I looked into copying prefabs over each other:

  • Reference component instance
  • Add referenced component types
  • Copy referenced component parameters

That I can do no problem.

If I was to instantiate a prefab, then attach it as a child, obviously this would result in the desired outcome - just with an extra transform (which is unacceptable without a reason for it) - I’m wondering if there’s any way I could merge those objects or otherwise “collapse” upwards onto an empty GO?

Or otherwise outright replace the GO a Mono-behavior is on with a different one by-reference?

Oh see this is dumb:

As soon as the pool instantiates it, RandomFood just references the pool (which is a member of a singleton class), pops itself out, and pushes a random prefab in.

Which sounds awful, but i’m using Awake correctly, so it shouuuuld be safe as long as all of that happens in Awake, and nobody is popping during Awake, which nobody will be.

I knew I was gonna be putting particle systems on these guys and didn’t want to mess with copying the params from those.

Or I could do what’s proper and extend my object stack to accept arrays of objects, but that’s no fun. (cough)

I don’t get it. Why are you instantiating and destroying objects for a pool. That kind of defeats the whole point of it.

Normally you would throw the randomising code in OnEnable of the object being pooled. That way you will get a properly randomised object each time.

You’re right to be confused, I would need to specifically design a game around it lol - or it may save some game design I didn’t plan well.

To be frank it’s more academic than anything. I learned what IEnumerator really is, used it myself with MoveNext(), and I think I better understand Coroutines as well because of it. It’s also my first class to use Generics- (it accepts any Object); and probably my first fully-reusable class.

I think I actually programmed this one in January. So you get it out, and as a noob, just using it is a solid review.

It gives you one advantage. You can create new pools while the player is playing. If something slams the pool for objects before it has a chance to populate them, it will Instantiate() on demand, with no limit, and tank your framerate. So you instantiate this guy and give him (object, size) and then you can immediately call Stack.Pop() as if it were Instantiate.

I like spewing things? So like maybe a new enemy comes in and you didn’t have a direct part in that or a plan for it, it’s just something the game might do, and you can instantiate him something to spew egregiously at that time… I’m really big on emergent systems so it was just a topic that interested me a lot.

That’s what it needs, a randomization function + constructor overload would be within SRP for a pool of things I suppose, but for sure I am gonna give it an “immediate” overload if/when the way it works causes problems.