Dynamic and mixin inheritance cover most of what entities are doing. Given a more expressive language where these inheritances could be expressed succinctly, you would probably find them very useful.
It's a sort of interesting divergence from what you'd expect, though. (There's no "one way" of course, but) The Components (mixins) have all of their logic centralized in Systems which get called by the simulation tick. Adam Martin (t-machine.org) writes about how it's similar to a relational model, and even suggests the Entities and Components be stored in an RBDMS when its feasible for performance (MMOs). If you're not using a database, then you're sort of replicating the relational model in your code.
entity: id
component: id field1 field2 field3...
entity_component: ent_id com_id
Then your tick iterates the Systems, each does a query for the relevant components, applies transformations, and puts back in the datastructure. So your logic is very centralized, and the entity behaviors are basically declared by a combination of choosing its Components and choosing the active Systems.
Driving behavior via time is easy once you have your object plumbing. You may also requisition events for this purpose and allow for them to be plumbed separately, if that's useful. I just wrote a paper on such a system, coincidentally:
Entity component systems are not true behavior systems: they do not implement subsumption of behaviors as reflexes. Check out Rodney Brooks' subsumption architectures which is 20+ years old now and used heavily in robotics. The Kodu team used this heavily and I adopted it to one of my own languages once:
Comments
Dynamic and mixin inheritance cover most of what entities are doing. Given a more expressive language where these inheritances could be expressed succinctly, you would probably find them very useful.
It's a sort of interesting divergence from what you'd expect, though. (There's no "one way" of course, but) The Components (mixins) have all of their logic centralized in Systems which get called by the simulation tick. Adam Martin (t-machine.org) writes about how it's similar to a relational model, and even suggests the Entities and Components be stored in an RBDMS when its feasible for performance (MMOs). If you're not using a database, then you're sort of replicating the relational model in your code.
Then your tick iterates the Systems, each does a query for the relevant components, applies transformations, and puts back in the datastructure. So your logic is very centralized, and the entity behaviors are basically declared by a combination of choosing its Components and choosing the active Systems.Driving behavior via time is easy once you have your object plumbing. You may also requisition events for this purpose and allow for them to be plumbed separately, if that's useful. I just wrote a paper on such a system, coincidentally:
http://research.microsoft.com/apps/pubs/default.aspx?id=2112...
Entity component systems are not true behavior systems: they do not implement subsumption of behaviors as reflexes. Check out Rodney Brooks' subsumption architectures which is 20+ years old now and used heavily in robotics. The Kodu team used this heavily and I adopted it to one of my own languages once:
http://research.microsoft.com/apps/pubs/default.aspx?id=1793...
Elephants don't play chess indeed!
managed time sounds a lot like how FRP (Functional Reactive Programming) and even things as simple as Rx (Reactive Extensions)
Yes, those are both covered in the paper (back in Section 5).
Thanks, I'll give them a read.