TODO/New features

[louisponet]

This issue is partly to group some todo's, partly to engage in a discussion on design for certain features, since they might influence many things in the future.

• Groups: what is the right way to implement. Basic implementation exists but is not ideal.
• Children: sometimes it would be desirable to have a Child relationship so certain components can be reused between entities. e.g. annotate a point with text, the text entity would use the coordinates of the point so that it automatically moves with the parent
• Entity creation: After working with a more complex set of components and systems in Glimpse, it became clear that sometimes one wants to create an Entity that would work with a certain System, is there an elegant way to formalize this somehow?

[dumblob]

This sounds a bit like a path to the ECS "generalization" as outlined in https://ajmmertens.medium.com/why-vanilla-ecs-is-not-enough-d7ed4e3bebe5 (which I'd everybody interested in ECS to read and at best also to follow 😉).

[dumblob]

Btw. there are some thoughts about merging ECS (i.e. a strictly synchronous architecture) with an asynchronous architecture in Pauan/rust-signals#31 (reply in thread) .

If you find you have some spare time to explore that area, that'd be awesome. So far the best candidate for testing such merger seems an ECS UI (like traffaillac/traffaillac.github.io#1 ).

[louisponet]

Hey, nice little blogpost. I must say many of the things that he's alluding to I also ran into and agree with. Some comments:

• Things like his "system belongs to a phase" is very similar to my Stage construct. I would like to have a more event driven orientation too, but I'm not entirely clear on how to do it in the best way. I thought about something like a Pipeline with Systems, but I haven't come up with a solution that I really like.

• The being able to assign components to (entity, component) is very interesting, I think this is a very valid idea, I'm not entirely clear on what would be the best way to implement this though.

• SharedComponentalready does some of the component sharing, I think it is relatively workable.

• About Children and a more general Role, I found that just having a Child Component with the id of the parent entity works relatively well. Of course this is not automated and so deleting parent entities is a bit iffy to say the least.

If you have some concrete thoughts about how to design some of these features, especially the Role, (entity, component) identifiers, and event driven System updates, please let me know I'm keen!

[dumblob]

If you have some concrete thoughts about how to design some of these features, especially the Role, (entity, component) identifiers, and event driven System updates, please let me know I'm keen!

Right now not though I'd like to devote some time to think it through and if anything good comes to my mind, I'll try to explain it here 😉 (I'll probably start by exploration of @async or @task macros in conjunction with event-driven System updates...).