Eugene
> Я свой игровой EnTT код на урховские компоненты вообще переписать не смогу (без кучи ручной копипасты и боли), он на них тупо не ложится.
Немного разверну пример.
Вот у меня есть три разные игровые системы, которые делают разные вещи, читают данные, пишут данные.
Одна работает только с объектами, у которых есть компоненты А, Б, В.
Вторая работает только с объектами, у которых есть компоненты А, Б, Г.
Третья работает только с объектами, у которых есть компоненты Б, В, Г.
Вопрос знатокам — как мне переписать эти три системы на урховские компоненты, без использования костылей в виде ручных массивов и трекинга?
В EnTT это просто три цикла в трех разных функциях, проще некуда.
1vanK
> А тебе не надо такой фильтрацией в Урхо заниматься, ты на ноду вещаешь логику, которая ожидает, что у ноды есть все нужные компоненты
Именно.
Иными словами, если бы я был вынужден переписать свой код на Урхо компоненты, мне бы пришлось, во первых, добавить еще три новых типа компонентов, АБВ-компонент, АБГ-компонент и БВГ-компонент, которые каждые бы делали работу первой, второй и третьей системы в своих LogicComponent::Update-ах.
А если бы мои циклы имели какое-то состояние и обрабатывали разные объекты не-независимо, то мне бы еще пришлось добавить АБВ-систему, АБГ-систему и БВГ-систему, которые бы трекали каждый свой компонент и делали тот же самый цикл, который в EnTT делается одной строкой.
> У тебя пример максимально синтетический, ты например имеешь функцию создать_пулю(), которая создаёт все нужные компоненты на ноде и тебе не надо проверять, что у ноды еще ноги есть
Так моя система должна работать не с одним типом объекта, а со всеми возможными объектами, для которых эта система имеет смысл.
Ты же предлагаешь каждую систему докладывать прям в объект при создании. "Вот пуля, ее должны работать вот эти три системы, а вот эти пять систем — не должны".
1vanK
> Хотя с drawable плохой пример, в котором ecs обострется еще сильнее, когда их надо хранить в октодереве
Не все хранят в octree, некоторые строят R-tree каждый кадр.
1vanK
> У тебя они и так есть, ты же пишешь конкретную функцию, которая хочет конкретные компоненты
Я имел в виду, что в урхе эти три системы будут лежать вместе с объектами в общем дереве, поэтому их самих придется сделать компонентами, технически.
А сейчас оно существует отдельно и компонентом ни в каком смысле не является (ему и не нужно).
1vanK
> Я не понимаю, с примером будет понятнее
Я попытался быстро найти пример, но у меня в коде есть же еще целый пласт сложности с тем, что база EnTT хранит в себе все объекты (я ожидаю >=100к), а сцена — только те, что рядом с игроком (порядка 100-5000). В сцене Урхи я бы вообще никак не смог повторить это в лоб "как есть", пришлось бы какой-то другой подход делать. Поэтому мне сложно найти какие-то "чистые" примеры, которые не были бы дополнительно усложнены логикой, которая не относится к теме, которая сейчас тут обсуждается.
Во Flecs ecs есть встроенная иерархия
Проектировать на ecs ад еще тот, или это из за неопытности
1vanK
> а если ты не знаешь сколько?
Если ты знаешь, что ты хочешь хранить насколько компонентов, почему ты не хранишь их массив? В этом функция динамических массивов — хранить несколько объектов в одном месте.
1vanK
> Типа создать компонент с вектором структур? Ну тогда эти структуры не будут фильтроваться как остальные компоненты ecs и нафига мне этот ecs тогда?
У тебя будет фильтроваться компонент "вектор структур", и ты сможешь делать с этими структурами все, что захочешь. Да, будет два цикла вместо одного — но я не вижу в этом какой-то проблемы.
Можешь привести пример задачи, в которой что-то не работает?
1vanK
> Ну вообще автор entt не рекомендует использовать динамическое выделение вообще (это не на твой вопрос ответ, просто инфа) https://skypjack.github.io/2019-06-25-ecs-baf-part-4/
Я часто использую мелкие вектора для таких случаев.
Например, четыре пушки без выделения памяти, а больше мне и не надо, а если вдруг понадобится два раза за игру пять пушек, то пофиг на эти два выделения памяти.
У меня довольно много коллекций внутри компонентов, строки те же, но выделять память на каждую не хочется.
1vanK
Я не делал сам, только доклады смотрел, и судя по докладам делается же примерно так:
- Есть компонент с локальной трансформацией
- Есть компонент с глобальной трансформацией
- Есть комопнент с указанием родительского entity
- Есть система которая пересчитывает глобальную трансформацию из локальных
- Системы, которые читают глобальную трансформацию выполняются после системы пересчёта
- Системы, которые двигают объекты обновляют локальные трансформации и выполняются до
1vanK
> Eugene а у тебя как компоненты и системы по файлам раскиданы?
В одном файле держу каждую систему, и компоненты за которые она отвечает.
Системы конечно работают с компонентами друг друга, но (почти?) всегда есть "главная" система для каждого компонента, без которой этот компонент вообще не работает адекватно.
Например,
BehaviorManager - Behavior,
BuildingManager - Building,BuildingTemplate,
EntityLoader - PreLoaded,InTile,TileAssignmentPending
HitProcessor - HitAffinity,HitParent,HitInvoker,HitCollection
ну и так далее
И как бы вы отсортировали 10 миллионов объектов по дистанции на ECS?
Сама по себе ECS особо скорости не даёт, нужны мозги которые будут мыслить в рамках её..
Не знаю правильно ли но большая часть статей про ECS упирается в основном в способ хранения данных.
В каком режиме работает урховский UI? Сохраненный или немедленный?