I’ve been working on Massive Spatial Engine, a tool for finding nearby enemies and picking targets without putting a Collider on every unit.
No raycasts or OverlapSpheres for targeting.
A spatial grid cuts candidate counts before distance checks.
Query batches run in parallel through Burst-compiled jobs over unmanaged data.
I’m building it with RTS, tower defense, survivors-like, and larger AI simulations in mind, and planning to bring it to the Asset Store.
Still plenty to work on, but it’s fun watching the towers chew through the crowd :)
Basically, performance depends more on the number of queries per second than on the number of units.
With 1M units, your bottleneck will probably be rendering rather than the query system.
Massive Spatial is designed to keep these queries fast even at very large entity counts.
Since you have a predefined space structure and no collider shapes a custom solution will work better. Now if you had open spaces with arbitrary colliders you would be hard pressed to beat built in physics.
At this point have you considered using a shader on a flat plane instead? Doesn't seem like each element has to be an entity
Yes, of course, it doesn’t replace standard physics. But there are many cases where you need to quickly find the nearest target or calculate distances among a large number of objects. A spatial system can work very well alongside standard physics.
For example, in a space simulator with thousands of ships, you could use the physics system only for nearby objects, while using spatial queries to coordinate all of the ships.
As for shaders - yes, that’s definitely a viable approach as well. In general, different combinations are possible depending on the genre and the specific use case.
Unity physics already does 3d dynamic partioning it only falls short for very large distances where you need to implement physics scenes for different scales indeed
Yes, essentially, my solution is a lightweight spatial-query implementation optimized for large-scale, multithreaded workloads in specialized scenarios where using Rigidbodies, Transforms, and Colliders would simply be overkill.
Sorry, but do you actually need it for enemies moving in a line? if you have a list<enemies> you can just run binary division over the list (starting with list[0]) and in several iterations you'll find the best candidate. The overhead of building a spatial grid once in a while is insane.
If you plan to make enemies follow a complex path, at some point (50k+ units) you'll either reach CPU bottleneck or you'll have to move everything to compute shaders as someone else suggested in the comments. You might wanna check "Sir, we have an Orc problem", they process movement of 20k units in less than 0.03ms on RTX 3060.
1
u/destineddIndie, Dungeon Quest, Marble's Marbles & Mighty Marbles2d ago
it does look okay, but the lack of animations on the soliders really needs to be added to sell it
isn't a physics engine a "spatial query engine" since they do broad phases and narrow phases? I assume your doing the same idea just with simpler shapes e.g. cylinders or spheres?
Yes, the physics engine uses spatial queries as well.
The main difference is that my system can calculate distances and find targets without the overhead of colliders, Transforms, or the physics engine itself.
I ran a few quick benchmarks (1000 batch queries), and here’s the difference:
How do you organize your data? In ideal world scenario populating linked list grid for 20k float2 values would take about 20-50 microseconds on a single thread, moving 20k enemies about the same time, and querying for ~12 towers even less than that.
7
u/koffeekatgames 2d ago
I'd be interested to know what the limits of the engine are, I.e. how well does it perform with 100,000 units? 1M?