Обработка событий в компонентном проектировании игрового движка

Question

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

Я изучал игровой движокпроектирует и наткнулся на компонентную модель объекта.Это звучит многообещающе, но я все еще работаю над ее реализацией.

Я рассматриваю систему, в которой движок состоит из нескольких «подсистем», которые управляют некоторыми аспектами, такими как рендеринг, звук, здоровье, AIи т. д. Каждая подсистема имеет связанный с ней тип компонента, например компонент работоспособности для подсистемы работоспособности.«Сущность», например, NPC, дверь, какой-то визуальный эффект или игрок, просто состоит из одного или нескольких компонентов, которые, когда они вместе дают сущности ее функциональность.

Я определил четыре основных каналапередачи информации: компонент может передавать все компоненты в своем текущем объекте, компонент может передавать свою подсистему, подсистема может передавать свои компоненты, а подсистема может передавать другие подсистемы.

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

Все это дляНажатие клавиш кажется немного запутанным, и я, безусловно, открыт для улучшений этой архитектуры.Но в любом случае, мой главный вопрос все еще остается в силе.

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

Шаблон посетителя почти работает.Однако для этого потребуется наличие виртуальных функций для каждого типа компонента (например, visitHealthComponent, visitPositionComponent и т. Д.), Даже если он не имеет к ним никакого отношения.Я мог бы оставить эти функции пустыми (поэтому, если бы они встречались с этими компонентами, это было бы проигнорировано), но мне пришлось бы добавлять другую функцию каждый раз, когда я добавляю компонент.

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

Итак, два моих вопроса:

1. Есть ли какие-либо улучшения в моем дизайне?может позволить, с точки зрения эффективности, гибкости и т. д.?
2. Каков оптимальный способ обработки событий?

Answer 1

Извините за плохой английский.

Я пишу гибкий и масштабируемый java 3d игровой движок, основанный на Entity-Component System.Я закончил некоторые основные части этого.

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

В части обработки событий, я думаю, базовая обработка ввода не должна быть включена в ECS.Вместо этого у меня есть система с названием Intent System и компонент с именем Intent Component, который содержит много намерений.Намерение означает, что объект хочет что-то сделать с ним.Система намерений обрабатывает все намерения. Когда она обрабатывает намерение, она передает соответствующую информацию другим системам или добавляет другие компоненты к объекту.

Я также пишу интерфейс, называемый Генератором намерений.В локальной игре вы можете реализовать Keyboard Input или Mouse Input Generator, а в многопользовательской игре вы можете реализовать сетевой генератор намерений.В системе ИИ вы также можете генерировать намерения.

Вы можете подумать, что Система намерений обрабатывает слишком много вещей в игре.Но на самом деле, он разделяет многие обработки на другие системы, и я также пишу Script System.Для конкретной особой сущности у него есть компонент сценария, выполняющий особые вещи.

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

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

Answer 2

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

http://martinfowler.com/eaaDev/EventAggregator.html http://stackoverflow.com/questions/2343980/event-aggregator-implementation-sample-best-practices

и т.д.

Answer 3

эта архитектура описана здесь http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf Я столкнулся, по крайней мере, с тремя проблемами при реализации этого в реальном проекте:

1. системы не уведомляются, когда что-то происходит - единственный способ -спросите об этом - игрок мертв?стена не видна?и так далее - чтобы избежать этого, вы можете использовать простой MVC вместо шаблона наблюдателя.
2. что если ваш объект является композитным (т.е. состоит из объектов)?Система пересекает всю иерархию и спрашивает о состоянии компонента.
3. И главный недостаток заключается в том, что эта архитектура смешивает все вместе - например, почему игрок должен знать, что вы нажали клавишу?

я думаю, что ответом является многоуровневая архитектура с абстрактным представлением ...

Answer 4

Я думал об использовании систем сущностей для одного из моих собственных проектов и прошел через аналогичный мыслительный процесс. Сначала я думал использовать шаблон Observer для работы с событиями - я тоже изначально рассматривал какой-то шаблон посетителей, но решил отказаться от него по тем же причинам, что и вы.

Я думаю, что подсистемы будут обеспечивать специфический для подсистемы интерфейс публикации / подписки, и, таким образом, зависимости подсистем будут разрешаться в "слабо" связанной форме. Любая подсистема, которая зависит от событий из другой подсистемы, будет знать интерфейс абонента к этой подсистеме и, таким образом, сможет эффективно использовать ее.

К сожалению, то, как эти подписчики получают ручку своим издателям, все еще остается проблемой. На данный момент я предпочитаю какое-то динамическое создание, где создается каждая подсистема, а затем используется вторая фаза для разрешения зависимостей и перевода всех подсистем в «состояние готовности».

В любом случае, мне очень интересно, что сработало для вас и какие проблемы вы столкнулись в вашем проекте:)