this post was submitted on 30 Jul 2023
10 points (100.0% liked)
Programming
13212 readers
1 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 see why, unless you're planning to query and manipulate them later again.
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...
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 ofBubbleComponent
s per iteration.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: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 likeQuery<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.Makes sense, I guess. I really can't comment on the wider implications with an ECS, though.