#Patterns for "well-known data" with cleanup components

1 messages · Page 1 of 1 (latest)

white verge
#

I'm frequently running into a situation where many cleanup components need to duplicate "well-known" data on an entity to be able to perform cleanup logic, such as the world position from LocalToWorld.

Right now the only "pattern" I've come up with is just to keep copying all the relevant data into all the cleanup components that are interested in it (sometimes every frame, such as in the case of updating positions) but this feels like a really ugly and slow way of doing things.

I find myself wishing for a type of component in between IComponentData and ICleanupComponentData:

type                  | blocks destruction | removed by DestroyEntity
IComponentData        | no                 | yes
I???ComponentData     | no                 | no
ICleanupComponentData | yes                | no

Is there a good pattern for this? Note: I'm running into this with other more game-specific data besides position as well.

cobalt root
#

Forget them and introduce your special destruction framework which will be the only place entities are destroyed at

#

and you can always query WithAll<DestroyTag>() to rely on entity being destroyed

white verge
#

hmm, isn't the big downside of that that then i need to start adding WithNone<DestroyTag> into all my queries everywhere?

#

for normal operation

cobalt root
#

why being marked for destruction supposed to change anything about other systems?

#

only when entity is being destroyed it matters, but that happens within one system group

#

A when actual destroy happens (structural change), B is whole SimulationSystemGroup, C is DestroySystemGroup

image.png
#

the reason why destroy is at the beginning is to prevent any sort of sync point

#

but if your project is ok with that - it's ok to do it at the end of C

#

for simplicity

white verge
#

my intuition is that i don't want a system B1 to process an entity anymore after it's been marked for destruction by a system B0 in the same frame, but maybe i'm just not zen enough yet

cobalt root
#

it's perfectly fine to process entity until actual disposal starts

#

because once things get disposed

#

this is when things can get broken

#

that's why all normal simulation should happen outside of destruction group

white verge
#

i know, i'm thinking more in terms of game logic than in terms of low level resource logic

cobalt root
#

that's kind of I mean

#

when entity is at 0 health, it's practically marked for destroy

#

but you don't stop working with it

white verge
#

like let's say if i have multiple game systems looking for a limited number of things to target and destroy, then thus far i've been able to use destroyentity to signal that any further systems shouldn't waste their limited game resources on that entity, and should select other targets instead

but of course that does mean that's been a sync point so it's not great in terms of performance, but it's fairly easy to reason about (i can have a Targetable tag component that's gone after DestroyEntity)

#

but maybe that in itself is an anti-pattern of sorts, i need to chew on that for a bit

cobalt root
#

In our game we destroy only dead creatures after a while

#

they already cannot be considered targets