Расскажи про опыт работы с LeoECS

Мой опыт работы с LeoECS (Entitas-подобный фреймворк для Unity)

Я использовал LeoECS в нескольких коммерческих проектах, где требовалась максимальная производительность и предсказуемость логики при сохранении простоты кода. Это легковесный Data-Oriented фреймворк для реализации архитектуры Entity Component System (ECS) в Unity, идеально подходящий для проектов с тысячными пулами объектов (например, мобильные гипер-казуальные игры, симуляторы, тактические проекты).

Ключевые преимущества, которые я использовал на практике

• Низкий порог входа для команды. По сравнению с Unity DOTS, LeoECS имеет гораздо более простой API. Я создавал шаблоны и сниппеты, которые позволяли коллегам, не знакомым с ECS, быстро начать вносить функциональность.
• Выдающаяся производительность. В проекте с тактическим боем, где на поле одновременно находилось до 500 юнитов с AI, физикой (коллизии через системы) и анимациями, переход с MonoBehaviour на LeoECS дал прирост в >3x по количеству кадров на целевых мобильных устройствах. Это достигается за счет линейного итеративного обхода данных в системах.
• Четкое разделение ответственности. Data (компоненты), Logic (системы) и сами Entity строго разделены. Это значительно упрощало тестирование систем в изоляции и рефакторинг.

Пример реализации типичной системы

Рассмотрим систему движения. Сначала определяем компонент как структуру (чистые данные):

// Компонент: данные о перемещении
public struct MoveComponent
{
    public Vector3 Position;
    public Vector3 TargetPosition;
    public float Speed;
}

Система инжектит отфильтрованный пул сущностей, имеющих нужные компоненты, и обрабатывает их в Run():

// Система: логика перемещения
public class MoveSystem : IEcsRunSystem
{
    private readonly EcsFilter<MoveComponent> _movables = null;

    public void Run()
    {
        // Итерация по всем сущностям с MoveComponent - эффективный линейный проход
        foreach (var entityId in _movables)
        {
            ref var moveComp = ref _movables.Get1(entityId);

            // Вычисление нового положения (чистая логика, без зависимостей от Engine)
            var direction = (moveComp.TargetPosition - moveComp.Position).normalized;
            moveComp.Position += direction * moveComp.Speed * Time.deltaTime;

            // Здесь можно было бы добавить компонент-тег RequirePositionUpdateTag
            // для последующей системы, которая синхронизирует Transform.
        }
    }
}

Далее, отдельная ReactiveSystem или TransformSyncSystem будет отвечать за применение Position к GameObject.transform, минимизируя связь с Unity API внутри вычислительной логики.

Практические паттерны и проблемы

• Синхронизация с Unity View. Реализовывал системы-презентеры, которые по компонентам-тегам (например, PositionChangedTag) обновляют Transforms, аниматоры или VFX. Использовал EcsWorld.InjectUnityGlobalComponent() для доступа к Time.deltaTime в одном месте.
• Управление зависимостями между системами. Использовал стандартную для LeoECS фиксированную последовательность выполнения в EcsSystems. Для обработки событий (например, "сущность получила урон") применял компоненты-события, которые создаются и потребляются в одном кадре.
• Отладка. Пользовался LeoECS-Lite и его встроенным отладчиком (EcsWorldObserver), который позволяет отслеживать все сущности, их компоненты и активные системы прямо в редакторе Unity — незаменимый инструмент.
• Сложность при интеграции сложных сторонних ассетов. Не все плагины легко обернуть в ECS-стиль. В таких случаях использовал гибридный подход: MonoBehaviour как "адаптер" для View, который генерирует события в ECS-мир.

Выводы по использованию

LeoECS — это отличный выбор, когда нужно резко повысить производительность кадро-зависимой логики игры без погружения в сложности Unity DOTS и Burst Compiler. Однако он требует от разработчика строгой дисциплины в проектировании и понимания Data-Oriented принципов. Главный недостаток — фреймворк "варится в собственном соку" и иногда требует написания большего объема шаблонного кода для связи с Unity-инфраструктурой, но этот код, как правило, хорошо стандартизируется. Для нового проекта с высокой нагрузкой на CPU я бы снова выбрал LeoECS или его продвинутую версию LeoECS Extended.