- cross-posted to:
- gamedev@lemmy.ml
- programming_languages@programming.dev
- cross-posted to:
- gamedev@lemmy.ml
- programming_languages@programming.dev
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
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.