I was hoping to get some input from the great minds on the forum who know more than me in this area. I’m working on a game that spawns a random dungeon made from prebuilt chunks and my concern is optimising enemies. Correct me if I am wrong but suppose my chunks have enemy spawns inside of them (These could be simple blueprint “turrets” or Behaviour tree AI enemies) all of the enemies around the dungeon will be firing ticks and slowing down the game tick?
I was wondering what the best practise is for having lots of enemies placed around a map? I would only expect at most 10 enemies could be on screen at once in my current gameplay but then if that volume of enemies existed all around the map and were ticking off screen I imagine it would begin to lag.
I thought about maybe having spawners that spawn the enemy once the player gets close but to be checking that information all of those spawners need to exist and tick so perhaps a single master blueprint some how gathering the spawn locations and doing the distance checks would be more efficient?
Rambling aside I would greatly appreciate any insight you might have on this subject. Thanks for reading!
The first thing that springs to mind is not to spawn enemies unless the player is in that “chunk” of the dungeon. You can use a trigger to spawn them once the player enters a zone. You don’t need to use tick, you have an event that is fired when the player hits that area, then it spawns the enemies. I think most games use fog of war to hide everything beyond a certain distance so that the player never notices enemies appearing out of nothing.
There’s stuff that you need to use tick for, but most of the time I’d use something else when you can. If your AI is simple you may not be using that much processing time on ticks anyways, there’s a resource profiling display built into the editor that will break everything down for you. Your usage of tick may be fine. I don’t know what your AI logic is, but if it’s complex you can ask yourself if there’s an equally good solution that doesn’t involve using tick.
You raise some great points, I hadn’t considered using triggers around the chunk to dictate when enemies should spawn. Right now I don’t have much set up for AI, I’ve got a basic slime enemy that uses behaviour tree to pick a direction to jump and favours jumping towards the player and I have a turret that spawns a projectile when you get in range of it. Mostly i’m just trying to think ahead so I don’t get caught off guard and need to redo the dungeon system or AI or whatever else this may affect.
I think for a typical linear game, such as a first person shooter campaign, I can understand using a series of triggers and conditions like needing to kill off all the enemies before advancing. Adding triggers to the chunks to spawn enemies sounds like a good road to go down but I still wonder what would happen if players ran into every chunk without killing anything. An effective method for culling enemies might be needed when they get too far away and then making that work in such a way that players can’t simply run away to despawn enemies.
You can use a sphere or box around your player and put enemies to sleep that are too far away. You don’t need to despawn them. You can also use that sphere or box to wake them.
With triggers to spawn and sleep/wake you should have a pretty solid setup that will probably work most of the time.
@ When you say “put them to sleep” what do you mean by this exactly? Closing a gate after its tick event/disabling its behaviour tree? Does having all those blueprint ticks hitting a closed gate not really impact the game tick? (sorry to bombard you with questions :D)
That looks very useful thank you! I think I may have got myself worked up over nothing. I was using the butterflies in the blueprint office demo to test things like going off player distance. I duplicated out about 100 of them and placed them at varying distances around the level but I saw I was still getting signifiacnt slow down even though they were just hitting a closed gate if they wern’t near the player. After going back in to test again I noticed that they had timelines that autoplayed! I turned that off along with everything else and the lag went completely even with 100 of them placed around randomly. I’m going to give it a go from scratch just to make sure though.
That said the stop tick nodes could help optimise even furthur. Thank you again!
I might have tricked myself. For some reason having the blueprints closer to me but still not close enough for the gate to open still causes the game tick to lag. Maybe the butterfly just isn’t a good test because of the particle systems and such attached to it. Although the set actor tick node you linked seems to remove the lag comepletely as if they are miles away again. Is there something built in where at a certain distance blueprints don’t tick?
I worked out why it was being so inconsistent. It was the timeline autoplay. I didn’t notice that clicking save and play isn’t enough to change the autoplay setting I need to click recompile as well so when i thought it was off it was actually still on, my post before this was rightfully optimistic
Even when you don’t do many computations every tick, there is still some overhead. With gates the overhead stays. Using the stop tick node removes the overhead.
Particle systems shouldn’t be an issue because they are only calculated and rendered when visible (I assume).
