Hi guys;
Im creating infinite obstacles for an infinite level but i want to destroy objects that i created with same creation speed. How can i do that can you help me?
I’ve read some topics about Creating/Destroying/Pooling and everybody talk differently and i dont know what to do in this situation?
Should i destroy the objects i’ve created?(i dont know how to do)
Should i let go the infinite instantiate and dont destroy anything?
THANKS!!
Infinite obstacles on an infinite level is certainly a job for a pool of objects. It could just be a risk without a pool. Though it can be achieved you would need to be precise and accurate and it would have to not be your first time attempting it.
so in a pool you perhaps instantiate your max gameobjects on start and place them under a transform parent in the hierarchy setting them inactive.
When you come to spawn these objects, you run through the child count of their parent transform, set them active if they are inactive and teleport them to location.
if the level is back traceable- then a pool is not as useful as instantiating the object. If it is type of infinite runner, in a single direction; then pool is the way to go. As you merely depict the illusion that the world is filled. Yet if you needed the world to be actually populated and revisit-able, then a pool would be substantially more complex.
Destroying is okay but depending how many things are happening in your game, impact of destroying may become noticeable. But you can limit the destroy rate of objects to a controllable and manageable interval.
Game is playing one way, something like ‘‘flappy bird’’ and instantiation happens with timer, there are no big things happening; some power-ups and animations on instantiating objects for now.
So what kind of way should i follow? Thank you for explaining all that stuff it will be helpfull for sure but i still dont know what to do:)
I don’t think you need anything but the basic
Destroy(object, timeToDelayBeforeDestroyingTheObject);
The main concern when destroying large (or frequent) amounts of objects is garbage collection. This is an automatic process which collects dead references from memory, basically a cleanup. In some programming languages you got to do this yourself, which both gives you more control… but also makes it easy to miss something and introduce memory leaks.
Garbage collection obviously, as anything else, takes time. Usually this happens between two frames, so it can introduce quite a noticable spike in frametimes, if a lot of cleanup has to happen at once.
However, object pooling and other approaches fall in the category of optimizations. And the general rule of thumb concerning optimizations is to never do optimizations “just because”. First implement a very simple solution to get it working, for example by using Destroy() as mentioned by @jlorenzi .
If you then notice an actual performance problem, using the inbuild Unity profiler (which also tells you where exactly that problem is), you can then start to think about optimizations. Due to how powerful moder hardware is, for most games and most issues it wont come this far - which is why the rule of thumb says to simply not opzimize until you hit a measurable problem.
The idea of object pooling is to prevent garbage collection by recycling existing objects instead of constantly creating and destroying them as needed. For that you usually either instantiate all necessary objects, or do so dynamically while playing. However, you usually dont destroy any of them. Instead of instantiating a new item, you get one from this pool and activate it. Instead of destroying it, you return it to the pool (and possibly reset its state, if necessary) and deactivate it. Thus only the same objects are used, removing the need for garbage collection to run at all. While this might sound counter intuitive, overall memory consumption can end up lower as well, since the actual amount of objects you need is likely lower than what you would have active by instantiating things and then destroying them on a timer. However, memory should really be of “no” concern in modern times, i just thought it was a fun fact to add.
While object pooling is a nice idea, it would not be my first go-to solution, even if you notice a measurable performance problem using the profiler. Unity introduced incremental garbage collection a while ago, which spreads the load over multiple frames.
Enabling this is likely enough to reduce the problem to a level you wont notice anymore. If that’s still not enough, then you can think about object pooling or other approaches like it.
Agreed. Object pooling would probably one of the last things I would even consider. I’ve never seen it provide a net benefit. Here’s why:
The costs and issues associated with object pooling / pools:
Arguments for/against object pooling aside, just a PSA that Unity has an ObjectPool API that makes implementation a breeze. Lean Pool also works great.
Well I never knew. I just make my own pool but like the others say I only make a pool if I am dealing with something I don’t want to instantiate or if I want a fixed memory with no accidental extras.
@Yoreki thank you for all the information you gave me it will be really helpful as i move forward this is priceless bro
For now i haven’t experience any performance problem yet., and i think i can use the basic code as @jlorenzi said but;
Only one object(same object creating) instantiate in every sec. so this kind of order doesn’t make them all destroyed ?
I’m not 100% sure what the question is.
If you are asking whether all objects will be destroyed by calling Destroy(): no. Only the passed instance.
Instantiate() returns you the instance it created, which you would then pass to Destroy(), together with its timer, to tell Unity to later destroy the instance. Something alone those lines (fill with actual info):
GameObject instance = Instantiate(...);
Destroy(instance, timer);
If you are saying that the objects spawn a copy of themselves after 1s: no that wont cause problems with Destroy() either, unless you destroy them before they can create the copy. However, as a quick note, this approach is really hard to control. Which might be fine for your current game design - in which case do whatever works! Usually you want some kind of spawn manager script, which handles all the instantiating (and in this case destruction). This also allows to keep track of all currently spawned objects, for example by storing them in a list. This can be immensely useful, and is also one central place you can use to, for example, adjust the spawn rate or create more complex behavior over time.
Bro tried what you guys told and it works really fine !!! I have kind of spawn manager script should i do another script for destruction too?
Oftentimes “it depends”. I dont think an extra manager really helps there. It would also probably be the same one handling the spawning. Say your game allowed to collect a powerup that would destroy all obstacles, or something along those lines. The manager could then simply call Destroy for all objects it knows about (if it maintains a list). But since you just want to make sure that objects dont stay alive for forever, telling them to self-destruct after a couple seconds (either directly after instantiating them, or in their own Awake/Start function so you cant forget it) should be all you need.
You seem really motivated, keep at it! 
Thank you with all the help and interst you had!!!