I notice that when an enemy spawns in a location where it happens to hit the collider of another object, it ignores that collider. Is there some way to turn this off?
I have a squarish spawner object that enemies appear on top of, but because the enemies have to spawn in a place where the spawners collider is present, the enemy always falls into the spawner square because it is ignoring the collider. If I spawn it way way above the spawner (which looks too weird to keep) it lands on the spawner properly.
Sorry this is just one of those quirks that is hard to google.
You need to change the way you look at instantiating objects.
You are currently creating a new enemy every time you call instantiate, thats fine, it works simply.
But if you where to create all your enemies (10/15/20?) in the game scene at the start of the level you can put them into an array and de-activate them all. When you need an enemy simply iterate through the array until you find an enemy that is NOT active and then activate it, and move it to position.
Instantiating objects at runtime is not very efficient when it comes to memory management as everytime you instantiate and destroy an object you leave sections of memory of the size of that game object. This results in a fragmentation of your objects in memory.
By insantiating (or creating manually) all your enemies at the start of the game and simply activating/deactivating them when you need to your game will run far better.
Now as for your problem with colliders, if you create a solution similar to the above you can move the activated enemy to your spawn location and it should detect the collision.
Quick Tip: Don’t get too hung up on issues like this, block out as much of your game as possible and dont be tempted to work on each part until it’s perfect. Who knows you may end up re-doing large parts of it! Focus on your game and gameplay and try and ignore the cosmetic bugs at an early stage.
I’m not sure how optimal this solution is. What if you run out of queue up enemies?
I do not know if this is true, but assuming that it is, i would still argue that it’s a bad idea. If you initiate everything from the beginning you are using as much or more memory than by doing the initiation as you run. Fragmented memory spaces are better than no memory spaces.
I agree with this though - If Alastairs solution is easier for you to implement, go for it. What matters in the beginning is getting off the ground.
It does seem counter intuitive at first but give some consideration to how certain situations would welcome this approach. With regards to limits you do have to put time into planning how many of certain things should be allowed in game at any one time. (number of players/weapon drops/health pack)
For smaller projects it may not be as important I agree but if you’re hitting the upper end of the memory heap you will run into problems when trying to create new objects that may be too big to fit into the last cleared stack. Also keep in mind the overhead involved with the Instantiate() method, this is far greater than that of gameobject.active.
Bottom rule really is it’s faster to work with a memory cache than to keep destroying and recreating it; it’s an optimisation technique hands down but it will give you a better understanding of how your game is actually working under the hood. The ideal goal should be to fit your game into the memory limit on whatever platform you are building for (and as long as your assets are optimal with regards to textures/meshes you shouldn’t have any problem with memory limits).
I mean realistically you’re not going to run out of memory these days but it does make a huge impact on mobile devices if you set up all your game components before you start the game. Think about a checkers game, you could easily just create and destroy the tokens, or create 26 tokens as you know it’s finite.