Solving Enemy Blob Performance Issues: Distance-Based Optimizations

 Distance-Based Processing When @anon4life reported that enemies blobbing together caused performance issues despite maintaining high FPS, it led me to investigate collision detection as the likely culprit. Through debugging, I found that having numerous enemies with active physics processing in close proximity was causing the stuttering.

Here's my solution: A distance-based processing system that intelligently reduces physics updates for enemies based on their distance from the player. The code introduces a dynamic update frequency system where enemies that are far away from the player don't need to update as frequently as those nearby.

When an enemy is more than 200 pixels away, they only update 30% of the time. Between 150-200 pixels, they update 60% of the time. And when closer than 150 pixels, they update every frame (100% of the time). This is achieved using a random check against the check_frequency value. For example, when check_frequency is 0.3, there's only a 30% chance the enemy will process physics that frame.

The benefit? Enemies that are far from the player and less relevant to immediate gameplay consume fewer CPU cycles, while enemies close to the player maintain full responsiveness. This significantly improves performance when you have many enemies on screen, without the player noticing any difference in gameplay.

Dynamic Enemy Cleanup While implementing the distance-based processing helped, I still needed to address the root cause of too many entities with active collision detection. Special thanks to @anon4life for bringing this issue to my attention - it's exactly the kind of real-world testing feedback that helps make games better.

I implemented a dynamic enemy cleanup system to maintain performance as enemies accumulate during gameplay. The system works by establishing a "despawn radius" around the player - think of it as a huge invisible circle. Any enemies that wander outside this circle get automatically removed from the game.

The code runs every time the spawn timer ticks. First, it checks all existing enemies and calculates their distance from the player. If any enemy is beyond the despawn radius (in this case, 500 pixels from the player), it gets removed using queue_free().

Why is this helpful? In bullet-hell or survival games, enemies tend to build up over time. Without cleanup, you might end up with hundreds of enemies that are so far off-screen that they're irrelevant to gameplay. These distant enemies still consume processing power even though players can't see or interact with them.

By removing distant enemies while continuing to spawn new ones closer to the player, I maintain a constant, manageable number of active enemies. This helps prevent performance issues that could arise from having too many entities active at once, especially when enemies tend to cluster together.

The value of 500 pixels for DESPAWN_RADIUS can be adjusted based on your game's specific needs - you want it large enough that players never see enemies pop out of existence, but small enough to effectively manage your enemy count.

Both these optimizations work together to handle the "blob" scenario, where lots of enemies cluster together and overwhelm the physics engine. It's a great example of how community feedback leads to better optimization strategies and ultimately a smoother game experience.

Future features: Crowd controll ability, Enemies will try to encircle player instead of going like herd, Wizard will spawn projectiles from distance - This things will probably come in separate updates not all in one :))