ES GarbageCollect

This question is mainly for @pspeed however, if anyone else wants to contribute, please fell invited :smile:

Scenario:
I have SolarSystems, containing ships planets ect.

For example this tree:

SolarSystem -> Station -> Hangar -> Ship -> Hangar -> Fighter -> Player -> Inventory -> Weapon -> Ammo

Now currently what I do is that I check from time to time for Entities in the database, that are not somehow transiently connected to a SolarSystem, kinda similar to how java GC kills stuff no longer referenceable.

The reason is, that I cannot figure out a better way to remove stuff, for example anything between the station and the player might get blown up, the player might disconnect (and be removed from the game, but not from the database) ect.
Doing a full check on every entity remove, to notice what i must cascade seems like much overhead compared to only scan trough all every few hours/days.

Do you have similar problems in Mythruna/your game? What is your attempt to solve it?

How are similar problems solved in your games logic?

So… like a Station gets blown up but then somehow doesn’t delete the stuff inside of it?

I’m not sure this will come up for me as I don’t have all of those tree linkages. Personally, it feels more OOP than ES but I also don’t understand what it’s used for.

I guess in my case I will have to worry about all of the random attached entities (like damage, buffs, etc.) but they are generally temporary anyway.

At any rate, if you have those relationships in the ES then they must be defined in some component… and some system must be using that component. Else make a system that does and every now and then checks to make sure the target exists. If not then delete the entity holding the component. Eventually the chains will fix themselves after enough frames. (You could even make the next sweep come sooner if the last sweep found something.)

Don’t know if that can help but here are my two cents :

I use a Parenting component, that allow a child to know about its parent. There is no way for a parent to know about its children.

When an entity is to be removed for any reason, we add a ToRemove component on it.

Then, we have three processors (systems) :

  • ToRemoveProc : only launch entityData.remove(eId) to clean the components
  • ParentRemovedProc : check if the parent has a ToRemove component. If true, the child gain the ToRemoveNextTick component.
  • ToRemoveNextTickProc : replace the ToRemoveNextTick component by a ToRemove component.

Then you have to order them correctly: ToRemoveNextTick -> ParentRemovedProc -> ToRemoveProc

It may seem complicated but it offers a way to clean the child of a removed parent at each tick, without any performance cost. The only thing to keep in mind is that the removal information will travel slowly into the parenting tree. The grand-grand-grand-child of your blown station will be removed four ticks later.

Hope it helps

I have a similar component, yes

I have the Parent component, and a pretty similar StoredIn component.
As I work on a in memory database I also actually have a Stores component, that is synthetically created by the inventory system.

Now I only need a good way to process the actual explosion due to extra logic stuff :confused:
Eg cargo might drop when the container is shot and similar stuff.

I guess looking only at one layer (as methu…'s system does) at most every tick will help to reduce the complexity quite a bit.

Can you make a system that manages DeathByExplosionComp & StoresComp ?

When a storing entity is destroyed by explosion, it processes all the stored entities, giving them a chance to be destroyed in the explosion, and a chance to become parentless.

Your undestroyed cargo will then lose its StoredInComp and will manage its own positionning, lost in space. the exlosion blast entity will push it in the correct direction.

Something like that?

hm it already has a positonal component, so that part should work, also it actually gets a position already calculated to simplyfy some logics, might be a way