Система компонентов сущности

Эта статья написана как личное размышление, личное эссе или аргументированное эссе , в котором излагаются личные чувства редактора Википедии или представлены оригинальные аргументы по теме. Пожалуйста, помогите улучшить его , переписав в энциклопедическом стиле . ( Октябрь 2013 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

Сущность – компонент – система ( ECS ) - это шаблон архитектуры программного обеспечения, который в основном используется при разработке видеоигр . ECS следует принципу композиции, а не наследования, что означает, что каждая сущность определяется не присвоенным ей «типом», а именованными наборами данных, называемыми «компонентами», которые с ней связаны, что обеспечивает большую гибкость. В ECS процессы, называемые «системами», определяют, какие объекты имеют определенные желаемые компоненты, и воздействуют на все эти объекты, используя информацию, содержащуюся в компонентах. Например, физическая система может запрашивать объекты, имеющие компоненты массы, скорости и положения, а затем перебирать их все и выполнять физические вычисления. Таким образом, поведение объекта может быть изменено во время выполнения системами, которые добавляют, удаляют или изменяют компоненты. Это устраняет проблемы неоднозначности глубоких и широких иерархий наследования, которые трудно понять, поддерживать и расширять. Общие подходы ECS очень совместимы,и часто сочетаются сметоды проектирования, ориентированные на данные . Хотя объект связан со своими компонентами, эти компоненты обычно не обязательно хранятся рядом друг с другом в физической памяти. Примечательно, что ECS напоминает структуру баз данных и, как таковая, может называться базой данных в памяти .

История

В 2007 году команда, работающая над Operation Flashpoint: Dragon Rising, экспериментировала с проектами ECS, в том числе вдохновленными Bilas / Dungeon Siege , а Адам Мартин позже написал подробный отчет о дизайне ECS, ^[1] включая определения основных терминов и концепций. ^[2] В частности, работа Мартина популяризировала идеи «систем» как первоклассного элемента, «сущностей как идентификаторов», «компонентов как необработанных данных» и «кода, хранящегося в системах, а не в компонентах или сущностях».

В 2015 году Apple Inc. представила GameplayKit , платформу API для разработки игр для iOS , macOS и tvOS, которая включает реализацию ECS. Хотя он не зависит от графического движка, используемого для рендеринга игры, он включает удобную поддержку интеграции с Apple SpriteKit , SceneKit и Xcode Scene Editor. ^[3]

В августе 2018 года Сандер Мертенс создал популярный фреймворк ECS под названием « flecs ». ^[4]

В октябре 2018 года ^[5] компания Unity выпустила свою знаменитую демонстрацию в мегаполисе, в которой использовался технологический стек, построенный на ECS. У него было 100000 источников звука, по одному на каждую машину, каждую неоновую вывеску и многое другое, создавая огромный и сложный звуковой ландшафт. ^[5]

Характеристики

Используемая сегодня терминология Мартина ^[2] :

• Сущность: Сущность - это объект общего назначения. Обычно он состоит только из уникального идентификатора. Они «помечают каждый грубый игровой объект как отдельный элемент». Реализации обычно используют для этого простое целое число. ^[6]
• Компонент: необработанные данные для одного аспекта объекта и того, как он взаимодействует с миром. «Обозначает Сущность как обладающую этим конкретным аспектом». Реализации обычно используют структуры, классы или ассоциативные массивы. ^[6]
• Система: «Каждая Система работает непрерывно (как если бы каждая Система имела свой собственный частный поток) и выполняет глобальные действия с каждой Сущностью, имеющей Компонент или Компоненты, соответствующие этому Системному запросу».

Допустим, есть функция рисования. Это будет «Система», которая выполняет итерацию по всем объектам, имеющим как физический, так и видимый компонент, и рисует их. Видимый компонент обычно может содержать некоторую информацию о том, как должен выглядеть объект (например, человек, монстр, летящие искры, летящая стрела), и использовать физический компонент, чтобы знать, где его нарисовать. Другой системой может быть обнаружение столкновений. Он будет перебирать все сущности, у которых есть физический компонент, так как не будет заботиться о том, как отрисовывается сущность. Затем эта система могла бы, например, обнаруживать стрелы, которые сталкиваются с монстрами, и генерировать событие, когда это происходит. Ему не нужно понимать, что такое стрелка и что она означает, когда стрелка поражает другой объект. Еще одним компонентом могут быть данные о состоянии здоровья и система, которая управляет здоровьем.Компоненты здоровья будут прикреплены к сущностям человека и монстра, но не к сущностям стрелы. Система управления работоспособностью подпишется на событие, сгенерированное в результате столкновений, и соответственно обновит работоспособность. Эта система также может периодически перебирать все сущности с компонентом здоровья и восстанавливать здоровье.

Сущность состоит только из идентификатора для доступа к компонентам. Идея состоит в том, чтобы внутри компонентов не было игрового кода (поведения). Компоненты не обязательно должны физически располагаться вместе с объектом, но должны быть легко найдены и доступны с помощью объекта. Обычной практикой является использование уникального идентификатора для каждой сущности. Это не является обязательным требованием, но у него есть несколько преимуществ:

• На объект можно ссылаться с использованием идентификатора вместо указателя. Это более надежно, так как позволяет уничтожить объект, не оставляя висячих указателей.
• Это помогает сохранить состояние извне. Когда состояние загружается снова, нет необходимости восстанавливать указатели.
• При необходимости данные можно перемещать в памяти.
• Идентификаторы объектов могут использоваться при обмене данными по сети для уникальной идентификации объекта.

Некоторые из этих преимуществ также могут быть достигнуты с помощью интеллектуальных указателей .

Обычный способ передачи данных между системами - хранить данные в компонентах, а затем каждая система последовательно обращается к компоненту. Например, положение объекта можно регулярно обновлять. Затем эта позиция используется другими системами. Если существует много разных нечастых событий, потребуется много «флагов» в одном или нескольких компонентах. Затем системам придется отслеживать эти «флаги» на каждой итерации, что может стать неэффективным. Решением может быть использование шаблона наблюдателя . Все системы, зависящие от события, подписываются на него. Таким образом, действие из события будет выполнено только один раз, когда оно произойдет, и опрос не потребуется.

Архитектура ECS обрабатывает зависимости очень простым и безопасным способом. Поскольку компоненты представляют собой простые корзины данных, у них нет зависимостей. Каждая система обычно запрашивает компоненты, которые должна иметь сущность, чтобы система могла с ней работать. Например, система рендеринга может зарегистрировать компоненты модели, преобразования и рисования. Затем он проверит каждую сущность на предмет этих компонентов, и если у сущности есть все они, система выполнит свою логику для этой сущности. В противном случае сущность просто пропускается, и нет необходимости в сложных деревьях зависимостей. Однако это может быть местом, где ошибки могут быть скрыты, поскольку распространение значений из одной системы в другую через компоненты может быть очень трудным для отладки. ECS может использоваться, когда несвязанные данные должны быть привязаны к заданному времени жизни.

В архитектуре ECS используется композиция, а не деревья наследования. Сущность обычно состоит из идентификатора и списка связанных с ней компонентов. Любой тип игрового объекта может быть создан путем добавления правильных компонентов к сущности. Это также может позволить разработчику легко добавлять функции одного типа объекта к другому без каких-либо проблем с зависимостями. Например, к объекту игрока может быть добавлен компонент «пуля», и тогда он будет соответствовать требованиям для манипулирования некоторой системой «bulletHandler», что может привести к тому, что этот игрок нанесет ущерб вещам, столкнувшись с ними.

В оригинальном выступлении на GDC ^[7] Скотт Билас сравнивает объектную систему C ++ и свою новую систему пользовательских компонентов. Это согласуется с традиционным использованием этого термина в общей системной инженерии с помощью объектной системы Common Lisp и системы типов в качестве примеров. Поэтому идеи «Систем» как первоклассного элемента - это эссе личного мнения. В целом, ECS - это смешанное личное отражение ортогональных устоявшихся идей в общей информатике и теории языков программирования . Например, компоненты можно рассматривать как идиому миксинов в различных языках программирования. В качестве альтернативы, компоненты - это всего лишь небольшой корпус под общимделегирование (объектно-ориентированное программирование) подход и метаобъектный протокол . Т.е. любая законченная компонентная объектная система может быть выражена с помощью шаблонов и модели эмпатии в рамках концепции объектно-ориентированного программирования , изложенной в Договоре Орландо ^[8] ,

Смотрите также

• Модель – представление – контроллер
• Образец наблюдателя
• Шаблон стратегии
• Реляционная модель

использованная литература

внешние ссылки

• Анатомия нокаута
• Развивайте свою иерархию
• Вики Сообщества
• Компонент - шаблоны игрового программирования
• Дизайн ECS для достижения истинной инверсии управления потоком