Cap on enemies on map to avoid UPS/FPS drops
Posted: Thu Aug 14, 2025 1:13 pm
TL;DR
Did you ever mess around, just playing around, but because you destroyed tons of bases, the enemy now gathers to attack you but... there is a timer... and as they gather, there is UPS/FPS drop...What?
A lot of the base defence, including asteroid vs spaceship, is fun to play around with. Sadly, the more you mess around having fun, the more of them swarm on the map until the drop happens... and to avoid that, you avoid what you are doing... so you stop having fun messing around to avoid the drop. But that is exactly the joy kill. Adding a mod to make enemies stronger to reduce their number is not the same as having a horde of them attacking; it's just a challenge, not the fun of messing around. Example with the asteroids: if there is an FPS drop, we could have a new button saying "optimise" (or whatever, just to keep it simple). The fire rate of everything would be halved, their range doubled, and the speed of the spaceship halved (not the actual speed, but what is handled by the program). Instead, all the asteroid swarm would be halved. The idea is that in-game, nothing changes; it's just that the program load is reduced. Like the double range I mentioned — this is actually for the railgun because it fires a long line. Since the asteroids do not yet exist, that means attacks that could have hit them don't... except now that attack is kept in a "memory". When the new asteroids are spawned, they are checked to see if that memory attack would have hit them. If yes, then they don't show up at all because they were destroyed by the railgun seconds ago. The whole idea is to reduce the load without actually changing the game itself, just limiting how many "exist" at a time.Regarding the biter (won't even talk about Gleba), unless we visually look at them on the screen, the biters do not even exist. They only exist off-screen before they attack, to avoid issues caused by non-existing biters. The whole "gathering" would be only a single biter to not cause issues of bitter existing where they could not (bugs). As we look exactly at them, the inexistent ones would be generated. But if we never look at them, they never existed, avoding drop. And when it's finally time to attack, for one instant, calculate how many should have existed and then create them. This will result in the horde of bitters without the impact on the PC. To put it differently, at max evolution, even small bitters could show up duing an attack. Maybe hundres of them. All this because 1 single bitter existed, when to attack, and once we finally look at this one, just before it attack, not only will there be a lot of behemoths, there will be many big ones, even more medium, and who knows, maybe tons of small ones. This is why I said, there could be a possibility of hundrends of bitters at the same time. Because the focuse is on them and any other bitter (off screen) dosen't not exist except for 1 place holder for each group. I will say this one more time: this is only when the numbers of bitter is more the X. Before there is no change. After? there is a cap how many to exist. How is this cap decided? either automatically if there is a way to use the FPS/UPS drop as a trigger, or manually, via adding a new "optimise" button to manually tell the game that you are having drop and needs to trigger this cap <- i'm talking about that little section where we can click for alt view, personal roboport, exoskeleton, so on.
Other elements: when there are more than X numbers of biters that will attack , there should be no gathering or waiting. Instead, multiple are generated extremely fast for the attack, meaning no need for a "gathering"; they already start going for the attack. The group goes through the normal phase as all the new ones generated will run to join the group. Once the attack group is maximised, immediately trigger the run to attack. This reduces the impact on the PC without reducing the numbers. Speeding them up with no wait time is the alternative I suggest.
Why?
To avoid FPS drops via cap. If said cap is reached or crossed, change behaviour by STOP generating more, but speed up the existing ones massively, while the next in queue won't be cancelled or voided — just set to generate and attack extremely fast next. This means we can add mods that add tons of enemies. It will be possible to have gameplay where we can have possible hundrens of them attack one area. Making us neccesary to use a nuke at our own base to just avoid the complete destruction of it.Plus, if you ever increase how many asteroid to exist (before start of game slider), going to the end poit of the univers, it will be extremly slow due to fps drop or you need to slow down the space ship to avoid fps drop questioning which of the 2 option is actually the fastest since it's so slow. With this cap, you can avoid the ups/fps drop caused by having to many of them on the map, meaning, as long as you have the ammo, energy, and fire power, you never need to slow down (and the devs or mod devs will be able to add stuff on that destination exactly because we can do automation to get to or from, even at high asteroid swamp rate)