I thought the way explained on the first post was the best way
ed.setComponents(hitbox,
new Position(pos, Quaternion.ZERO),
new Velocity(new Vector3f(-500, 0, 0)),
//...
);
for (int i = 0; i < 50; i++) {
Vector3f bpos = pos.clone();
bpos.x += SPRITE_SIZE * (i * .02f - .3f);
bpos.y += SPRITE_SIZE * ((float) Math.random() * .12f - .0f);
ed.setComponents(ed.createEntity(),
new Position(bpos, Quaternion.ZERO),
new Velocity(new Vector3f(-500, 0, 0)),
new DecayTogether(hitbox)
);
Or you mean that I should make a component on the hitbox that keeps track of all the “children”?
Besides, is it an antipattern to query if an entity is removed?
Anyway… because I’m heading to bed and I don’t want to leave you hanging… if you really must persist down this path you are on… and it feels very weird and so hopefully there is a non-weird way…
You can remember that an entity is never really “removed”. It just may not have the components you are interested in. For example, your ed.isRemoved(parent) call could just as easily be replaced with a ed.getComponent(parent, Position.class) == null.
That’s the only thing you can know: this entity doesn’t have the component I’m interested in. It’s not “removed”. It’s just an unfortunate convenience that there is a remove() method that will clear all of the known components.
As you can see from the code, each has a separate random position, so I can’t just slap together a “Model” and a “hitbox” component on the same entity.
Why should I manage these particles without an ES? I see no benefit.
Maybe one day I’ll upgrade the visuals and use a different approach altogether, but for now that’s it.
Yeah, or even a standard JME particle control or whatever.
I mean, to me, if this is a client-server game then the server doesn’t really care to send status updates for every little visual particle if it’s never going to interact with a game object.