Cee's Funposts - A Type System for Scripting ECS
ceesstuff.github.io

cross-posted from: https://programming.dev/post/1086370

This time on my arbitrary blog: Entity component systems.

Also, highlight.js should degrade more gracefully without JS activated than last time. Note that I can’t process syntax highlighting in my build step, because I don’t have a build step.

EDIT: improved phrasing

  • TheCee@programming.devOP
    1·
    1 year ago

    Does this mean that each entity can have any number of components of a particular type in this implementation?

    Yes. I vaguely remembered that some ECS can apparently do that. If not, you’d probably settle for a branch or an optional type instead.

    Would each component also need its own ID to distinguish between two components of one type on the same entity?

    I don’t see why, unless you’re planning to query and manipulate them later again.

    Another option here is that instead of creating a BubbleComponent that’s part of the same entity as the BoundaryComponent, it might make more sense to create a new entity that’s at the same position as the BoundaryComponent’s entity, possibly using some kind of relative transformation to keep the bubble at the same position as the boundary.

    The boundary is supposed to BE the position. So some rendering system would have rendered the speech bubble in the middle of the boundary. Maybe I should have called the boundary area instead…

    • TehPers@beehaw.orgEnglish
      1·
      1 year ago

      Yes. I vaguely remembered that some ECS can apparently do that. If not, you’d probably settle for a branch or an optional type instead.

      I don’t doubt this is possible, but I’m really curious how querying would work. On the other hand, a component which essentially is just a wrapper for BubbleComponent[] is possible, but querying is straightforward since you’d just get the full list of BubbleComponents per iteration.

      The boundary is supposed to BE the position. So some rendering system would have rendered the speech bubble in the middle of the boundary. Maybe I should have called the boundary area instead…

      My idea behind using positions relative to the BoundaryComponent is along the lines of having each new “bubble entity” hold a reference to the “boundary entity”. Then you’d have a script which updates the transforms of the bubble entities to match that of the boundary entity:

      function inherit_parent_boundaries(
    child: BoundaryComponent & ParentReferenceComponent,
    boundaries: Query<BoundaryComponent>
) {
    -- This updates the child's boundary to match its parent's boundary
    child.boundary = boundaries.get(child.parent).boundary;
}

      This would keep the bubbles as their own entities and avoid the need for a single entity to hold multiple of the same component, which I think would keep the ECS overall a lot simpler. This doesn’t account for parents of parents or anything like that, but if boundaries can be something like Query<BoundaryComponent & ParentReferenceComponent?>, you can recurse up the chain until you’ve updated all the ancestors as well, and all the leaves of the tree will eventually be updated by this system.

      function inherit_parent_boundaries(
    child: BoundaryComponent & ParentReferenceComponent,
    boundaries: Query<BoundaryComponent & ParentReferenceComponent?>
) {
    -- This updates the child's boundary and all its ancestors to match the boundary of the root of the ancestry tree
    for (
        var cur = child, var parent = boundaries.get(cur.parent);
        parent != null;
        cur = parent, parent = boundaries.get(cur.parent)
    ) {
        cur.boundary = parent.boundary;
    }
}