ECS

​

Решение проблемы «OOP — это плохо»: ECS

​

Почему композиция предпочтительнее наследования для игровых объектов?

1. Допустим, вы хотите, чтобы борги, но не AI и не pAI, потребляли энергию из энергосети, как BasePoweredMachine. Что делать? Сделать наследование боргов от BasePoweredMachine? Это невозможно, так как им нужно наследовать и от BaseMob, и от BaseSilicon. Может, сделать BaseMob наследником BasePoweredMachine? Это тоже не имеет смысла — большинству мобов не понадобится такая функциональность. Единственный вариант — дублировать код, отвечающий за питание, между BaseMachinePowered и Borg.
2. Допустим, вы хотите разрешить пристёгиваться к лошадям и боргам, но не к остальным мобам. Что делать, сделать BaseMob наследником BaseBuckleable? Это не имеет смысла — большинству мобов не понадобится такая функциональность. Ваш единственный вариант снова — дублировать код в нескольких отдалённых классах.

• Борги и кофеварки используют компонент PowerReceiver, что позволяет им потреблять энергию из сети.
• Борги и стулья используют компонент Buckle, что позволяет сущностям с Buckleable (например, людям) пристёгиваться к ним.
• Люди и борги используют компонент PlayerControllable (также известный как Mind в коде SS14), который позволяет игроку управлять ими…
• И большинство игровых объектов выше используют Damageable, что даёт им «здоровье» и возможность получать урон.

​

TODO: закончить

1. Во-первых, наследование. Есть множество проблем и негибкости, связанных со сложными деревьями наследования… Представьте, что у нас нет компонентов, а есть огромное дерево наследования: если у вас есть базовый класс «machine» с потреблением энергии и другой базовый класс «mob» с механикой управления игроком, то сделать моба с качествами машины (или наоборот) без уродливых хаков или общего базового класса для «machine» и «mob» практически невозможно. Но в то же время это не имело бы особого смысла! Большинству мобов не нужны «функции потребления энергии», и мало какие машины будут управляться игроком… Итак, чтобы решить эту ужасную проблему, мы используем «композицию» (компоненты!) вместо наследования. Вы уже знаете это: если хотите, чтобы у сущности были руки, добавьте HandsComponent. Если хотите, чтобы она потребляла энергию, PowerConsumerComponent поможет! Если хотите сделать её управляемой игроком, добавьте MindComponent и управляйте сущностью — и вуаля, мы сделали «киборга» из переиспользуемых, обобщённых компонентов! Это, конечно, трудно сделать с одним лишь огромным деревом наследования… Наследование может быть хорошим для небольших вещей или когда у вас очень маленькое и самодостаточное дерево наследования (см., например, SoundSpecifier — оно крошечное, но наследование там очень помогает), но когда у вас большая сложная игра, такая как SS14, наследование только всё усложняет.
2. Также инкапсуляция — ещё один момент. OOP любит помещать данные и методы/логику в один и тот же класс, в виде связки, и предоставлять только определённые вещи внешнему миру. Вы знаете, забавные модификаторы доступа вроде public, private и т.д.? Инкапсуляция хороша для таких вещей, как движок, которому нужно скрывать/запрещать доступ к некоторым данным или методам. Но она не имеет особого смысла для игровых данных и логики. Например, StackComponent в SS14 не имеет приватных полей или свойств — любой может свободно читать и записывать значения как хочет. Однако это не рекомендуется для взаимодействия со стеками! StackSystem имеет несколько методов для работы с StackComponent и изменения его значений. Чтобы использовать определённое количество чего-либо в стеке, вы используете StackSystem.Use, чтобы разделить — StackSystem.Split и т.д., и StackSystem позаботится обо всём. Потому что оказалось, что просто изменить значение количества в стеке недостаточно. Нужно также делать такие вещи, как: помечать компонент как изменённый для синхронизации по сети, устанавливать значение внешнего вида, вызывать событие StackCountChanged и т.д. В архитектуре E/C вы бы поместили всю эту логику в свойство «amount» в StackComponent или, возможно, в метод. Затем вы могли бы сделать фактическое число «amount» приватным. Однако архитектура E/C не будет принята в этой кодовой базе — мы будем использовать только архитектуру ECS.

1. Наш игровой мир содержит множество сущностей, у сущностей есть компоненты
2. Есть системы, которые работают с компонентами

​

Компоненты: пересмотр

​

Entity Systems: какими они должны были быть с самого начала

​

События, подписки и методы

// Система, работающая на сервере...
// Всякий раз, когда пользователь взаимодействует с сущностью, имеющей этот компонент,
// счётчик в ней будет увеличен на ноль. Также будет вызвано событие.
// Другие Entity Systems могут взаимодействовать с FooComponent через публичный API.
public sealed class FooSystem : EntitySystem
{
    [Dependency] protected readonly SharedAppearanceSystem _appearanceSystem = default!;

    // Всегда подписывайтесь на события здесь, при инициализации
    public override void Initialize()
    {    
        // Подписка на инициализацию FooComponent...
        SubscribeLocalEvent<FooComponent, ComponentInit>(OnFooInit);
        
        // Подписка на взаимодействие пользователя с FooComponent через предмет.
        SubscribeLocalEvent<FooComponent, InteractUsingEvent>(Handle);
        
        // Подписка на широковещательное событие MoveEvent, вызываемое при
        // перемещении сущности... Просто пример подписки
        SubscribeLocalEvent<MoveEvent>(OnEntityMove);
    }
    
    // Вызывается при инициализации FooComponent.
    private void OnFooInit(Entity<FooComponent> ent, ref ComponentInit _)
    {
         // Инициализируйте ваш FooComponent здесь
    }
    
    // Пример обработчика для взаимодействия с FooComponent пользователем.
    private void Handle(Entity<FooComponent> ent, ref InteractUsingEvent args)
    {
        // Увеличиваем счётчик взаимодействий на единицу
        // Мы вызываем этот метод, так как он делает всё за нас.
        SetInteractCounter((ent, ent.Comp), ent.Comp.InteractCounter + 1);
    }
    
    // Вызывается при перемещении сущности.
    private void OnEntityMove(ref MoveEvent ev)
    {
        // Сделайте что-нибудь здесь! Хотя мы ничего не делаем, так как это пример...
    }

    // Публичный метод, который другие системы могут вызывать для взаимодействия с FooComponent
    public void ResetInteractCounter(Entity<FooComponent?> ent)
    {
        // Просто вызываем наш другой метод, который всё делает за нас.
        SetInteractCounter(ent, 0);
    }

    // Публичный метод, который другие системы могут вызывать для взаимодействия с FooComponent
    public void SetInteractCounter(Entity<FooComponent?> ent, int count)
    {
        // Пытаемся разрешить компонент...
        if (!Resolve(ent, ref ent.Comp))
            return;
    
        // Сохраняем старый счётчик для последующего использования...
        var oldCounter = ent.Comp.InteractCounter;
        
        // Устанавливаем новый счётчик взаимодействий
        ent.Comp.InteractCounter = count;
    
        // Теперь устанавливаем некоторые данные внешнего вида, если у сущности есть компонент внешнего вида
        if (TryComp(ent, out AppearanceComponent? appearance))
            _appearanceSystem.SetData(ent, FooVisualData.InteractCounter, count, appearance);
            
        // Теперь вызываем событие, чтобы дать всем знать, что InteractCounter изменился
        // Поскольку третий аргумент — false, это событие не будет широковещательным.
        // Оно будет вызвано только как направленное событие!
        RaiseLocalEvent(ent, new FooInteractCounterChangedEvent(oldCounter, ent.Comp.InteractCounter));
    }
}

[RegisterComponent]
public sealed partial class FooComponent : Component
{    
    // Это будет увеличиваться каждый раз, когда пользователь взаимодействует с нами.
    // Обратите внимание, что логика этого находится не в компоненте, а в системе.
    [DataField]
    public int InteractCounter = 0;
}

// Событие, которое будет вызываться при изменении счётчика взаимодействий FooComponent.
// Это событие неизменяемо и информативно, то есть не может быть изменено обработчиками,
// и его единственная цель — информировать о некотором событии, в данном случае об изменении значения.
public sealed class FooInteractCounterChangedEvent : EntityEventArgs
{
    public int OldCounter { get; }
    public int NewCounter { get; }
    
    public FooInteractCounterChangedEvent(int oldCounter, int newCounter)
    {
        OldCounter = oldCounter;
        NewCounter = newCounter;
    }
}

[Serializable, NetSerializable]
public enum FooVisualData
{
    InteractCounter,
}

​

Создание и использование

​

Время жизни

​

Межзависимости

public sealed class BarSystem : EntitySystem
{
    public void Doo()
    {
        // Некоторая логика здесь
    }
    
    public void Hicky()
    {
        // Некоторая логика здесь
    }
}

public sealed class FooSystem : EntitySystem
{
    // Это будет автоматически установлено при создании системы.
    [Dependency] private readonly BarSystem _barSystem = default!;
 
     // Обычные зависимости от менеджеров IoC также работают здесь
    [Dependency] private readonly IPlayerManager _playerManager = default!;
 
    public override void Initialize()
    {
        // Это работает в Initialize, зависимости уже разрешены.
        _barSystem.Doo();
    }
    
    public void MyFunnyMethod()
    {
        _barSystem.Hicky();
    }
}

​

События, или как создать сложную игру без спагетти-кода

​

Направленные события

​

Широковещательные события

​

Примечание: Сортированные события

​

Шаблоны событий

​

Неизменяемые события

​

Событие жизненного цикла

• ComponentAdd — компонент был добавлен к сущности.
• ComponentInit — компонент был инициализирован.
• ComponentStartup — компонент был запущен.
• ComponentShutdown — компонент был остановлен.
• ComponentRemove — компонент будет удалён.

​

Информационное событие

​

Изменяемые события

​

Отменяемое событие

​

Обработанное событие

​

Обеспечивающее событие

​

Method event

​

События с ручной сортировкой

• BeforeDooHickyEvent
• DooHickyEvent
• AfterDooHickyEvent

​

Рекомендации по созданию событий

• Имена классов событий всегда должны заканчиваться на «Event», никогда на «Message» или что-то ещё.
• Если ваше событие связано с сущностью и является широковещательным, оно должно иметь свойство/поле, ссылающееся на сущность, чтобы широковещательные подписки могли правильно использовать событие. RaiseLocalEvent() не делает событие широковещательным по умолчанию, если явно не указать параметр broadcast как true при его вызове.
• Входные параметры события всегда должны устанавливаться в конструкторе. Опциональные входные параметры тоже — используйте для них необязательные аргументы.
• Документируйте ваш класс события должным образом. Пишите, что он делает или что он должен представлять. Если свойство предназначено для входного и/или выходного параметра, укажите это в комментарии.

​

Часто задаваемые вопросы по ECS