Come evitare che gli oggetti di gioco si cancellino accidentalmente in C ++

Diciamo che il mio gioco ha un mostro che può esplodere kamikaze sul giocatore. Scegliamo un nome per questo mostro a caso: un Creeper. Quindi, la Creeperclasse ha un metodo che assomiglia a questo:

void Creeper::kamikaze() {
    EventSystem::postEvent(ENTITY_DEATH, this);

    Explosion* e = new Explosion;
    e->setLocation(this->location());
    this->world->addEntity(e);
}

Gli eventi non sono in coda, vengono spediti immediatamente. Questo fa sì che l' Creeperoggetto venga eliminato da qualche parte all'interno della chiamata postEvent. Qualcosa come questo:

void World::handleEvent(int type, void* context) {
    if(type == ENTITY_DEATH){
        Entity* ent = dynamic_cast<Entity*>(context);
        removeEntity(ent);
        delete ent;
    }
}

Poiché l' Creeperoggetto viene eliminato mentre il kamikazemetodo è ancora in esecuzione, si arresta in modo anomalo quando tenta di accedere this->location().

Una soluzione è accodare gli eventi in un buffer e inviarli in un secondo momento. È quella la soluzione comune nei giochi C ++? Sembra un po 'un trucco, ma potrebbe essere solo a causa della mia esperienza con altre lingue con diverse pratiche di gestione della memoria.

In C ++, esiste una soluzione generale migliore a questo problema in cui un oggetto si elimina accidentalmente dall'interno di uno dei suoi metodi?

Non cancellare this

Anche implicitamente.

- Mai -

L'eliminazione di un oggetto mentre una delle sue funzioni membro è ancora nello stack sta implorando problemi. Qualsiasi architettura di codice che si traduca in ciò che accade ("accidentalmente" o no) è oggettivamente cattiva , è pericolosa e dovrebbe essere immediatamente riformulata . In questo caso, se al tuo mostro sarà permesso di chiamare "World :: handleEvent", non eliminare in nessun caso il mostro all'interno di quella funzione!

(In questa situazione specifica, il mio approccio abituale è di far mettere il mostro su una bandiera "morta" su se stesso e di far testare l'oggetto del mondo - o qualcosa del genere - per quella bandiera "morta" una volta per fotogramma, rimuovendo quegli oggetti dal suo elenco di oggetti nel mondo, o eliminandolo o restituendolo a un pool di mostri o qualsiasi cosa sia appropriata. In questo momento, il mondo invia anche notifiche sulla cancellazione, quindi altri oggetti nel mondo sanno che il mostro ha ha smesso di esistere e può rilasciare qualsiasi puntatore che potrebbe trattenere. Il mondo lo fa in un momento sicuro, quando sa che nessun oggetto è in fase di elaborazione, quindi non devi preoccuparti che lo stack si svolga fino a un certo punto dove il puntatore 'this' punta alla memoria liberata.)

Invece di mettere in coda gli eventi in un buffer, accodare le eliminazioni in un buffer. La cancellazione ritardata ha il potenziale per semplificare enormemente la logica; puoi effettivamente liberare memoria alla fine o all'inizio di un fotogramma quando sai che non sta accadendo nulla di interessante ai tuoi oggetti ed eliminarlo da qualsiasi luogo.

Invece di consentire al mondo di gestire l'eliminazione, è possibile consentire all'istanza di un'altra classe di fungere da bucket per archiviare tutte le entità eliminate. Questa particolare istanza dovrebbe ascoltare gli ENTITY_DEATHeventi e gestirli in modo tale da metterli in coda. L' Worldpuò quindi iterare in questi casi ed eseguire operazioni di post-morte dopo che il telaio è stato reso e 'chiaro' questo secchio, che a sua volta eseguire l'eliminazione effettiva delle istanze entità.

Un esempio di tale classe sarebbe il seguente: http://ideone.com/7Upza

Suggerirei di implementare una fabbrica utilizzata per tutte le allocazioni di oggetti di gioco nel gioco. Quindi, invece di chiamarti nuovo, diresti alla fabbrica di creare qualcosa per te.

Per esempio

Object* o = gFactory->Create("Explosion");

Ogni volta che si desidera eliminare un oggetto, la factory inserisce l'oggetto in un buffer che viene cancellato dal fotogramma successivo. La distruzione ritardata è molto importante nella maggior parte degli scenari.

Considera anche di inviare tutti i messaggi con un ritardo di un frame. Esistono solo un paio di eccezioni a cui è necessario inviare immediatamente, la stragrande maggioranza dei casi, tuttavia, è sufficiente

Puoi implementare tu stesso la memoria gestita in C ++, così che quando ENTITY_DEATHviene chiamato, tutto ciò che accade è che il numero dei suoi riferimenti viene ridotto di uno.

Successivamente, come suggerito da @John all'inizio di ogni frame, è possibile verificare quali entità sono inutili (quelle con zero riferimenti) ed eliminarle. Ad esempio puoi usare boost::shared_ptr<T>( documentato qui ) o se stai usando C ++ 11 (VC2010)std::tr1::shared_ptr<T>

Usa il pooling e non eliminare effettivamente gli oggetti. Invece, cambia la struttura dei dati in cui sono registrati. Ad esempio per il rendering di oggetti c'è un oggetto scena e tutte le entità in qualche modo registrate su di esso per il rendering, il rilevamento delle collisioni ecc. Invece di eliminare l'oggetto, staccarlo dalla scena e inserirlo in un pool di oggetti morti. Questo metodo non solo previene i problemi di memoria (come un oggetto che si elimina da solo) ma può anche velocizzare il gioco se si utilizza correttamente il pool.

Quello che abbiamo fatto in un gioco è stato utilizzare il posizionamento nuovo

SomeEvent* obj = new(eventPool.alloc()) new SomeEvent();

eventPool era solo una grande quantità di memoria che era stata ricavata e il puntatore a ciascun segmento veniva archiviato. Allocare () restituirebbe l'indirizzo di un blocco di memoria libero. Nel nostro eventPool la memoria è stata trattata come uno stack, quindi dopo che tutti gli eventi sono stati inviati, abbiamo semplicemente reimpostato il puntatore dello stack all'inizio dell'array.

A causa del modo in cui il nostro sistema di eventi ha funzionato, non abbiamo avuto bisogno di chiamare i distruttori sugli eventi. Quindi il pool registra semplicemente il blocco di memoria come libero e lo alloca.

Questo ci ha dato un'enorme velocità.

Inoltre ... Abbiamo effettivamente utilizzato i pool di memoria per tutti gli oggetti allocati dinamicamente nello sviluppo, in quanto è stato un ottimo modo per trovare perdite di memoria, se c'erano oggetti lasciati nei pool quando il gioco è uscito (normalmente), allora era probabile che ci fosse una perdita di mem.