Add a stagger() option to systems to spread iterations over multiple world ticks.

[LouChiSoft]

Apologies if this has been brought up anywhere else, I had a search and didn't seem to find anything that matched.

This idea came from wanting to make a horde shooter style of game. You could have 100s maybe even low 1000s of enemies all needing to do navigation calculations. You obviously don't want to be recalculating their navigation every frame, so the first thing you will probably do is put it on a timer to only run maybe once a second, this solves having to calculate all the navigations paths every frame, but still leaves you with a computation spike every second when that system gets triggered.

My proposal would be to add a Stagger() option to the world.system() call which takes the query conditions and splits it up over several frames to more evenly spread out the computational work load. Some example numbers: 600 enemies, each updating their navigation once a second, in a locked 60 FPS game could be reduced down to 10 enemies per tick. If you have a lot of systems that can benefit from this I could see it being a much smoother experience.

There are some caveats I can think of that I am not immediately sure what would be the best way to handle. e.g:

• If on system 'launch' you segment the query into chunks then what if between the first batch and the second batch of calculations the number of entities changes and then that second batch is mostly non-exist. This would result in inefficiencies. But equally calculating and tracking the entities that have been added, removed and previously processed might be just as inefficient
• Delta time might be an issue, with a Timer it's as simple as the Timer interval essentially becoming delta time. But in a staggered system where you might not have a stable interval between batches this could cause inaccuracies.
• How do you split the entities in a query up. This is less of a technical caveat and more of just a design choice. Do you design Stagger to split by something logical like the size of a cache line or do you let the user choose the chunk size and then dynamically dispatch number of chunks needed over a set amount of frames. In the case of the latter how do you encourage users to not Stagger systems that end up adding more overhead for staggering than it would have been to just run the entire system on a timer, etc.

Would love to hear some feedback

[SanderMertens]

The biggest challenge with staggering updates is that it's difficult to guarantee that each entity is updated the same number of times, if you also want to allow for adding and removing components dynamically. It would be possible to do this application side though, either by manually maintaining a list of entities, or using some trick like doing a % on the entity id.

[LouChiSoft]

Thanks for the reply. I won't lie, I don't really know what a great internal solution could be. Maybe lock a single loop of all the entities to their chunks, and then check if they are destroyed before calling the system for it? Then on the next loop redistribute the chunks. IDK what the kind of overhead for maintaining and checking that information would be, or if that's even possible.

It would be possible to do this application side though, either by manually maintaining a list of entities, or using some trick like doing a % on the entity id.

Not sure I follow, don't suppose you have some pseudo/semi-accurate code for what you mean. I might be able to wrap it all in a class that does the boilerplate code for the system.