Я видел большое количество разных, противоречивых предложений о том, как хранить информацию в системе Entity Component System - некоторые рекламируют «чистоту» или оптимизацию кэша, без особых объяснений. Как общее резюме:
Список объектов, которые хранят компоненты внутри своей структуры (например, какой-то unordered_map<type_info, IComponent*> в C ++). Системы отслеживают свой собственный список, в котором в настоящее время активные объекты обладают компонентами, с которыми они работают.
То же, что и 1, за исключением того, что системы выполняют глобальные итерации по всем объектам и проверяют, какие компоненты они содержат.
Существует отдельный список для каждого типа компонентов, и нет фактического сохраненного списка «сущностей» - системы перебирают свои соответствующие компоненты и должны каким-то образом находить другие связанные компоненты, которые принадлежат к той же сущности, через какой-то уникальный идентификатор, который их связывает. Хранение компонентов в списке, подобном этому, поддерживается как предположительно улучшающее локальность кэша (хотя я не понимаю, как, поскольку вы все равно будете искать в нескольких больших списках, чтобы найти связанные компоненты для конкретной сущности), и не иметь фактического ' Тип сущности предположительно является признаком «чистого» ECS.
Каждый тип компонента имеет свой собственный глобальный контейнер / список, но все еще есть список структур сущностей, которые отслеживают какие компоненты принадлежат какой-то конкретной сущности. Системы ведут себя как в 1 или 2.
Я также нашел некоторые аргументы в пользу «одного типа компонента на систему» - что упростит некоторые из проблем системы 3, но будет в целом очень мало смысла.
Так что мой вопрос - прорезать весь шум различных реализаций, является ли какой-либо из них «идеальным» или «каноническим» способом создания ECS? Довольно сложно проанализировать преимущества и недостатки каждого из этих дизайнов и их множество различных вариантов. Я обычно реализовывал их, как в '1' из моего списка выше, что оказалось удобным, но не обязательно оптимальным.