Пройдя несколько шаблонов игрового дизайна, я выбрал Entity-Component-System (ES System) для моего игрового движка. Я читаю статьи (в основном T = Machine ) и рассматриваю некоторый исходный код, и я думаю, что получил достаточно, чтобы начать.
Есть только одна основная идея, с которой я борюсь. Как мне работать с группами объектов, которые зависят друг от друга?
Позвольте мне использовать пример:
Предположим, я делаю стандартный верхний шутер (например, Джеймстаун ) и хочу создать «босс-сущность» с несколькими различными, но соединенными частями. Разбивка может выглядеть примерно так:
- Тело корабля: движение, рендеринг
- Пушка: Положение (заблокировано относительно корпуса корабля), Отслеживание \ Огонь у героя, Получение урона до отключения
- Ядро: Положение (заблокировано относительно корпуса корабля), Отслеживание \ Огонь героя, Получение урона до отключения, Отключение (э-э ... уничтожение) всех других объектов в группе корабля.
Моей целью было бы то, что можно было бы идентифицировать (и манипулировать) в качестве отдельного игрового элемента без необходимости переписывать подсистему с нуля каждый раз, когда я хочу построить новый агрегатный элемент.
Как мне реализовать этот вид дизайна в ES System?
- Реализую ли я какие-то отношения сущности родитель-потомок (сущности могут иметь детей)? Это, кажется, противоречит методологии, согласно которой сущности являются просто пустым контейнером, и заставляет их чувствовать себя более ООП.
- Реализую ли я их как отдельные сущности, с каким-то связующим компонентом (BossComponent) и связанной системой (BossSubSystem)? Я не могу не думать, что это будет сложно реализовать, поскольку взаимодействие компонентов кажется большой медвежьей ловушкой.
- Реализую ли я их как один объект с набором компонентов (ShipComponent, CannonComponents, CoreComponent)? Похоже, что это отклоняется от намерения системы ES (компоненты здесь кажутся слишком похожими на объекты с большим весом), но я знаю об этом, поэтому я решил, что я это изложу.
- Я реализую их как что-то еще, что я упомянул?
Я знаю, что это очень легко реализовать в ООП, но я остановлюсь на выборе ES вместо ООП. Если мне потребуется порвать с чистой теорией ES для реализации этого дизайна, я сделаю это (не то чтобы раньше мне не приходилось ставить под угрозу чистый дизайн), но я бы предпочел сделать это по соображениям производительности, а не начинать с плохого дизайна.
Для дополнительного кредита, подумайте о том же дизайне, но каждая из «сущностей босса» фактически была связана с более крупной «сущностью BigBoss», состоящей из основного корпуса, основного ядра и 3 «боссовых сущностей». Это позволило бы мне увидеть решение по крайней мере для 3 измерений (дедушка-родитель-ребенок) ... которого должно быть более чем достаточно для меня.