Multiple entities forming one entity about engo

[paked]

Most other engines implement this as a group.

However, I have no idea how this looks from an ECS standpoint. Perhaps things are just bound together because they are part of the same system?

[EtienneBruines]

An Entity mainly being a []Component, a group would roughly be [][]Component.

I could imagine we add another Update function?

func (s *Systemer) Update(group *engi.Group, dt float32) {
    var (
        rcs []*RenderComponent
        spaces []*SpaceComponent
        ok bool
    )

    if rcs, ok = group.ComponentsFast(rcs).([]*RenderComponent); !ok {
        return
    }

    // ....
}

(Note that we probably cannot cast to []*RenderComponent, but for the sake of argument, let's say we could)

[paked]

@EtienneBruines I think the best way to do this would be with a group of Entitys, as opposed to [][]Component.

[EtienneBruines]

According to the stuff I've read on Stackoverflow and forums of other engines, the solution they talk about, is to have the user/programmer implement some kind of ParetnComponent, or HealthBarEntityComponent, which holds a reference (pointer) to the linked Entity. This means that the HealthBar Entity doesn't have to be part of the System which manages the Health - but when the health-bar changes (when the HealthSystem has processed the playerEntity), the referenced HealthBar Entity will be changed (i.e. the RenderComponent).

Long story short: the user should implement this, preferably by creating custom Components which hold pointer references to those Entitys, and only add those Entitys to the Systems which actually process it.