Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Is there a way to loop the ECS systems while work still exists?

Discussion in 'Entity Component System' started by Arowx, Jul 2, 2018.

  1. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    There seems to be a need for a way to have all the work done between frames which is hard to do with a pipelined set of systems e.g.

    Say we have systems:

    A B C D (in that order)

    now a flat pipeline means any processes or behaviours that traverse the systems like this...

    A->B,
    A->D,
    B->D

    work fine but what if we need

    B->D->A
    or
    D->A
    or
    C->B

    to happen in a frame.

    If the ECS had a loop til done or 'end of cycle time' reached option then we could have processes that don't need to be repeated in the loop e.g.

    A B C D A B (solves the above problem paths).

    to cope with different process paths.

    Is there a way to loop through systems that still have work in the current frame?
     
  2. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,683
    Fast solution (but not beautiful)- use own MyUpdate wrapper for protected OnUpdate and call him directly from end of D. (If this systems deallocated injected arrays for some reasons then in MyUpdateWrapper will use UpdateInjectedComponentGroups)
     
  3. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    You wouldn't use systems as the entry points for pipeline stages in cases like that. Systems running once per frame is basically an entry point to the system for that frame is I think the best way to think of it. So likely your pipeline would simply be a job chain within a single system.

    Recursive logic in pipelines is likely a code smell. Maybe you do have a case where it's really needed. But it's more likely just not the best design.
     
  4. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Got the idea from the FSM thread where you want dynamic and different behavioural trees within a game to allow the characters/units to behave/operate in different ways. In standard ECS you would have to run through multiple frames to build up a complex behaviour set with a looping system you could ensure that near all the behaviours that are needed are completed in one frame.

    Imagine a Guard, the default behaviour is to
    1. look around for the player.
    2. listen for the player.
    3. if sighted or sensed alert other guards and persu player.
    4. If not sighted then move along patrol path.
    The if the guard is alerted...
    1. Move quickly to alert point e.g. NPC/Guard/Tower
    2. look in move direction.
    3. listen for player but moving fast so reduced sensitivity.
    4. if sighted or sensed alert other guards and persu player.
    So in ECS Systems we would have

    S - Look
    L - Listen
    A - Alert
    M - Move

    Default Guard -> S->L->?A->M
    Altered Guard -> M->S->L->A

    The default Guard can complete a cycle in 1 frame the Altered Guard which should move faster actually takes 2 frames.

    Note: A looping ECS system is not recursive it would simply continue looping while there is work to be done in each system or the frame ends.

    repeat {
    if work run S
    if work run L
    if work run A
    if work run M ​
    } until work done or end of frame
     
    Last edited: Jul 2, 2018
  5. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Systems are designed to work at the higher game loop level. So you can reason about them in relation to other things running at that same level of abstraction.

    So the kind of ai logic you are outlining would be encapsulated inside a system. Or maybe a few systems but you wouldn't have every granular detail a separate system. You can, it's just not going to scale well either in performance or complexity. You need to move fairly large chunks of logic into your jobs and they encapsulate most of your FSM/Behavior tree logic.
     
  6. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    The problem with a lot of the examples/ideas out there now is they are mostly toys. Look at stuff actually doing any real work or at scale and you find not a lot of systems, not much work in OnUpdate, and the bulk of the logic in jobs. Like the Austin tech demo, the pathfinding solution that was posted, etc..