In this case, would the components be combined into a list? Basically you’d have a BubbleComponent[] attached to the entity instead of just a BubbleComponent? Maybe I’m misunderstanding what the system is, is click_handler in the post a system, and if so, do systems only declare a single component of an entity as their input? From my experience, you often want to work with multiple components of the same entity in a system, for example:

-- Mark characters with 0 or less life as dead
function mark_dead(character: BoundaryComponent) {
    with character as movement: MovementComponent {
        character.x += movement.velocity.x * delta_secs;
        character.y += movement.velocity.y * delta_secs;
    }
}

Would there be a simpler way to query these components in the system, and what if I wanted to query for both BoundaryComponent and BubbleComponent, what would that look like?

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;
    }
}

I do not consider programming in Rust scripting.

I don’t think most people do to be honest, I was providing it as reference because it’s a strongly typed ECS. One of the other challenges with scripts is they often don’t have static type checkers since they’re intended to be executed right away. mypy and TypeScript have helped tremendously with Python and JavaScript, but they’re still extra steps that need to be executed before you can run your code.

an embedded interpreter seems kind of off the table.

An embedded interpreter can still be highly performant, assuming it has a decent JIT compiler. Sending data between the host and the interpreter would be a concern, but it might be possible to allow the script to share memory with the host and directly access the components (while holding locks on those components’ storages). I tried experimenting with this a while back using WASI, but unfortunately the runtimes I played with (wasmer + wasmtime) weren’t yet mature enough from my experience to be realistically useful, and I couldn’t figure out how to get the modules to share memory with each other.

I know there are people playing around with scripting capabilities in bevy though, so I’m sure this will be possible at some point. The other challenge, of course, is having a scheduler that’s flexible enough to handle dynamically added/removed systems, and systems which execute runtime-specified queries.

Edit: I should add that a large part of the performance of an ECS comes from the ability of an ECS runtime to parallelize the systems. If your interpreter can execute the systems in parallel, then you still get to keep that benefit as long as your scheduler knows which systems are safe to run in parallel.