Scalability of the data-driven approach for games with large number of units / sprites

[stephanemagnenat]

Hello,

I am experimenting with porting an old game of mine from the 90ies to Bevy. This game is a simulation-based RTS that has a large number (10k-100k) of units a in 2-D world. It was able to run in real time in late 90ies through a very simple unit update logic.

In that old time, the game update logic was separate from the display code and the latter was simple: just iterating over the part of the map that is currently being visible in the main view and draw the corresponding sprites. However, with the data-driven approach of Bevy it is not so clear what is the now best approach. For example, ideally out of engineering hygiene and performance concerns, I would like to keep the game update logic separate from the drawing code.

However in my understanding Bevy's approach would typically push to have one entity per unit and one sprite bundle per entity, but I have concern that this would not scale. In particular, I am not sure that when selecting which sprites to show there will not be an O(n) filtering of all sprites for visibility test. Sure, the original game did loop all units at each time step anyway, but it mostly did little processing per unit and the data were quite compact in memory. With Bevy, I suspect that the visibility test will be an additional loop and will be much more heavy has it will involve touching quite some parts of the memory. If that is too heavy, a solution is to spawn and kill SpriteBundles whenever the main view is moved and units enter/exit it. It feels like a lot of manual work, but it might be more performant.

So I'm wondering whether people have previous experience to share about games with similar constraints, that is, with many simple units out of which only a small portion is visibility at a given time.

Thank you!

[laundmo]

just an idea: you might want to look into how bevy_ecs_tilemap does chunked rendering of sprites

[stephanemagnenat]

Thanks for the input! I'm already using bevy_simple_tilemap for the map, but it only supports non-overlapping tiles (I need overlapping tiles, as units can partially visually overlap and not be aligned with map tiles when they move). I checked the examples of bevy_ecs_tilemap and did not see support for overlapping tiles either. It could probably work if the Tile struct had (dx: i32, dy: i32) shifting properties, as while visuals overlap, the actual map doesn't allow units to stack, but that is not implemented so far.

[laundmo]

oh I didn't even mean to use it, just look at how it handles rendering/chunking of the entities.

[stephanemagnenat]

Ah, right, good point! I just checked and it's fairly low level, similar to what I was doing 20 years ago, but wgpu/Vulkan style ;-)