Вопросы 24/01/2022

Улучшаем проект на Unity: что такое ECS и стоит ли применять его в разработке

Сооснователь Stan’s Assets from KAPPS

На сегодняшний день существует огромное количество информации о том, насколько хорошо себя показывает Unity ECSEntity-Component-System (ECS) — это шаблон проектирования, обеспечивающий гибкость в проектировании архитектуры ПО. по сравнению с MonoBehaviour. Но возникает вопрос: если с ним все так круто, почему же тогда его нет в каждом проекте? Об этом сегодня и поговорим.

Давайте разберемся, о каком ECS мы будем говорить в этой статье.

ECS – это один из модулей стека Unity DOTS, который был представлен еще в 2017 году. Он включает в себя несколько технологий, основные это: Job System, ECS, Burst Compiler, а также другие пакеты: Unity Physics, Unity Netсode, DSPGraph, DOTS Runtime, Unity Animation.

Сердце стека — Entity Component System, где:

Entity — сущности, которые обитают в проекте;

Component – компоненты с данными, которые придают сущностям различные свойства;
System – чистые системы, которые работают с сущностями и данными, которые находятся в их компонентах.

На вебинаре мы показывали демо, в котором ECS DOTS демонстрирует невероятную производительность по сравнению с MonoBehaviour. Такую скорость работы мы получили благодаря тому, что каждый наш Entity (контейнер с данными), который мы можем очень легко находить, был обработан в одном месте внутри нашей системы. Решая такую же задачу с MonoBehaviour, мы делали бы эту операцию в Update и в каждом MonoBehaviour отдельно.

Очень важно отметить, что стек DOTS позволяет нам работать с Job System и Burst Compiler без дата-ориентированного подхода в разработке. Соответственно, Job System открывает нам двери в мир многопоточной работы с Unity API. Burst Compiler хоть и накладывает определенные ограничения при написании кода, но как вознаграждение от LLVMLow Level Virtual Machine — вычислительная технология бэкенд-компиляции. мы получаем высокооптимизированный код, адаптированный под текущую платформу. Поэтому можем сделать вывод, что путь к оптимизации и увеличению производительности с помощью DOTS — это далеко не всегда ECS.

Давайте проанализируем, когда на самом деле хорош и полезен ECS?

Когда в проекте огромное количество сущностей одинакового архетипа.
ECS дает нам гибкость в логике. Он заставляет нас мыслить и, соответственно, проектировать наш проект DoD. Важно отметить, что часто, когда разработчики видят методы внутри компонентов, то принимают это за ошибку. К счастью, это не всегда так, и давайте разберемся почему. Компонент может иметь внутри себя логику, которая обрабатывает только данные текущего компонента. Например: внутри структуры Vector3 мы можем найти множество удобных свойств, таких как Magnitude, Normalized или метод Set. Все они созданы с единой целью — помочь разработчику.
Photon Quantum (высокопроизводительная детерминированная среда ECS). Какое главное отличие PQ от обычного Photon-сервера, с которым мы привыкли взаимодействовать в мире Unity? Оно состоит в том, что в сердце Photon Quantum все изначально живет в виде сущностей. Вам придется работать с unmanaged-кодом в C#, и так вы практически бесшовно сможете перейти на ECS в Unity. Фактически приложение на Photon Quantum работает как большая симуляция, и в Unity он используется только на view-layer, это значит, что ваша игра может жить и работать в headless mode. В Photon Quantum есть свой pathfinding, свой физический движок и множество других. К тому же, система симуляции физики в Unity плохая, потому что она недетерминированная. Это значит, что при одних и тех же входных данных я не получу одинаковые результаты физической симуляции. Другими словами, мы не можем полагаться на такую систему, если в нашей игре физика — это важная часть геймплея. Поэтому в Photon Quantum есть свой физический детерменированный фреймворк (одинаковые входные данные = одинаковые результаты на разных клиентах).

А когда же ECS не так хорош?

Когда вам нужно быть оперативным. С точки зрения бизнеса и разработки — время на разработку приложения, которое будет создано с помощью ECS, будет больше. Потому что вам нужно будет лучше и дольше придумать вашу систему, сущности, компоненты. Самого кода, который вам нужно будет написать для ECS, будет буквально больше по сравнению с MonoBehaviour. Поэтому и ваше общее время на разработку увеличится. Но важно помнить, что многие фреймворки этим страдают (обязывают нас писать boilerplate codeСтандартный код, который можно использовать без изменений в нескольких проектах.), но при этом, поработав больше вначале — мы получаем больше плюсов потом.
Когда дело касается UI и анимации. Очень часто в ECS-демо мы видим, какие-то крутые штуки. Но завершенный проект — это далеко не один геймплей. И важная часть обертки, которую мы хотим видеть — это анимированный UI. И вот в этом моменте все становится непросто, потому что если мы идем в pure ECS mode, например, это у нас Project Tiny, то в целом у нас нет другого рендера и мы не можем никак рендерить, кроме как через ECS-компоненты. Это значит, что нам придется и UI строить в том же data-oriented-стеке. Делать это не очень приятно, и в принципе ECS не очень хорошо подходит для решения этих задач, не говоря уже о полном отсутствии каких-либо фреймворков, наработок и чего-либо еще в этом направлении. Поэтому UI вам будет строить очень сложно, не говоря уже об анимации и остальных фичах, которыми вы точно захотите наполнить ваш проект.

Когда есть вопросы с читаемостью кода. Это общая проблема программирования. Чем больше кода, тем сложнее его читать и тем потенциально больше в нем возникает багов. То есть представьте, если бы я жил в мире MonoBehaviour, то у меня был бы всего один класс, где у меня есть определенные сериализованные поля, которые я использую, как данные, update loop в котором крутится моя логика, которая обрабатывает каждый кадр. Если я бы делал такую же задачу в мире ECS, то у меня были бы как минимум еще один component-класс. И должен быть еще какой-то bootstrapper, который создаст все мои ECS-сущности, чтобы все это жило в мире ECS.
Когда нужно соединить мир MonoBehaviour (где нам нужно что-то рендерить) и мир ECS (где только данные и логика). Тут все сталкиваются с проблемами, чтобы их «подружить». Вы будете писать различные data-bindingsСвязывание данных — это процесс, который устанавливает соединение между UI приложения и бизнес-логикой., когда фактически наши Views будут фолловить какие-то сущности, позиции которых мы просчитываем в Job Systems. Ведь внутри вашего проекта должны взаимодействовать множество систем, и если они из разных миров, то реализация их взаимодействия всегда будет очень нетривиальной задачей. В Unity важно помнить, что со сценами и контентом работают люди. И ECS пока что не очень дружественный в этом плане. Представьте, что мы ничего не видим на экране по рендеру до тех пор, пока не созданы world entities в ECS-домене. Артисты и геймдизайнеры не могут так работать, им нужны «живые» сцены. Если вспомнить наш Unity-инспектор, то в ECS он не не позволит нам редактировать значения. Именно это закрывает двери возможностей для артистов и дизайнеров.

Как и когда лучше использовать ECS?

ECS в Unity чаще всего ассоциируется с оптимизацией, то есть получив какие-то проблемы с огромным числом Monobehaviour, разработчик может принять за данность переход на дата-ориентированный стек и начать переписывать весь проект. Безусловно, во многих ситуациях ECS даст вам значительный результат, но прежде задайте себе несколько вопросов:

Вы готовы переписывать большую часть своего проекта? Ведь одной системой все не ограничится, и она потянет за собой другие, как снежный ком.

Вы уверены, что рассмотрели другие варианты оптимизации, и ECS — это единственный путь? Очень часто мы сталкивались с ситуациями, когда у разработчиков опускались руки из-за проблем с производительностью, но зачастую парочка детальных и боевых профайл-сессий и несколько новых идей — и так решались поставленные задачи. У разработчика, с точки зрения C#, есть множество инструментов, оптимизация математики самих алгоритмов, базовые подходы оптимизации в Unity и напоследок Job System и Burst Compiler (пока без ECS).

Еще один очень немаловажный фактор, чтобы понять, стоит ли использовать ECS — это стадия проекта. Если проект находится в ранней стадии разработки и возможно заложить дополнительное время, чтобы построить ту же задачу с помощью дата-ориентированного подхода – тогда да. Ведь количество систем, которые нужно будет менять — меньше. Но если проект близок к завершению и уже находится в продакшене, очень сложно приостановить всю разработку и на полгода закрыться переписывать код.

Мы делаем проекты с дедлайнами и отодвинуть любой из них — это потенциальный удар и потеря возможности конкурировать на рынке. Ориентируйтесь на текущие бизнес-условия и возможности, а не только на технический аспект.

Поэтому все наши аргументы можно кратко суммировать одной фразой: ECS не ради ECS-концепции разработки, а ради производительности, когда приложение действительно в этом нуждается.

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