Як уникнути ігрових об’єктів, випадково видаливши себе в C ++

Скажімо, у моїй грі є монстр, який може камікадзе вибухнути на гравці. Виберемо назву для цього монстра навмання: Creeper. Отже, у Creeperкласі є метод, який виглядає приблизно так:

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

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

Події не в черзі, вони відправляються негайно. Це призводить Creeperдо видалення об'єкта десь усередині виклику postEvent. Щось на зразок цього:

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

Оскільки Creeperоб’єкт видаляється, поки kamikazeметод все ще працює, він припинить роботу при спробі доступу this->location().

Одне з варіантів - це чергувати події в буфер і відправляти їх пізніше. Це загальне рішення в іграх на C ++? Це здається, що це трохи зламало, але це може бути просто через мій досвід роботи з іншими мовами з різними методами управління пам'яттю.

Чи є в C ++ краще загальне рішення цієї проблеми, коли об'єкт випадково видаляє себе всередині одного зі своїх методів?

Не видаляйте this

Навіть неявно.

- Колись -

Видалення об'єкта, поки одна з його функцій-членів все ще знаходиться у стеку, викликає проблеми. Будь-яка архітектура коду, яка призводить до того, що трапляється ("випадково" чи ні), об'єктивно погана , небезпечна , і її слід негайно відновити . У цьому випадку, якщо вашому монстрові буде дозволено дзвонити "Світ :: handleEvent", ні в якому разі не видаляйте монстра всередині цієї функції!

(У цій конкретній ситуації мій звичайний підхід полягає в тому, щоб монстр встановив «мертвий» прапор на себе, а об’єкт «Світ» - або щось подібне до нього - протестував цей «мертвий» прапор один раз на кадр, видаляючи ці об’єкти зі свого списку об'єктів у світі, або видалення або повернення його до пулу монстрів або будь-якого іншого. У цей час світ також надсилає сповіщення про видалення, тому інші об’єкти у світі знають, що монстр має припинила існування і може кинути на нього будь-які вказівники, які вони могли б утримувати. Світ це робить у безпечний час, коли він знає, що жоден об’єкт не обробляє в даний час, тож вам не доведеться турбуватися про те, щоб стек розгорнувся до точки де вказівник "цей" вказує на звільнену пам'ять.)

Замість того, щоб чергувати події в буфері, чергуйте видалення в буфері. Затримка-видалення може потенційно значно спростити логіку; ви можете фактично звільнити пам'ять в кінці або на початку кадру, коли вам відомо, що з вашими об’єктами нічого цікавого не відбувається, і видалити з будь-якого місця.

Замість того, щоб дозволити світу обробляти видалення, ви можете дозволити екземпляру іншого класу служити відро для зберігання всіх видалених об'єктів. Цей конкретний екземпляр повинен слухати ENTITY_DEATHподії та обробляти їх таким чином, щоб він ставив їх у чергу. Потім Worldможе повторювати ці екземпляри та виконувати післясмертові операції після того, як кадр був наданий та очистив це відро, що, в свою чергу, виконало б фактичне видалення екземплярів сутностей.

Приклад такого класу може бути таким: http://ideone.com/7Upza

Я б запропонував запровадити фабрику, яка використовується для всіх розподілів ігрових об'єктів у грі. Тож замість того, щоб називати себе новим, ви б сказали фабриці створити щось для вас.

Наприклад

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

Щоразу, коли ви хочете видалити об'єкт, фабрика штовхає об'єкт у буфер, який очищається наступним кадром. Затримка руйнування дуже важлива у більшості сценаріїв.

Також розглянути можливість надсилання всіх повідомлень із запізненням на один кадр. Є лише декілька винятків, коли вам потрібно негайно надіслати, що переважна більшість випадків, однак, просто

Ви можете самостійно реалізувати керовану пам’ять у C ++, так що при ENTITY_DEATHвиклику все, що відбувається, - кількість її посилань зменшується на одиницю.

Пізніше, як @John запропонував на початку проходження кожного кадру, ви можете перевірити, які об'єкти марні (ті, що мають нульові посилання) та видалити їх. Наприклад, ви можете використовувати boost::shared_ptr<T>( задокументовано тут ) або якщо ви використовуєте C ++ 11 (VC2010)std::tr1::shared_ptr<T>

Використовуйте об'єднання та фактично не видаляйте об'єкти. Натомість змініть структуру даних, до якої вони зареєстровані. Наприклад, для візуалізації об'єктів є об'єкт сцени, і всі об'єкти, якимось чином зареєстровані в ньому для візуалізації, виявлення зіткнень тощо. Замість видалення об'єкта від'єднайте його від місця події та вставіть у пул мертвих об’єктів. Цей метод не тільки запобігає проблемам із пам'яттю (наприклад, видалення самого об'єкта), але також може прискорити гру, якщо ви правильно використовуєте пул.

Що ми робили в грі - це використання місця розташування нове

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

eventPool був просто великим масивом пам'яті, яка була вирізана, і вказівник на кожен сегмент зберігався. Отже, alloc () повертає адресу вільного блоку пам'яті. У нашому eventPool пам'ять трактувалася як стек, тому після відправлення всіх подій ми просто скинули вказівник стека назад до початку масиву.

Через те, як працювала наша система подій, нам не потрібно було викликати деструкторів на евенах. Таким чином пул просто зареєстрував би блок пам'яті як безкоштовний і розподілив би його.

Це дало нам величезну швидкість.

Крім того ... Ми фактично використовували пули пам'яті для всіх динамічно розподілених об'єктів, що заперечуються в процесі розвитку, оскільки це був чудовий спосіб пошуку витоків пам'яті, якщо в пулах залишилися якісь об'єкти, коли гра виходила (як правило), то, швидше за все, це було пам’ятний витік.