Комментарии 9
Как решаете проблему иерархий в ECS UI?
Используете ли что то вроде компонента relationship как в https://skypjack.github.io/2019-06-25-ecs-baf-part-4/ ?
нет, мы не используем компоненту для этого. У нас у сущности есть поле parent всегда. Это указатель на родительскую сущность. У корня он равен nullptr
у нас было что-то похожее на архетипы ранее. Благодаря этому у нас была очень долгая вставка компонент, но константное получение их при этом. Мы заменили на среднюю сложность вставки и среднюю сложность получения и суммарно выиграли от этого. Насчет cache-friendly вопрос слишком абстрактен. Поле parent всегда указывает на валидную сущность, либо равно нулю.
Поддерживаю, как это устроено? Видеть в рантайм коде перебор Conlrol'ов и запросы GetComponent на каждой итерации в контексте ECS выглядит очень странно по мне. Чем тогда это отличается от какого-нибудь сцен-графа с компонентой моделью, например?
не совсем понимаю сравнение сцен-графа и ECS. Сцена-граф это структура данных, а ECS это более, чем просто структура данных — в ECS есть динамика, то есть, системы. А в целом именно пассивная часть да похожа на сцена-граф у нас.
ECS, это прежде всего дата-ориентированный дизайн. Системы в ECS обрабатывают данные т.е. компоненты, а не сущности (Control). Ни каких переборов сущностей и запросов GetComponent там быть не должно, тем более проверок в цикле наличия компонент. Другая идеология. Собственно вопрос локальности обрабатываемых данных здесь принципиален и именно эту задачу, должна решать ECS. Процессинг, который вы привели в листинге, имеет объектно-ориентированный дизайн. Без какого-либо контекста, ровно такой же метод будет в случае со сцен-графом или другой подобной структурой с навешанными на узлы компонентами (компонентной моделью) и мы также будем итерироваться по этим узлам (Control'ам), запрашивать у узла нужны компонент и выполнять какие-то действия.
ECS в UI в клиенте World of Tanks Blitz