Entity Component System + ООП подход?

Question

[siRius32]

Не совсем понятно как писать в этом стиле, можно ли мешать с ООП. К примеру есть сущность игрок с набором компонентов наследованная от Entity, в ней методы, которые меняют данные в компонентах, эти методы вызываются в системах. Или же нет типа "типов" сущностей и брать компоненты из entity надо только в системах и там только что то делать. Про состояния, пустые компоненты добавлять удалять в entity как флаги что сущность в каком либо состоянии, и отдельные системы для обработки каждого состояния это нормальный подход ?! *

Answer 1

[Евгений Шатунов]

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

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

К примеру есть сущность игрок с набором компонентов наследованная от Entity,

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

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

Про состояния, пустые компоненты добавлять удалять в entity как флаги что сущность в каком либо состоянии, и отдельные системы для обработки каждого состояния это нормальный подход ?!

Битовые компоненты - это рядовая оптимизация для хранения пустых компонент. Да, так делают и обеспечивают правильную работу систем, чтобы фильтры компонент одинаково обрабатывали как полноразмерные компоненты, так и битовые тоже.

Comments

[siRius32]

Спасибо за ответ.
Вот пример https://github.com/aesophor/Vigilante-gdx/blob/mas...
Считаете так делать нельзя?

[Евгений Шатунов]

siRius32, да, это плохой дизайн. Java не оставляет тебе шанса в отказе от ООП, но даже в Java можно реализовать правильный подход ECS.

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

[siRius32]

Евгений Шатунов, Ну а как быть с уже готовыми решениями, которые лежат за пределами ECS, например пользовательский интерфейс, кнопки, панельки, не переписывать же это на компоненты, и вообще надо ли это, можно же внедрять в системы и пользоваться к примеру через EventManeger, и всё будет работать, значит можно все это объединять ecs+ооп, в чем могут быть сложности, это же не запрещается.

[Евгений Шатунов]

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

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

А проблема заключается в том, что ECS в любой момент должен иметь возможность распорядиться по-своему абсолютно каждой сущностью. Создать новую, удалить текущую, добавить компоненты, убрать компоненты. В этом гибкость подхода ECS. Более того, ECS изначально, как архитектура, спроектирован так, чтобы дать разработчику возможность неблокирующего массового распараллеливания симуляции мира. На все ядра сразу и сразу на 100%.
Когда ты замешиваешь ООП в ECS, часть опор архитектуры ECS рушится. В результате ты получаешь недоархитектуру, которой уже не так удобно пользоваться. Так всегда бывает с любым архитектурным шаблоном: ты не можешь пользоваться им с присущим ему удобством если сам же это удобство загубил.
Ты можешь получить внезапный удар в спину от невозможности больше удалять компоненты после их добавления. Или - невозможность оперировать жизнью компонентов после создания сущности. Или - недоступную более возможность массового распараллеливания.
Это все больно бьет по удобству использования ECS.
Это я говорю как участник двух Open Source разработок ECS библиотек и создатель трех собственных версий ECS.

[siRius32]

Евгений Шатунов, Спасибо за информацию. А то какое то гадание на кофейной гуще было. Наверное я говорю про ecs, а думаю как будто это ооп еще. По сути получается так, что без разниицы как называется сущность 'игрок' или 'ходунок', если у entity есть компонент MovableComponent, и есть система MovableSystem, то она будет двигать его. Остается еще понять как определить для чего нужна сущность, к примеру нужно ли создавать сущность для чего то типа 'состояние игры' в одном числе или 'карта'.

[Евгений Шатунов]

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

А если попробовать все-таки сформулировать такие компоненты для таких сущностей, то зачем эти компоненты сущностям фигур? И зачем сущностям поля или состояния игры компоненты фигур? Это вносит в мир ECS неоднородность, набор компонентов становится несвязным. Для одних сущностей становятся характерны только один компоненты, а для других - только другие. Получается снова недоархитектура.
Такой ECS-мир является избыточным и, вероятно, должен быть разделен на несколько ECS миров, компоненты в которых будут связными.

[siRius32]

Евгений Шатунов, получается в идеальном варианте, абсолютно любой компонент можно добавить/удалить абсолютно любой entity и система, которая использует этот компонент что то сделает, если же какой то компонент нельзя дать сущности, то что то не так значит надо пересматривать архитектуру? один непонятный момент, если пустой компонент наделяет сущность уже как бы флагом чего то, то для чего в компонент можно добавить кучу полей с информацией. можете сказать или привести пример компонента с данными в шахматах или другой игры. вот пример такого компонента https://github.com/aesophor/Vigilante-gdx/blob/mas..., можно поидеи все эти поля вынести в отдельные компоненты и отдельные системы? получется так? будет код из сотни файлов?

[siRius32]

Вообще, складывается такое ощущение, что на практике ECS удобнее использовать как каркас для игрового цикла, т.к. все системы прокручиваются в update, система может работать без сущностей, типа отрисовывать внешний ui, несколько групп систем, которые работают с определенным набором компонентов и сущностей, все это связывается через event'ы. Это представляется более как то правдоподобно в реальности и переводимо в код, нежели запутаться в абстракциях сущностей монолитной чистой EC системы. Как то так)

[Евгений Шатунов]

siRius32,

получается в идеальном варианте, абсолютно любой компонент можно добавить/удалить абсолютно любой entity и система, которая использует этот компонент что то сделает, если же какой то компонент нельзя дать сущности, то что то не так значит надо пересматривать архитектуру?

Верно. Из этого правила сами собой выводятся множественные облегчения работы систем. Система может быть просто реакционной: надо компонент добавить - добавляю безотносительно сущности и того, сколько уже компонентов добавлено.

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

Сам компонент означает некоторое свойство, которым сущность может обладать. Например, это может быть свойство мертвого персонажа. Есть компонент - персонаж мертв. Такому компоненту не нужны данные, мертв - это как бы однозначно и без оговорок.

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

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

Любая система в любой момент времени может добавить или убрать компоненты сущности. Так, например, система жизни может увидеть что после работы системы урона очков жизни больше нет, значит пора сущности умирать. В этом случае система жизни добавляет компонент умирания и больше ничего не делает.
Далее, система умирания подхватывает сущность с компонентом умирания и удаляет у нее компоненты подвижности, здоровья, атаки, магии, компонент цели атаки или навыков, а так же добавляет компонент лута и компонент смерти. После этого система умирания удаляет и компонент умирания. Все, сущность умирла и не важно что это за сущность: сундук, моб или игрок.

[Евгений Шатунов]

siRius32,

Вообще, складывается такое ощущение, что на практике ECS удобнее использовать как каркас для игрового цикла, т.к. все системы прокручиваются в update, система может работать без сущностей, типа отрисовывать внешний ui, несколько групп систем, которые работают с определенным набором компонентов и сущностей, все это связывается через event'ы.

Да, верно. Но только отчасти.
ECS - это архитектура математической модели мира. Оставь отрисовку внешней относительно ECS логике. Сущности в мире ECS могут и не рисоваться вовсе. Это могут быть точки звукового сопровождения или точки интерактива, для которых доступно лишь взаимодействие.
Плюс, всегда стоит помнить о том, что дизайн ECS заточен на неблокирующее массовое распараллеливание, когда все системы начинают обрабатывать сущности сразу на нескольких ядрах процессора. Такой параллелизм выгоден только мат.модели, но не рендеру и прочим инструментам ввода/вывода.