Prestazioni a collo di bottiglia in ECS

Una possibile soluzione sarebbe quella di sostituire l'entità con una nuova entità senza componenti. Con il setup che hai, sembra che sarebbe solo questione di lasciare l'entità lì e rimuovere tutti i componenti che fanno riferimento all'ID dell'entità. Quindi, i tuoi sistemi dovrebbero naturalmente saltare quell'entità dal momento che non ha i componenti che richiedono.

Allo stesso tempo, è possibile aggiungere l'indice a un elenco di indici di entità "riciclabili". Quando crei nuove entità, se c'è qualcosa in quell'elenco, sposta un indice fuori dall'elenco e usa l'entità a quell'indice invece di posizionarlo alla fine. A questo punto non avrà componenti, quindi puoi dargli i nuovi componenti, rendendoli effettivamente una nuova entità.

Si presume che i sistemi salteranno le entità che non hanno i componenti richiesti. Idealmente potresti scrivere qualcosa come questo (c ++):

class GravitySystem : public System<MassComponent, PositionComponent, VelocityComponent> {
    public:
    GravitySystem() {}

    void logic(Entity& e) {
        auto mass = e.get<MassComponent>();
        auto pos = e.get<PositionComponent>();
        auto vel = e.get<VelocityComponent>();
        vel->y += 9.81 * mass->value;
        pos->x += vel->x;
        pos->y += vel->y;
    }
};

E poi nel tuo ciclo di gioco scrivi qualcosa come gravitySystem.process(entities) , e itera su ogni entità e applica la logica su ogni entità che ha i componenti richiesti. Quindi non devi preoccuparti degli ID a meno che non ti servano per qualcos'altro. Dai un'occhiata a darkf / microecs per un esempio.

La soluzione semplice consiste nell'utilizzare un elenco gratuito e, naturalmente, rimuovere tutti i componenti quando si richiede di rimuovere un'entità. Riutilizza la memoria di un'entità come un indice per l'entità libera next quando viene rimossa dall'elenco (senza rimuoverla dall'array o spostarla in giro). Questo diagramma dovrebbe chiarire l'idea:

Esempiodicodice:

structEntity{unionData{...intnext_free;};Datadata;};structEcs{...vector<Entity>entities;intfree_entity;//setto-1initially};intEcs::insert_entity(constEntity&entity){if(free_entity!=-1){//Ifthere'safreeentityindexavailable,//popitfromthefreelistandoverwritethe//entityatthatindex.constintindex=free_entity;free_entity=entities[free_entity].data.next_free;entities[index]=entity;returnindex;}else{//Otherwiseinsertanewentity.entities.push_back(entity);returnentities.size()-1;}}voidEcs::erase_entity(intentity_index){//Pushtheentityindextothefreelist.entities[entity_index].data.next_free=free_entity;free_entity=entity_index;}

Ciòmanterràituoiindiciinvalidi,consentiràunrapidorecuperodeglispazivuotiemanterràiltuoinserimentoerimozionesporcoabassocostooperazioniatempocostanteetuttosenzacrearealcunanuovastrutturadatioqualcosadelgenere.

Ovviamenteognivoltachesidisponediunarraycon"buchi", può iniziare a sprecare memoria se ci sono molti spazi vuoti in cui il cliente ha rimosso un sacco di cose e non si è mai preso la briga di inserire qualcosa di nuovo. Un modo per mitigare quello è usare una sequenza di accesso casuale composta da blocchi contenenti, diciamo, 16 entità ciascuna. Se un blocco diventa completamente vuoto, è possibile liberare la sua memoria e sostituirla con un puntatore nullo, per essere riallocata in un secondo momento se il client vuole mai reclamare l'intervallo di indici rappresentato dal blocco precedentemente rappresentato. Questo ha lo svantaggio di un accesso casuale più lento (un po 'più aritmetico per accedere all'elemento nth ), ma fa un lavoro migliore per liberare memoria quando le persone rimuovono gli elementi da esso. È anche compatibile con l'approccio alla lista gratuita.