2 ms·

thanks for humoring me! i'm writing because i'm genuinely interested. so it seems like then, that the discipline in building a system in this fashion revolves

by a-dub 5y ago

thanks for humoring me! i'm writing because i'm genuinely interested. so it seems like then, that the discipline in building a system in this fashion revolves around responsibility for updates (which system is the sole updater of a given type of component) and the sequencing of those systems (ensuring that all the systems that update components that are used by a given system have completed their updates, possibly with some sort of record level update indication that allows for downstream systems to begin processing before upstream systems have completed all their records). do any of the ecs libraries provide facilities for these problems, or are they typically built into a game engine framework?

reificator 5y ago
That’s a very good question, because sequencing tends to be the place where implementations vary the most. Usually there will be some way to sort systems into steps and define the order of those steps. Some require you to hardcode the order, others define constraints like “after input” or “before physics” and attempt to solve those constraints, and some let you define groups that can run together and you define the order of the groups. Explicit signaling is not typically built in, but you may be able to implement it yourself if desired. In environments with an expressive type system, most tend to favor the constraints model. Otherwise ordering tends toward the hardcoded approach, typically implicitly in registration order. As to managing what systems are responsible for updating a given component’s state, that tends to be left to the game developer. Sometimes there is a concept of events and if it’s not obvious who should mutate something then systems that want to mutate will send events that later systems can consume. For instance an input system and an AI system might both send a Move(entity, direction) event that a later system validates and applies. And because it’s cute to do so, often times those events will be implemented as components themselves, with convenience wrappers to make it feel more natural to end user developers. This can come in handy for networked games and debugging in editor. You could also use it in game, such as displaying a unit’s next planned move in a turn-based game.
- a-dub 5y ago
  interesting. this is really cool! in the automatic constraint solver variants (which is more interesting to me) are the schedules static (precomputed at compile time) or do they run as a dynamic scheduler of sorts and are the constraints statically checked for deadlock ahead of time? this architecture is exciting!
  - reificator 5y ago
    Compile time would be pretty sweet. I've never looked into it so I don't know for sure. Don't get too caught up in the hype, it never ends well no matter what the architecture. But it's certainly useful and fun to play with.

by a-dub 5y ago

reificator 5y ago

That’s a very good question, because sequencing tends to be the place where implementations vary the most. Usually there will be some way to sort systems into steps and define the order of those steps. Some require you to hardcode the order, others define constraints like “after input” or “before physics” and attempt to solve those constraints, and some let you define groups that can run together and you define the order of the groups. Explicit signaling is not typically built in, but you may be able to implement it yourself if desired. In environments with an expressive type system, most tend to favor the constraints model. Otherwise ordering tends toward the hardcoded approach, typically implicitly in registration order. As to managing what systems are responsible for updating a given component’s state, that tends to be left to the game developer. Sometimes there is a concept of events and if it’s not obvious who should mutate something then systems that want to mutate will send events that later systems can consume. For instance an input system and an AI system might both send a Move(entity, direction) event that a later system validates and applies. And because it’s cute to do so, often times those events will be implemented as components themselves, with convenience wrappers to make it feel more natural to end user developers. This can come in handy for networked games and debugging in editor. You could also use it in game, such as displaying a unit’s next planned move in a turn-based game.

a-dub 5y ago
interesting. this is really cool! in the automatic constraint solver variants (which is more interesting to me) are the schedules static (precomputed at compile time) or do they run as a dynamic scheduler of sorts and are the constraints statically checked for deadlock ahead of time? this architecture is exciting!
- reificator 5y ago
  Compile time would be pretty sweet. I've never looked into it so I don't know for sure. Don't get too caught up in the hype, it never ends well no matter what the architecture. But it's certainly useful and fun to play with.