Game Loop and System Order

Hello

After reading about System Update Order at https://github.com/Unity-Technologi.../content/ecs_in_detail.md#system-update-order I'm left with thought that using attributes [UpdateAfter(typeof(OtherSystem))], [UpdateBefore(typeof(OtherSystem))] , [UpdateInGroup(typeof(UpdateGroup))] and Barrier is the only way to set systems order.

For now I'm used to writing a game loop function, with all systems in explicit order visible directly from source code, where some sets of systems may run in cycle, some system called multiple times per frame from multiple places.

Is there a reason to force using attributes instead of writing custom game loop?

 

I believe for cases where you don't need A to precede B, it's best to leave it unspecified because then ECS can decide the order between A and B for itself, in some cases choosing the more optimal order. (I haven't looked at this in the code, so not sure about this.)

I agree it's bothersome to not have a central listing of the update order, but I believe the Entity Debugger window in a future release will show you the systems in their update order.

 

This happened to me. It is a bit uncomfortable to think in terms of system's "requirement" (what it needs before it can run?) rather that hard fix your loop design like the MonoBehaviour script execution order way, but currently in my game I have so many unexpected execution ordering in my Profiler, and yet everything runs correctly as I wished.

Those ordering will be optimized so that the worker thread is always busy with jobs while still as much progress as possible in the main thread.

 

I can see how ordering JobComponentSystem updates could be automatically optimized, but I wonder what, if anything, is done for regular ComponentSystems? Could running two systems with same/similar component groups immediately after the other avoid cache misses?

 

Actually I don't know how it figure out the non-constrained ordering for me nor how it knows (or adapt on the fly on later frames?) the length that my jobs would take at all. Need to read it when I have time.

 

I do believe that ComponentSystems are also factored in when optimising the system order. It's mostly dependent on how you configure your systems to interact with the data it's operating on. If a system is manipulating some ComponentDataArray directly by changing values it'll have to be factored in when the job scheduler needs to schedule jobs that operate on the same data. If these systems weren't taken into account then I don't see how the job scheduler can guarantee not having race conditions on your data.

 

I'm pretty sure that, immediately before a ComponentSystem update, you'll get an exception if the system has component groups conflicting with any scheduled jobs. In general, job conflicts (including conflicts with the main thread) are not resolved automatically, but the safety checks will at least tell you about the conflicts, and then you have to resolve them by...

1. changing the update order
2. or completing the job(s) before the conflicting update
3. or making the conflicting ComponentSystem into a JobComponentSystem that does the work in jobs