Компонент на основе игрового движка: как управлять отношениями между игровыми объектами?

В компонентном игровом движке у меня есть проблемы, когда дело доходит до отношения между игровыми объектами / компонентами.

Где хранить связи и как их удалять?

Для простоты приведем пример.

Игра-клон Gradius состоит из 2 типов игровых объектов:-

  1. Ракета = Компонент Основного Корпуса + Компонент Башни
  2. Плавающая револьверная головка = компонент револьверной головки (отдельно)

Деталь компонента :-

  1. Компонент основного тела = одно физическое тело + одно графическое тело
  2. Компонент револьвера = одно физическое тело + одно графическое тело

Компонент башенки конструирован для того чтобы иметь отношение (физическое ограничение или владение) с к компоненту основного корпуса .

Существует требование, что связь должна быть удалена перед обоими компонентами.

  • Например, отношение в этом случае также содержит физическое ограничение, реализуемое внешней физической библиотекой, например, физикой пули.

Это вполне конкретное описание, приведенное на всякий случай ….

Шаги для удаления Rocket должны быть в этом порядке :-

  1. удалить ограничение
  2. удалить компонент основного корпуса и компонент револьвера (любой заказ в порядке)

Отношение также должно быть удалено, когда компонент основного корпуса удаляется, оставляя компонент башни в покое, поэтому пусть он станет плавающей башней .

Где должно храниться отношение? (Все кажется в порядке, но связано со следующим вопросом.)

  1. внутри нового компонента в новом выделенном игровом объекте (new entity)
  2. внутри нового компонента в той же сущности, что и Rocket
  3. внутри новой системы диспетчера, которые хранят список этого конкретного вида отношений

Как удалить связь? (Обе идеи кажутся плохими.)

  1. создайте флаг для проверки на предстоящее удаление компонента основного тела или ракеты, затем вызовите новую выделенную систему для удаления связи непосредственно перед удалением других компонентов, он должен вызываться перед другими системами диспетчера каждый раз.

  2. let’s other existing manager call a new dedicated system when it want to delete Main Body Component or Rocket

Я ожидал ответов для общих случаев, когда существует много типов отношений. (между игровыми объектами или компонентами)

Edit 1: предлагаемое решение о создании владения и добавлении кода непосредственно в деструктор ракеты полностью противоречит компонентной основе.

  • Это сделает три компонента (включая ограничение) очень парой.
  • Кроме того, компоненты не должны иметь нетривиальной функции.
    Я считаю, что разрушитель является одним из них, этого следует избегать.
    (У меня когда-то был раздутый деструктор некоторых объектов, он уничтожает все хорошие модульности.)

1 ответ

  1. В вашем примере ракетного игрового объекта отношение является собственностью и должно храниться в ракете. Если это позволяет архитектура игрового движка, связь может быть удалена функцией деструктора в игровых объектах, вызываемых системой диспетчера до их удаления.

    Редактировать:
    Если вы не хотите, чтобы объекты или компоненты имели какие-либо знания об их собственности или отношениях, я думаю, что лучшим выбором было бы сохранить список ( как вы предложили) отношения со ссылкой на владельца отношения. Таким образом, вы можете сначала проверить список, чтобы увидеть, если ваш игровой объект (ракета) может быть удален или если у него есть какие-либо отношения/s, чтобы удалить сначала.