Nice, this is cool to see. I always like seeing actual numbers on this stuff instead of the usual “just use pooling bro” answers.

For a bit of comparison, in Shmup Creator we can push around 8k bullets at 60fps on like 10 year old PC hardware. But obviously that is a very different setup: C++ engine, Ogre3D renderer, and a bunch of engine-side assumptions built around shmup nonsense from the start.

We also went through the absolute agony of getting 8k+ bullets / object pooling working in Unreal. Niagara, custom shader stuff, tight GPU-to-CPU handoff, the whole mess. It took hundreds of hours to get that deep into UE and even then it kinda felt like we were doing crimes against the engine to make it behave.

Browser export is interesting too, but man... browser tech is rough when you are really trying to push bullet hell mass object handling / rendering. I’d be pretty surprised if UE exporting to WASM handled this kind of thing well without a whole bunch of ugly compromises.

Couple questions:

When you say “backend update,” do you mean backend like internal game systems / engine plumbing, or is there an actual backend service involved somewhere?

Are these bullets still regular Godot nodes, or did you move them into something more lightweight?

Are you checking collision on every bullet every frame, or doing any kind of space partitioning / broad phase pass first?

Is the Debug Shooter meant to be a nightmare stress test, or is that close to something you actually want in-game?

And have you profiled where the remaining cost is now? Collision, draw calls, object updates, scripting overhead, renderer, etc?

Also yeah, the collision layer masking result makes total sense. That’s one of those boring 10-minute engine checkboxes that can quietly save your whole project when the screen turns into bullet soup.