Ecs что это такое
Улучшаем ваш Unity проект. Гайд по ECS для MonoBehavior разработчиков
Пару лет назад компания Unity представила свой стек DOTS, на котором и построен проект Megacity. Это некий список технологий, которые в совокупности позволяют колдовать и ускорять ваш проект в десятки раз. В корне всей магии лежат 2 простых заклинания:
Если правильно управлять данными, процессору будет легче их обрабатывать, а если их легче будет обрабатывать, то игрокам будет легче жить.
Для того, чтобы Unity программистам удалось осуществить вышеописанные постулаты, компания выпустила дополнительные пакеты:
Дары смерти от Unity Technologies
А сердцем DOTS является:
На текущий момент DOTS выглядит скорее проклятьем Unity Technologies, чем волшебной палочкой. Стек до сих пор не вышел в официальный релиз. И неизвестно когда DOTS выйдет в официальный релиз. Сейчас это крайне нестабильная штука, которую точно не стоит использовать в Production проекте.
Поэтому, давайте попробуем применить подход Entity Component System (ECS) в своем проекте.
Производительность! Бесплатно и без регистрации
Из чего состоит ECS?
Рецепт ECS под соусом Leo
Поиск Гугл по рецептам приводит нас к самому вкусному результату:
Помимо этого, на данный момент Leo ECS самый популярный ECS фреймворк после Entitas
Другие ECS рецепты, которые могут вас заинтересовать
Вот мы и определились. Чистый C# и соус Leo.
ОБНОВЛЕНО! Насколько увеличится скорость?
Я провел классический эксперимент, создал 100 000 GameObject и двигал их по вектору Z на 0.1 значение.
Как видно из этих тестов, переход на ECS подарил в районе 20 FPS. Однако точно такой же тест от коллеги по цеху, запущенный на моем устройстве, демонстрирует увеличение производительности в 3 раза. Мне же не удалось достичь таких результатов.
Leo ECS еще один тест
После тщательного анализа исходного кода моего коллеги, я так и не нашел причины за счёт чего ему удалось увеличить скорость работы. Есть ощущение, что пакеты от DOTS, установленные на моей сборке, как-то замедляли весь процесс тестирования.
Нагрузка Update методов из Profiler
Однако я попробовал вынести работу в многопоток через Job System и получил буст производительности в 5-6 раз. При этом добавление атрибута от Burst никак не увеличила производительность. Видимо в моем коде нет как таковой логики чтобы ее Burstить.
Leo ECS + Job System
Превращаем GameObject в Entity
Если Leo ECS по умолчанию не конвертирует игровые объекты из Unity Engine, то как интегрировать его с этим движком? Можно ли как-нибудь очень-очень легко превращать наши игровые объекты в Entity, чтобы процесс готовки был простым и понятным.
UniLeo автоматически конвертирует ваши игровые объекты в Entity и позволяет настраивать компоненты прямо из инспектора.
Перейдем наконец-то к коду
Подключаем пакеты через Unity Package Manager
Добавьте ссылку в Packages/manifest.json
Не забываем пространство имен
То есть, если в проекте нужно управлять физикой, необходимо создать компонент с переменной RigidBody. Таким образом можно управлять абсолютно любым элементом игрового движка Unity.
Но в UniLeo можно создать класс-проводник, который должен наследоваться MonoProvider и его можно крепить к игровым объектам.
После того, как данный класс закреплен на игровом объекте, его можно предварительно настроить из редактора.
Отлично, теперь мы можем без лишних проблем настроить наш компонент прямо из редактора Unity.
Настало время написать первую систему. Для этого необходимо просто создать класс и реализовать один из готовых интерфейсов, чаще всего используются только:
IEcsInitSystem // Срабатывает 1 раз при инициализации
IEcsRunSystem // Срабтаывает на Update или Fixed Update метод
Пишем первую систему
Выбираем метод конвертации
После запуска игровой объект автоматически сконвертируется в Entity. Система начнет отрабатывать свои методы. Мы успешно интегрировали Leo ECS в наш проект. Поздравляю!
Наверное у вас еще остались вопросы, я попробую ответить на них.
Вопрос-Ответ
Вы можете порождать prefab любым известным вам способом, конвертация пройдет автоматически.
В ECS очень важно не нарушать порядок, при котором выполняются системы, асинхронное срабатывание может привести к большим проблемам в будущем.
Очень часто ивент-компоненты нужно очищать в конце кадра, для этого в LeoECS есть готовый механизм.
Но вы вполне можете использовать и пакеты от компании Unity, они дадут намного больше производительности, но интеграция с ними не так легка.
На хабре уже существует отличный пост про Job систему. Вам необходимо вызвать ее внутри ваших Run методов в LeoECS.
Пример работы с Job System есть выше, в разделе про тестирование.
Готовой интеграции для LeoECS с популярными сетевыми библиотеками на данный момент не существует, но передача данных осуществляется через ивенты, а как работать с ивентами я уже отвечал.
В любом случается, на данный момент вам придется самостоятельно придумать как лучше всего интегрировать то или иное решение с ECS.
Да, возможно сторонние ECS решения не такие быстрые, как подход DOTS, но они позволяют существенно увеличить производительность относительно классического MonoBehavior подхода. Теперь вы знаете с чего начать свой Megacity проект!
Основные принципы использования ECS в разработке игр
Как считаете, время разработчиков-одиночек прошло? Или наступает именно сейчас? Когда самоизоляция и карантин обеспечили избыток свободного времени и свободу от офисной мозгомойки, можно задуматься не только о «текучке», но и творчестве.
Быть может, именно сейчас рождаются проекты «одного человека», которые смогут встать в один ряд с «Elite», «VVVVVV», «Papers, Please», «Stardew Valley», «Undertale» и «Minecraft». Gamedev вполне можно считать одним из видов искусства, расширяющим горизонты познания окружающего мира и внутреннего мира человека.
Мы подготовили концентрированную выжимку информации, полученной на лекционном вечере сообщества ECS COMRADE, которое проходило еще до карантина в Высшей школе бизнес-информатики НИУ ВШЭ в рамках образовательных программ по игровой индустрии «Менеджмент игровых проектов» и «Основы создания игр».
Давным-давно, в далёкой-далёкой галактике…
Примерно с 70-х годов прошлого века, когда разработка игр была еще в зачаточном состоянии, основным подходом в создании цифровых продуктов был классический метод (объектно-ориентированный). Однако он использовался за неимением альтернатив — сейчас наступает эра, когда «классика» должна остаться в прошлом, а на смену ей придет более функциональный и универсальный метод.
Представьте, что вам нужно создать определенного юнита, к примеру, кошку. Как это делается в обычное время? Нам необходимо сделать класс, потом подкласс, в который включается эта самая кошка (класс хищник, подкласс семейство кошачьих).
Одним словом, наступает момент, когда код нашей игры, созданной при помощи объектно-ориентированного подхода, превращается в этакого «макаронного монстра». Да, система все-таки будет рабочей, но развивать такой код окажется весьма проблематично.
Так что на замену данной методики пришел подход под названием composition over inheritance. Он оказывается более гибким и настраиваемым, который позволяет решать проблему создания новых игровых элементов. Однако в таком коде еще проще запутаться, чем в классическом, что снова возвращает нас к необходимости совершенствовать методику разработки игровых приложений и самостоятельных проектов.
Потом все изменилось…
Мартин Адамс стал тем человеком, который предложил внедрить революционную систему Entity component system. Именно она позволила приступить к разработке крутых ММОРПГ — именно ECS в дальнейшем будет использоваться практически во всех студиях и практически всеми разработчиками.
Что такие ECS? Это, если говорить простыми словами, архитектурный паттерн, который используется при разработке современных видеоигр.
В чем же преимущества этой системы?
Во-первых, она создана напрямую для разработки игр (целевое направление, которое позволяет адаптировать методику под определенные задачи).
Во-вторых, ECS намного проще развивать.
В-третьих, методика работает по принципу схожести с реальным миром (основана на реальных физических законах).
Мы любим обсуждать все, что связано с ECS в нашем Телеграм-канале. Присоединяйтесь, если также увлекаетесь этой темой.
В конце концов, архитектура идеально подходит для коллаборации. Программисты, использующие ECS, пишут атомизированный код, что позволяет вносить правки разными людьми, преследующими, порой, самые разные цели.
На каких фреймворках лучше работать с ECS?
Оптимально использовать DOTS (высокопроизводительный многопоточный стек, делающий работу на игровом движке более оптимизированной и комфортной), если речь идет о разработке игр на Unity. Это не сторонний фреймворк, а уже являющийся частью Unity, он постоянно развивается и поддерживается. Другими словами, у DOTS есть будущее.
Конечно, и с ним имеются определенные проблемы (например, допускается использование только blittable types и много boilerplate), которые устроят не каждого разработчика. Однако данному способу отдают предпочтения разработчики на Unity, которые предпочитают использовать огромное количество уже готовых инструментов и делать игру, а не писать код.
Не одной ECS едины
Конечно, всю игру, сделанную на Unity, невозможно разработать на одной лишь ECS. Есть определенные элементы, которые выполняются на другой архитектуре и служат эдакой связью системы с «внешним миром».
Новый Input, который не так давно сделали для движка. Так вот, с его помощью и модернизируется ESC-архитектура, что позволяет, к примеру, назначать клавиши клавиатуры или кнопки мышки для определенного действия. Главное преимущество подобного подхода – универсальность. «Прибиндить» к действию вы можете практически любую клавишу, в том числе и «курки» геймпадов. После чего все выполненные мероприятия перекладываются в специальный буфер, через который и идет связь с ECS.
Почему прототипировать на ECS быстро?
На самом деле, разработка на этой архитектуре быстрее, потому что сотруднику требуется прилагать меньше умственных усилий и писать меньше кода. Тут нужно оба момента разобрать подробнее, чтобы четко определить все преимущества данного подхода к созданию видеоигр.
Итак, про мышление. Всего можно мыслить в трех направлениях: YOLO, ООП и, собственного, ECS. Первое – это Unity-way, который легко освоить, однако у него есть весомая проблема – слабо развивается. Второй вариант активно поддерживается и развивается, но порог вхождения в него намного выше. Третий же подход к мышлению включает в себя одни плюсы (меньше печатать, легче освоить и так далее).
Когда вы работаете на ECS, то вы мыслите в данных. И у вас есть 3 типа данных: статические, runtime-данные и config-данные. Первые никогда не меняются, вторые представляют собой игровую логику, а последние отвечают за пользовательские настройки, данные баланса и прочие условия, меняющиеся от сессии к сессии.
Далее следует определить, на каком фреймворке мы будем работать (спойлер, выбираем LeoECS). Выбор делаем мы, смотря на скорость написания кода (она у данного фреймворка максимальная), на простоту освоения и степень зависимости от Unity. Данный фреймворк мы применяем на этапе перехода от статистических данных к runtime-сегменту, связывая их, а потом переходим к конфигам.
Итоги
Можно прийти к выводу, что архитектура ECS для разработки современных игр не просто подходит, а рекомендуется. С ее помощью вы сможете существенно сократить затраты временных ресурсов на ручную работу, что позволит выпустить игру раньше и более проработанной. А что еще нужно для обычного игрового разработчика?
Посмотреть полные видео с лекций можно здесь:
Как и почему мы написали свой ECS
Что такое ECS на примере
Кратко я уже описывал, что такое Entity Component System, и на Хабре есть статьи про ECS (в основном, правда, переводы статей — смотрите мой обзор самых интересных из них в конце статьи, в качестве бонуса). А сегодня расскажу, как используем ECS мы — на примере нашего кода.
На схеме выше описаны сущность Player, её компоненты и их данные, и системы, которые работают с игроком и его компонентами. Ключевым объектом на схеме является игрок:
Для компонентов мы создаем классы-заготовки, которые используются нашим генератором кода для преобразования их в реально используемый код компонентов. Заведем заготовки для Health, Damage и Invincible (для остальных компонентов будет похоже).
Компоненты определяют состояние мира, поэтому содержат только данные, без методов. При этом в Invincible данных нет, он используется в логике как признак неуязвимости — если у сущности игрока есть этот компонент, значит игрок сейчас неуязвим.
Атрибут Component используется генератором для нахождения классов-заготовок для компонентов. Атрибуты Max и DontSend нужны как подсказки при сериализации и уменьшения размера состояния мира, передаваемого по сети или сохраняемого на диск. В данном случае сервер не будет сериализовать поле Amount и посылать его по сети (потому что клиенты не используют этот параметр, он нужен только на сервере). А поле Hp можно хорошо упаковать в несколько бит, учитывая максимальное значение здоровья.
У нас также есть класс-заготовка Entity, куда мы добавляем информацию о всех возможных компонентах у любой сущности, а генератор уже создаст из него реальный класс:
После этого наш генератор создаст код классов-компонентов Health, Damage и Invincible, которые уже будут использоваться в игровой логике:
Как видите, в классах остались данные и добавились методы, например, Reset. Он нужен для оптимизации и переиспользования компонентов в пулах. Другие методы вспомогательные, не содержат бизнес-логику — их не буду приводить для краткости кода.
Также будет сгенерирован класс для состояния мира, который содержит список всех компонентов и сущностей:
И наконец, сгенерированный код для Entity:
Класс Entity — это, в сущности, лишь идентификатор компонента. Ссылка на объекты мира GameState используются лишь в вспомогательных методах для удобства написания кода бизнес-логики. Зная идентификатор компонента, мы можем использовать его для сериализации связей между сущностями, реализации ссылок в компонентах на другие сущности. Например, компонент Damage содержит ссылку на сущность Victim для определения, кому нанесен урон.
На этом сгенерированный код заканчивается. Вообще, генератор нам нужен, чтобы не писать каждый раз вспомогательные методы. Мы только описываем компоненты как данные, дальше всю работу делает генератор. Примеры вспомогательных методов:
Система проходится по всем компонентам Damage в мире и смотрит, есть ли на потенциально поврежденном игроке (Victim) компонент Invincible. Если он есть — игрок неуязвим, урон не начисляется. Далее получаем компонент Health жертвы и уменьшаем здоровье игрока на размер урона.
Рассмотрим ключевые особенности систем:
Некоторые факты о ECS
У ECS есть свои плюсы и минусы, как подхода к разработке и способа представления мира игры, поэтому каждый сам для себя решает — использовать его или нет. Начнем с плюсов:
— Model — GameState из ECS;
— View — у нас это исключительно стандартные MonoBehaviour-классы Unity (Renderer, Text и т.д.) и префабы;
— Presenter использует GameState для определения событий появления/исчезания сущностей, компонент и т.д., создает объекты Unity из префабов и меняет их в соответствии с изменением состояния мира.
А знаете ли вы, что:
Наши критерии выбора ECS-фреймворка
Когда мы решили делать игру на ECS, мы начали искать готовое решение и выписали требования к нему на основе опыта одного из разработчиков. И расписали, насколько существующие решения соответствуют нашим требованиям. Это было год назад, на текущий момент что-то могло уже измениться. В качестве решений мы рассматривали:
Красный цвет — решение не поддерживает наше требование, оранжевый — поддерживает частично, зеленый — поддерживает полностью.
Для нас аналогией операций доступа к компонентам, поиска сущностей в ECS были операции в sql-базе данных. Поэтому мы использовали понятия типа table (таблица), join (операция соединения), indices (индексы) и т.д.
Распишем наши требования и насколько сторонние библиотеки и фреймворки им соответствовали:
Особенности нашей разработки на ECS
Бонус
В процессе решения — а нужна ли Хабру статья про ECS — я провел небольшое исследование. Как и обещал в начале, вот мой небольшой обзор статей по этой теме, а вы решайте, читать или нет:
Unity, ECS и все-все-все
Сколько уже было мануалов «Как сделать игру на Unity за 3 часа», «Делаем Counter-Strike за вечер» и т.п.? Низкий порог входа — это, несомненно, главный плюс и минус Unity. Действительно, можно накидать “ассетов”, дописать несколько простых “скриптов”, обмотать синей изолентой и это даже будет как-то работать. Но когда проект обрастает игровыми механиками, сложной логикой поведения, то проблемы при подобном подходе нарастают как снежный ком. Для внедрения новых механик требуется переписывание кода во многих местах, постоянная проверка и переделывание префабов из-за побившихся ссылок на компоненты логики, не говоря уже об оптимизации и тестировании всего этого. Разумеется, архитектуру можно продумать изначально, но на практике это всегда недостижимая цель — дизайн-документ довольно часто меняется, какие-то части выкидываются, добавляются абсолютно новые и никак не связанные со старой логикой поведения. Компоненты в Unity — это шаг в правильном направлении в виде декомпозиции кода на изолированные блоки, но особенности реализации не позволяют достичь необходимой гибкости, а самое главное, производительности. Разработчики придумывают свои фреймворки и велосипеды, но чаще всего останавливаются на ECS (Entity Component System). ECS – одно из решений, продолжающее идею компонентной модели Unity, но придающее ей ещё больше гибкости и сильно упрощающее рефакторинг и дальнейшее расширение приложения новым функционалом без кардинальных изменений в текущем коде.
Что такое ECS
ECS — это шаблон проектирования «Сущность Компонент Система» (Entity Component System, не путать с Elastic Cloud Storage :). Если совсем по-простому, то есть “Сущности” (Entity) — объекты-контейнеры, не обладающие свойствами, но выступающие хранилищами для “Компонентов”. “Компоненты” — это блоки данных, определяющие всевозможные свойства любых игровых объектов или событий. Все эти данные, сгруппированные в контейнеры, обрабатываются логикой, существующей исключительно в виде “Систем” — “чистых” классов с определенными методами для выполнения. Данный паттерн является независимым от какого-либо “движка” и может быть реализован множеством способов. Все “сущности”, “системы” и “компоненты” должны где-то храниться и каким-то образом инициализироваться — все это является особенностями реализации каждого ECS решения для конкретного “движка”.
Постойте, скажете вы, но ведь в Unity всё так и есть! Действительно, в Unity “Сущность” — это GameObject, а “Компонент” и “Система” — это наследники MonoBehaviour. Но в этом и заключается основное различие между компонентной системой Unity и ECS — логика в ECS обязательно должна быть отделена от данных. Это позволяет очень гибко менять логику (даже удалять / добавлять её), не ломая данные. Другой бонус — данные обрабатываются “потоком” в каждой системе и независимо от реализации в “движке”, в случае с MonoBehaviour происходит довольно много взаимодействия с “Native”-частью, что съедает часть производительности. Об особенностях внутреннего устройства вызова методов у наследников MonoBehaviour можно почитать в официальном блоге Unity: 10000 вызовов Update()
Пример работы ECS
Задача от дизайнера: “надо сделать перемещение игрока и загрузку следующего уровня, когда он доходит то точки Х”.
Разбиваем задачу на несколько подзадач, по одной на “систему”:
И вот как это всё примерно работает:
UPD: josinSbazin сделал реализацию этой тестовой задачи.
Выглядит как чрезмерное усложнение кода по сравнению с одним “MonoBehaviour” классом в десяток строк, но изначально:
Особенности ECS
Исходя из примера выше, можно вывести основные особенности ECS по отношению к компонентной модели Unity.
Плюсы
Минусы
Для многих, кто долго работал с Unity и ни разу не использовал ECS, поначалу будет сложно привыкнуть к такому подходу. Но вскоре, начинаешь “думать” компонентами / системами и всё собирается быстрее и легче, чем при сильно связанных компонентах на базе “MonoBehaviour”.
Встроенное ECS-решение в Unity
Сейчас даже сами разработчики Unity поняли, что пора что-то менять в их компонентной системе, чтобы повысить производительность приложений. Где-то год назад было анонсировано, что ведётся разработка собственной ECS и C# Job system. И вот, в 2018.1 версии, мы уже можем примерно представить, что же это будет в будущем, пусть даже и в Preview статусе.
Со штатной Unity ECS – пока ничего не понятно. Разработчики нигде не пишут, что она подходит только для ограниченного спектра задач, но когда возникают вопросы в результате переписывания с других ECS-решений — отвечают в стиле “вы неправильно используете ECS”. Т.е. по сути это получается не “multipurpose”-решение, что довольно странно. Релиза не было, всё еще могут поменять несколько раз, есть проблемы с передачей ссылочных типов (например, string), поэтому я не могу порекомендовать делать что-то большое на штатной ECS в её текущем состоянии.
Альтернативные ECS-решения для Unity
ECS-паттерн был придуман не вчера и на https://github.com можно найти множество его реализаций, включая версии для Unity. Относительно свежие и обновляющиеся:
Я имел дело только с двумя первыми вариантами.
Entitas — самое популярное и поддерживаемое большим сообществом решение (потому что было первым). Оно достаточно быстрое, есть интеграция с Unity-редактором для визуализации ECS-объектов, присутствует кодогенерация для создания оберток с удобным api поверх пользовательских компонентов. За последний год кодогенератор отделился в независимый проект и стал платным, так что это скорее минус. Еще один достаточно весомый минус (особенно для мобильных платформ) — память выделяется под все возможные варианты компонентов на каждой сущности, что не очень хорошо. Но в целом, он хорош, отлично документирован и готов к использованию на реальных проектах. Размер: 0.5mb + 3mb поддержки редактора.
Примеров с использованием Entitas достаточно много, но и существует / пиарится проект давно. Из примеров с исходниками можно посмотреть Match 1.
Общая производительность Entitas оценивается примерно так: 
С LeoECS я знаком лучше, потому что делаю на нём новую игру. Оно компактное, не содержит закрытого кода в виде внешних сборок, поддерживает assembly definitions из Unity 2017, более оптимизировано по использованию памяти, практически нулевой GC (только на первичном наборе пулов), никаких зависимостей, C# v3.5 с опциональной поддержкой inline-ов для FW4.6. Из приятных вещей: DI через разметку атрибутами, интеграция с Unity-редактором для визуализации ECS-объектов и готовая обвязка для событий uGUI. Размер: 18kb + 16kb поддержки редактора.
В качестве готового примера с исходниками можно посмотреть классическую игру «Змейка».
Сравнение скорости Entitas и LeoECS: результаты достаточно близки с небольшим перевесом в ту и другую сторону.
Заключение
Я не эксперт в данном вопросе (только недавно начал использовать Unity в связке с ECS), поэтому и решил поделиться своими наблюдениями и мыслями в первую очередь с теми, кто «собирает» игры на Unity из ассетов с кучей скриптов на каждом. Да, это работает. Сам такой был. Но если вы делаете не прототип или какую-нибудь одноразовую игру без необходимости её поддержки и дальнейшего развития, то подумайте 10 раз — вам же потом во всём этом разбираться и переделывать.
Используя ECS я даже получаю удовольствие от процесса рефакторинга 🙂 В игру легко добавляются новые фичи, изменяются старые — и всё это без боли и конфликтов с дизайнером, решившим добавить новую зубодробительную механику или удалить старые, наигравшись с ними.