Хабрахабр

Unity, ECS и все-все-все

Низкий порог входа — это, несомненно, главный плюс и минус Unity. Сколько уже было мануалов "Как сделать игру на Unity за 3 часа", "Делаем Counter-Strike за вечер" и т.п.? Но когда проект обрастает игровыми механиками, сложной логикой поведения, то проблемы при подобном подходе нарастают как снежный ком. Действительно, можно накидать “ассетов”, дописать несколько простых “скриптов”, обмотать синей изолентой и это даже будет как-то работать. Разумеется, архитектуру можно продумать изначально, но на практике это всегда недостижимая цель — дизайн-документ довольно часто меняется, какие-то части выкидываются, добавляются абсолютно новые и никак не связанные со старой логикой поведения. Для внедрения новых механик требуется переписывание кода во многих местах, постоянная проверка и переделывание префабов из-за побившихся ссылок на компоненты логики, не говоря уже об оптимизации и тестировании всего этого. Разработчики придумывают свои фреймворки и велосипеды, но чаще всего останавливаются на ECS (Entity Component System). Компоненты в Unity — это шаг в правильном направлении в виде декомпозиции кода на изолированные блоки, но особенности реализации не позволяют достичь необходимой гибкости, а самое главное, производительности. ECS – одно из решений, продолжающее идею компонентной модели Unity, но придающее ей ещё больше гибкости и сильно упрощающее рефакторинг и дальнейшее расширение приложения новым функционалом без кардинальных изменений в текущем коде.

Если совсем по-простому, то есть “Сущности” (Entity) — объекты-контейнеры, не обладающие свойствами, но выступающие хранилищами для “Компонентов”. ECS — это шаблон проектирования "Сущность Компонент Система" (Entity Component System, не путать с Elastic Cloud Storage :). Все эти данные, сгруппированные в контейнеры, обрабатываются логикой, существующей исключительно в виде “Систем” — “чистых” классов с определенными методами для выполнения. “Компоненты” — это блоки данных, определяющие всевозможные свойства любых игровых объектов или событий. Все “сущности”, “системы” и “компоненты” должны где-то храниться и каким-то образом инициализироваться — все это является особенностями реализации каждого ECS решения для конкретного “движка”. Данный паттерн является независимым от какого-либо “движка” и может быть реализован множеством способов.

Действительно, в Unity Сущность — это GameObject, а Компонент и Система — это наследники MonoBehaviour. Постойте, скажете вы, но ведь в Unity всё так и есть! Это позволяет очень гибко менять логику (даже удалять / добавлять её), не ломая данные. Но в этом и заключается основное различие между компонентной системой Unity и ECS — логика в ECS обязательно должна быть отделена от данных. Об особенностях внутреннего устройства вызова методов у наследников MonoBehaviour можно почитать в официальном блоге Unity: 10000 вызовов Update() Другой бонус — данные обрабатываются “потоком” в каждой системе и независимо от реализации в “движке”, в случае с MonoBehaviour происходит довольно много взаимодействия с “Native”-частью, что съедает часть производительности.

Задача от дизайнера: “надо сделать перемещение игрока и загрузку следующего уровня, когда он доходит то точки Х”.
Разбиваем задачу на несколько подзадач, по одной на “систему”:

  • UserInputSystem — пользовательский ввод.
  • MovePlayerSystem — перемещение игрока на основе ввода.
  • CheckPointSystem — проверка достижения точки игроком.
  • LoadLevelSystem — загрузка уровня в нужный момент.

Определяем компоненты:

  • UserInputEvent — событие о наличии пользовательского ввода с данными о нем. Да, события — это тоже компоненты!
  • Player — хранение текущей позиции игрока и его скорости.
  • CheckPoint — точка взаимодействия на карте.
  • LoadLevelEvent — событие о необходимости загрузки нового уровня.

И вот как это всё примерно работает:

  • Загружается сцена и инициализируются все системы в указанной выше последовательности. Да, порядок обработки систем можно контролировать без сложных телодвижений- это ещё один приятный бонус.
  • Создаются сущности игрока (с добавлением на него компонента Player) и сущности контрольной точки (с добавлением на неё компонента CheckPoint).
  • Тут стартует основной цикл обработки систем — по сути аналог метода MonoBehaviour.Update.
  • UserInputSystem проверяет пользовательский ввод через стандартное Unity-api и создает новую сущность с компонентом UserInputEvent и данными о вводе (если он был).
  • MovePlayerSystem проверяет — есть ли сущности с компонентом UserInputEvent и есть ли сущности с компонентом Player. Если пользовательский ввод есть — обрабатываем всех найденных “игроков” (даже если он один) с полученными данными, а сущность с компонентом UserInputEvent удаляем полностью. Да, это работает очень быстро, не вызывает работы сборщика мусора — все уходит во внутренний пул для последующего переиспользования.
  • CheckPointSystem проверяет — есть ли сущности с компонентом CheckPoint и есть ли сущности с компонентом Player. Если есть и то и то — в цикле проверяет дистанции между каждым игроком и точкой. Если один из “игроков” находится достаточно близко для срабатывания — создает новую сущность с компонентом LoadLevelEvent.
  • LoadLevelSystem проверяет — есть ли сущности с компонентом LoadLevelEvent и выполняет загрузку новой сцены при наличии. Все сущности с таким компонентом удаляются перед этим.
  • Повторяем основной цикл обработки систем.

Выглядит как чрезмерное усложнение кода по сравнению с одним “MonoBehaviour” классом в десяток строк, но изначально:

  • Позволяет отделить ввод от остальной логики. Мы можем поменять модель ввода с клавиатуры на мышь, контроллер, тачскрин и остальной код не поломается.
  • Позволяет расширять поведение по обработке игрока новыми способами без ломания текущих. Например, мы можем добавить зоны замедления / ускорения на карте путем добавления еще одной или нескольких систем и изменением параметра скорости в компоненте Player для определенных сущностей.
  • Позволяет иметь на карте сколько угодно контрольных точек, а не только одну, как просил дизайнер.
  • Позволяет даже иметь несколько игроков, управляющихся одним способом. Тоже может быть частью игровой механики, как в BinaryLand:

Исходя из примера выше, можно вывести основные особенности ECS по отношению к компонентной модели Unity.

Плюсы

  • Гибкость и масштабируемость (добавление новых, удаление старых систем и компонентов).
  • Эффективное использования памяти (особенность реализации, мы можем переиспользовать инстансы “чистых” C#-классов как угодно в отличие от “MonoBehaviour”).
  • Простой доступ к объектам (выборка (фильтрация) сущностей с определенными компонентами производится ядром ECS без потери скорости и аллокаций памяти — это именно то, чего не хватает компонентной системе Unity).
  • Понятное разделение логики и данных.
  • Проще тестировать (легко воспроизводить тестовое окружение).
  • Возможность использования логики на сервере без Unity (нет зависимостей от самого “движка”).

Минусы

  • Больше кода
  • Для событий самой Unity необходимо каким-то образом пробрасывать их в ECS-окружение через “MonoBehaviour”-обертки.

Но вскоре, начинаешь “думать” компонентами / системами и всё собирается быстрее и легче, чем при сильно связанных компонентах на базе “MonoBehaviour”. Для многих, кто долго работал с Unity и ни разу не использовал ECS, поначалу будет сложно привыкнуть к такому подходу.

Где-то год назад было анонсировано, что ведётся разработка собственной ECS и C# Job system. Сейчас даже сами разработчики Unity поняли, что пора что-то менять в их компонентной системе, чтобы повысить производительность приложений. 1 версии, мы уже можем примерно представить, что же это будет в будущем, пусть даже и в Preview статусе. И вот, в 2018.

Разработчики нигде не пишут, что она подходит только для ограниченного спектра задач, но когда возникают вопросы в результате переписывания с других ECS-решений — отвечают в стиле “вы неправильно используете ECS”. Со штатной Unity ECS – пока ничего не понятно. по сути это получается не “multipurpose”-решение, что довольно странно. Т.е. Релиза не было, всё еще могут поменять несколько раз, есть проблемы с передачей ссылочных типов (например, string), поэтому я не могу порекомендовать делать что-то большое на штатной ECS в её текущем состоянии.

Относительно свежие и обновляющиеся: ECS-паттерн был придуман не вчера и на https://github.com можно найти множество его реализаций, включая версии для Unity.

Я имел дело только с двумя первыми вариантами.

Оно достаточно быстрое, есть интеграция с Unity-редактором для визуализации ECS-объектов, присутствует кодогенерация для создания оберток с удобным api поверх пользовательских компонентов. Entitas — самое популярное и поддерживаемое большим сообществом решение (потому что было первым). Еще один достаточно весомый минус (особенно для мобильных платформ) — память выделяется под все возможные варианты компонентов на каждой сущности, что не очень хорошо. За последний год кодогенератор отделился в независимый проект и стал платным, так что это скорее минус. Размер: 0. Но в целом, он хорош, отлично документирован и готов к использованию на реальных проектах. Из примеров с исходниками можно посмотреть Match 1.
Общая производительность Entitas оценивается примерно так:
5mb + 3mb поддержки редактора.
Примеров с использованием Entitas достаточно много, но и существует / пиарится проект давно.

Оно компактное, не содержит закрытого кода в виде внешних сборок, поддерживает assembly definitions из Unity 2017, более оптимизировано по использованию памяти, практически нулевой GC (только на первичном наборе пулов), никаких зависимостей, C# v3. С LeoECS я знаком лучше, потому что делаю на нём новую игру. 6. 5 с опциональной поддержкой inline-ов для FW4. размер: 18kb + 16kb поддержки редактора.
В качестве готового примера с исходниками можно посмотреть классическую игру "Змейка".
Сравнение скорости Entitas и LeoECS: результаты достаточно близки с небольшим перевесом в ту и другую сторону. Из приятных вещей: DI через разметку атрибутами, интеграция с Unity-редактором для визуализации ECS-объектов и готовая обвязка для событий uGUI.

Да, это работает. Я не эксперт в данном вопросе (только недавно начал использовать Unity в связке с ECS), поэтому и решил поделиться своими наблюдениями и мыслями в первую очередь с теми, кто "собирает" игры на Unity из ассетов с кучей скриптов на каждом. Но если вы делаете не прототип или какую-нибудь одноразовую игру без необходимости её поддержки и дальнейшего развития, то подумайте 10 раз — вам же потом во всём этом разбираться и переделывать. Сам такой был.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть