Let’s assume i have 1000 enemies in one map, yet the maximum number of characters on screen is 50.
The game can be saved at any time.
I’m thinking this is my best option:
BP_SpawnEnemy generates BP_EnemyData on initial level load.
BP_EnemyData spawns BP_Enemy when the player enters a specified range.
BP_Enemy updates BP_EnemyData when the player leaves a specified range. Then BP_Enemy gets deleted.
A control script has a list of all 1000+ BP_EnemyData instances, range-checking 20 every tick.
SaveGames will convert between BP_EnemyData and BP_EnemySaveGameData.
As I dont know if the following **assumptions **are correct, other options might be:
2. Don’t use BP_EnemyData. Spawn 1000 BP_Enemy directly. Let the engine handle it. Disable tick & ai of BP_Enemy when out of range, the rest is already covered by the engine. (Animations, Physics). This will produce negligible overhead from sleeping characters.
3. Don’t use BP_EnemyData. Let the engine handle it, use smaller (or larger) levels, because UE4 can only handle up to X sleeping actors with negligible overhead.
4. Use BP_EnemyData, but work with triggers and individual spawn areas, because having 1000+ actors in a list to range-check 10 every tick is a bad idea. Use physics/triggers for that.
I suppose you’ll have to test
One thing is that I find that spawning things can cause hitches so it might depend on how fast your game changes?
How quickly can the spawn range change? If you suddenly have to spawn a few hundred Actors I could imagine that might cause trouble?
In the Epic video about optimizing Robo Rekall they mentioned that spawning lots of hit chimes (otr whatever it was) caused some hitches and that in hindsight maybe they should have kept a buffer of Actors and checked objects in and out as needed, so not to have to spawn too much at the same time.
Or that was how I understood it.
I tested spawning 4 characters at once a while ago and just reopened an old build. No hitches whatsoever spawning characters with ai.
I think I will be fine in regard to spawning because of the following possible workaround:
create a queue, spawn one every tick. this should have minimal effect on gameplay. (it’s singleplayer anyway )
How is your game space divided?
How large it is?
How many enemies on screen at the same time?
When and how often should enemies be spawned / hidden?
I’m almost certain hiding / loading them is less expansive than spawning. But I must admit it depends on how much enemies you have hidden at the same time.
As the game is in preproduction and concept phase, I was hoping to get a few simple, technical insights that will help me going forward.
They way you ask, the topic becomes much more complicated, to the point (i assume) it is not reasonable to ask for detailed guidance.
As Fredrum stated, I will have to run tests anyway.
Any help is greatly appreciated however!
The plan is to create a large seamless world where the player can travel back and forth the whole game.
use one persistent level with 10-20 sub-levels of about 1km*1km each.
each sub-level may have up to 1000 enemies.
use one master savegame linking sub-level savegames to load/save each enemy individually. Enemies may travel between sub-levels.
500 - 1000 enemies are spawned when streaming in a sub-level.
up to 30 characters may be spawned over a duration of a few seconds by various gameplay events.
depending on what is defined by future performance tests, the game aims to display 50-100 enemies on screen.
Since the enemies are spawned with random properties, I need to load their info from savegames after initial map-load. I just realized that is much more fun when I use two levels for one map: one containing the environment, and one containing enemy spawn dummies. The second one will not get streamed in when loading a savegame. A seperate script will handle streaming in of saved enemies.
I must mention that I have not yet wrapped my head around the asset manager. Could it help me for that purpose?
Also: I want to keep the project blueprint-only if possible, as I was able to find a blueprint-solution for all other major problems, except, expectedly, this last one.
