Войти
Сущность – компонент – система (ECS ) - это архитектура паттерн, который в основном используется при разработке игр. ECS следует принципу композиции над наследованием, который обеспечивает большую гибкость при определении сущностей, где каждый объект в игровой сцене является сущностью (например, враги, пули, транспортные средства и т. Д.). Каждый объект состоит из одного или нескольких компонентов, которые содержат данные или состояние. Следовательно, поведение объекта может быть изменено во время выполнения системами, которые добавляют, удаляют или изменяют компоненты. Это устраняет проблемы неоднозначности глубоких и широких иерархий наследования, которые трудно понять, поддерживать и расширять. Общие подходы ECS очень совместимы и часто сочетаются с методами ориентированного на данные проектирования.
В 2007 году команда работала над Operation Flashpoint: Dragon Rising экспериментировали с проектами ECS, в том числе вдохновленными Bilas / Dungeon Siege, а Адам Мартин позже написал подробный отчет о дизайне ECS, включая определения основных терминов и концепций. В частности, работа Мартина популяризировала идеи «систем» как первоклассного элемента, «сущностей как идентификаторов», «компонентов как необработанных данных» и «кода, хранящегося в системах, а не в компонентах или сущностях».
В 2015 году Apple Inc. представила среду API для iOS, macOS и tvOS. разработка игр, включающая реализацию ECS. Хотя он не зависит от графического движка, используемого для рендеринга игры, он включает удобную поддержку интеграции с Apple, SceneKit и Xcode Scene Editor.
В 2019 году, Представлено Unity.
Терминология Мартина, широко используемая сегодня:
Предположим, есть функция рисования. Это будет «Система», которая перебирает все объекты, которые имеют как физический, так и видимый компонент, и рисует их. Видимый компонент обычно может иметь некоторую информацию о том, как должен выглядеть объект (например, человек, монстр, летящие искры, летящая стрела), и использовать физический компонент, чтобы знать, где его нарисовать. Другой системой может быть обнаружение столкновений. Он будет перебирать все сущности, у которых есть физический компонент, так как не заботится о том, как отрисовывается сущность. Затем эта система могла бы, например, обнаруживать стрелы, которые сталкиваются с монстрами, и генерировать событие, когда это происходит. Ему не нужно понимать, что такое стрелка и что она означает, когда стрелка поражает другой объект. Еще одним компонентом могут быть данные о здоровье и система, которая управляет здоровьем. Компоненты здоровья будут прикреплены к сущностям человека и монстра, но не к сущностям стрелы. Система управления работоспособностью подпишется на событие, созданное в результате столкновений, и соответственно обновит работоспособность. Эта система также может время от времени перебирать все сущности с компонентом здоровья и восстанавливать здоровье.
Сущность состоит только из идентификатора и контейнера компонентов. Идея состоит в том, чтобы в сущности не было встроенных игровых методов. Контейнер не обязательно должен физически располагаться вместе с объектом, но его должно быть легко найти и получить к нему доступ. Обычной практикой является использование уникального идентификатора для каждой сущности. Это не является обязательным требованием, но у него есть несколько преимуществ:
Некоторые из этих преимуществ также могут быть достигнуты с помощью интеллектуальных указателей.
Обычный способ отправки данных между системами - хранить данные в компонентах. Например, положение объекта можно регулярно обновлять. Затем эта позиция используется другими системами. Если существует много разных нечастых событий, потребуется много флагов в одном или нескольких компонентах. Затем системам придется отслеживать эти флаги на каждой итерации, что может стать неэффективным. Решением может быть использование шаблона наблюдателя . Все системы, зависящие от события, подписываются на него. Таким образом, действие из события будет выполнено только один раз, когда оно произойдет, и опрос не потребуется.
В наивных реализациях ECS каждая система просматривает полный список всех сущностей и выбирает только те сущности, которые необходимы. Общая стоимость итерации для всех систем становится слишком высокой, если количество систем растет или количество объектов велико. В других архитектурах ECS каждый тип компонента хранится в отдельном списке, поэтому любые системы, работающие с данным типом компонентов, по умолчанию выполняют итерацию только по объектам, которые им важны. В этой общей архитектуре ECS описанный недостаток фактически становится основным преимуществом в производительности за счет более эффективного использования кэшей инструкций и данных ЦП. Однако другие ECS основаны на архетипах: все сущности с одним и тем же набором компонентов хранятся в одном списке. Это приводит к более быстрой итерации, но требует дополнительных затрат при добавлении компонентов в сущности или их удалении.
Архитектура ECS обрабатывает зависимости очень безопасным и простым способом. Поскольку компоненты представляют собой простые корзины данных, у них нет зависимостей. Каждая система обычно регистрирует компоненты, которые должен иметь объект, чтобы система могла с ним работать. Например, система рендеринга может зарегистрировать компоненты модели, преобразования и рисования. Затем он проверит каждую сущность на наличие этих компонентов, и если у сущности есть все они, система выполнит свою логику для этой сущности. В противном случае сущность просто пропускается, и нет необходимости в сложных деревьях зависимостей. Однако это может быть место для скрытия ошибок, поскольку распространение значений из одной системы в другую через компоненты может быть очень сложно отладить. ECS может использоваться там, где несвязанные данные должны быть привязаны к заданному времени жизни.
В архитектуре ECS используется композиция, а не деревья наследования. Сущность обычно состоит из идентификатора и списка связанных с ней компонентов. Любой тип игрового объекта может быть создан путем добавления правильных компонентов к сущности. Это также может позволить разработчику легко добавлять функции одного типа объекта к другому без каких-либо проблем с зависимостями. Например, к объекту игрока может быть добавлен компонент «пуля», и тогда он будет соответствовать требованиям, чтобы им манипулировала некоторая система «bulletHandler», что может привести к тому, что этот игрок нанесет урон вещам, столкнувшись с ними.
