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

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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