Комментарии 14
Сущности есть смысл грузить (и сохранять) в рантайме, этакая сериализации в текстовый формат (для конфигов, дерева исследований и подобных вещей которые хочется редактировать в виде текста).
А компоненты - наоборот, если уж грузить то во время компиляции/кодогенерации, потому что если грузить их в рантайме, то половина преимуществ ецс (скорость обработки за счёт фиксированной раскладки в памяти) уйдёт, да и работать с ними из компилируемого языка не выйдет.
Так что возникает вопрос - а есть ли смысл объединять одно с другим в один формат?
если грузить их в рантайме, то половина преимуществ ецс (скорость обработки за счёт фиксированной раскладки в памяти) уйдёт
Зависит от библиотеки. Есть flecs, в котором можно в рантайие определять компоненты.
работать с ними из компилируемого языка не выйдет
А как насчёт кодогенерации? ?
Но в целом согласен. Сущностям в рантайме быть. Компонентам - нихть!
Почему бы и нет? Можно сделать разные реализации, например - метапрограммирование компонентов.
да, компоненты можно считывать из файла для кодогенерации (или метапрограммированием).
Но вот сущности может быть желательно считывать уже после компиляции. Чтобы не пересобирать программу для изменения одного значения.
Получается, что нужно два парсера - один до компиляции, другой - рантаймовый. При этом они считывают непересекающиеся данные - один считывает компоненты, другой - сущности. Ну и вопрос - а есть ли смысл тогда хранить их в одном формате? Рантаймовый логично было бы в какой-нибудь xml/json запихнуть, чтоб использовать готовые библиотеки. Ну а для компонентов - да, можно и свой.
Складывается впечатление что автор перепутал ecs и компонентную архитектуру (на подобие той что используется в юнити). В ecs не используется никакого наследования и уж тем более компоненты не должны содержать внутри другие компоненты. Вы взяли ecs, но притащили за собой ровно те же проблемы из ооп от которых этот самый ecs должен был вас избавить.
Ну как вам сказать, каждый компонент НЕ содержит родителей, их содержимое складывается.
В таком случае это практически тоже самое наследование, разве нет? В любом случае, мой вам совет - уберите эти фичи. Наследование в компонентах в любом его проявлении - путь в ад. Вы упростите себе как написание парсера, так и жизнь тем, кто решит пользоваться вашим фреймворком. Вся прелесть ecs в том что у вас плоская архииектура без лишних иерархий и абстракций. Соответственно её сравнительно легко расширять и рефакторить. Зачем сознательно тащить проблемы ооп подхода - непонятно.
Это удобно в некоторых случаях.
На самом деле, формат вам не запрещает использовать наследования. Ваше дело не использовать эту фичу, но это не отменять, что она должна быть.
это конечно холиварный вопрос, но нет, этой фичи не должно быть. Если один компонент "наследуется" от другого, то надо просто вешать на сущность два - родительский и этот. Сразу получаем гибкость (когда потребуется использовать дочерний без родительского мы будем готовы) и эффективность (системы которые работают с родительским не будут забивать кеш данными дочернего).
Плоховато описана проблематика, которую пытается решить этот подход. Бойлерплейтный однотипный код при обьявлении компонентов? Ну допустим, а чем предложенный подход лучше тех же сниппетов? Пока выглядит так что вы пытаетесь заменить один бойлерплейт другим велосипедным.
Формат описания Компонентов и Префабов (Entity) для ECS. Часть 1. Спецификация