ECS, ориентированный на данные: владение и обход до выбора архитектурных ярлыков

Начните с работы

Архитектура entity-component-system полезна, когда упрощает организацию данных и обработки игры. Само название не обещает ни скорости, ни простоты. Начните с часто выполняемой операции: определите читаемые и записываемые поля и сущности, которым она действительно нужна.

Идентичность, данные и системы

Сущности обеспечивают идентичность, компоненты связывают с ними данные, а системы работают с выбранными комбинациями компонентов. Flecs описывает эти роли и системы на основе запросов. [1] Архетипное хранение группирует одинаковые наборы компонентов; Unity Entities размещает их в чанках, а структурные изменения могут перемещать сущности между группами. [2] Другие стратегии ECS имеют иные компромиссы.

Разобранный пример

Рассмотрим условное обновление 20000 движущихся искр. Каждой нужны трёхкомпонентные позиция и скорость, где компонент представлен float размером 4-byte. Полезные данные движения составляют 20000 × 6 × 4 = 480000 bytes.

Гипотетическая монолитная запись по 128 bytes на искру заняла бы 2560000 bytes, включая посторонние поля. Расчёт объёма не доказывает фактический трафик кеша или ускорение: важны выравнивание, заполнители, заполненность чанков и доступы. Он мотивирует проверить, может ли горячий цикл обходить компактные массивы Position и Velocity без переходов по указателям отдельных объектов.

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

Практический процесс

Опишите чтение и запись систем до планирования параллельной работы. Двум системам, записывающим один компонент, нужны порядок или безопасное разделение. Стабильные дескрипторы сущностей должны переживать перемещения хранения; сохранённые адреса компонентов могут не пережить. Укажите моменты обновления запросов и ссылок.

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

Компромиссы и проверка

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

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

Источники

[1] Быстрый старт Flecs — Sander Mertens и участники Flecs.

[2] Понятие архетипов — Документация Unity Entities.