Нодовая архитектура на Unity

Привет, Хабр! ?

Меня зовут Игорь, и я Unity Developer. В этой статье я хотел бы поделиться кастомной архитектурой, которую сделал в процессе разработки своей RTS игры.

Скажу сразу: что основные концепции и принципы уже используются в различных DI фреймворках, таких как Zenject & VContainer. Поэтому чего-то феноменального в этой статье вы не увидите. Но, поскольку я люблю делать свои велосипеды, то в свою архитектуру я привнес парочку интересных вещей, которых нет в других DI фреймворках на Unity. Ну шо, поехали 🙂

Введение

Итак, в начале разработки своей RTS игры, я уже понимал, что в моем проекте архитектура должна выполнять ряд требований. Ключевое из них — это быть простой и понятной, чтобы я, как разработчик, фокусировался на написании бизнес-логики, а не на инфраструктурных вещах. Вот какие у меня получились критерии:

1. Архитектура должна использовать Dependency Injection. По своему 5-ти летнему опыту разработки игр скажу, что использование механизма внедрения зависимостей увеличивает поддержку и тестируемость код-базы, поскольку каждый класс содержит в себе только бизнес-логику и необходимые зависимости. Когда есть DI, то не нужно создавать синглтоны на каждый чих или получать доп. зависимость на сервис-локатор. Использование архитектуры с DI упрощает поиск багов в классах, поскольку все зависимости определены в его конструкторе или методе пост-инъекции Construct().

2. Архитектура должна реализовывать механизм обработки игровых событий. Любая игра — это процесс. Поэтому у игры должны быть события и состояния старта, паузы, окончание и так далее. Поэтому было бы здорово иметь систему, которая может переключать состояния игры и оповещать об этом всех подписчиков.

3. Архитектура по-минимуму должна зависеть от монобехов. Считаю, что это очень хорошая практика писать код без монобехов, потому что обычные C# классы более гибкие в использовании, их легче тестировать, проще переиспользовать, так как они не завязаны на GameObject’ы и монобехи. И еще такой подход дает небольшой буст к оптимизации памяти и производительности.

4. Архитектура должна поддерживать несколько игроков. Поскольку игра будет мультиплеерной / против ИИ, то очень важно сделать так, чтобы у каждого игрока была своя подсистема контроллеров, менеджеров и игровых объектов, которыми он управляет.

Таким образом, у меня получилась своя нодовая архитектура, которая решает все эти задачи. Ну что ж, давайте смотреть 🙂

Что такое нодовая архитектура

Если говорить вкратце, нодовая архитектура — это архитектура, которая представлена в виде дерева-графа, где узлами являются домены, а ребрами — отношения между этими доменами: родительский / дочерний. Каждый домен является своего рода контекстом, который содержит в себе зарегистрированные компоненты системы и выполняет над ними инфраструктурную логику.

Приведу простой пример:

Давайте предположим, что мы делаем стратегию, в которой 2 игрока играют друг против друга. У каждого игрока есть своя армия, свои ресурсы, свои контроллеры управления и свой интерфейс. Также в игре есть и глобальные системы, например, система спауна игровых объектов или сервис, через который можно найти любой игровой объект на сцене.

Таким образом у нас есть дерево, которое состоит из родительского контекста игры и двух дочерних узлов игроков.

Таким образом, на домене каждого игрока будут располагаться локальные компоненты, а на домене игры — глобальные.

//Домен игры с глобальными компонетами public sealed class GameContext : ContextNode {     //Регистрируем зависимости:     protected override void OnInstall()     {         this.RegisterInstance(new ObjectSpawner()); //Создает объекты на сцене         this.RegisterInstance(new ObjectService()); //Ищет объекты на сцене         //И так далее...     } }

//Домен каждого игрока с локальными компонентами public sealed class PlayerContext : ContextNode {     //Регистрируем зависимости:     protected override void OnInstall()     {         this.RegisterInstance(new PlayerResources()); //Ресурсы игрока         this.RegisterInstance(new PlayerUnitStack()); //Выделенные юниты         this.RegisterInstance(new PlayerInput()); //Управление вводом         this.RegisterInstance(new PlayerInterface()); //Интерфейс         //И так далее...     } }

Поскольку в архитектуре используется механизм внедрения зависимостей, то ключевая задача заключается в том, чтобы каждый компонент системы правильно получил свои зависимости. И вот как он выглядит:

Когда происходит DI, то первым делом внедрение зависимостей заходит в корень дерева, а затем распространяется по дочерним узлам. Но при этом компоненты дочерних узлов могут получать зависимости, как на своем домене, так и на родительских.

Такой подход очень удобен, потому что можно легко масштабировать кол-во игроков в игре, не переписывая код-архитектуры.

Теперь приведу более конкретный пример из разработки своей RTS игры. Например, у каждого игрока есть стек выделенных юнитов, которыми он управляет. Чтобы отдать приказ юнитам переместиться в определенную точку на карте, нужен класс PlayerUnitMover, который и будет выполнять эту ответственность.

public sealed class PlayerUnitMover  {     // Зарегистрирован в домене игрока     private readonly PlayerUnitStack unitStack;       //Зарегистрирован в домене игры     private readonly ObjectManager objectManager;      //Метод пост-инъекции, куда приходят зависимости:     [GameInject]     public void Construct(       PlayerUnitStack unitStack,       ObjectManager objectManager     )     {         this.unitStack = unitStack;         this.objectManager = objectManager;     }      public void MoveSelectedUnits(Vector3 destination)     {         if (this.unitStack.IsNotEmpty())         {             var selectedUnits = this.unitStack.GetUnits();             this.objectManager.MoveObjects(selectedUnits, destination);         }       } }

Класс PlayerUnitMover отвечает за перемещение выделенных юнитов у конкретного игрока, которые находятся в классе PlayerUnitStack, а ObjectManager отдает различные приказы игровым объектом, которые существуют на сцене, на более низком уровне (на ECS), и ему не важно, кто отдал приказ конкретным юнитам.

В метод пост-инъекции Construct(), происходит внедрение зависимостей через аргументы метода. Зависимость на компонент PlayerUnitStack — получает из того же домена игрока, а ObjectManager — из домена игры.

В целом такой подход уже реализован в фреймворках Zenject и VContainer, поэтому построение игры в виде дерева подсистем используется достаточно часто.

Пуш игровых событий

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

Поэтому в моей архитектуре пришлось реализовать систему пуша игровых событий по всему дереву.

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

Приведу пример, как это сделано в моей архитектуре, на примере контроллера выбора юнита левой кнопкой мыши.

public sealed class ClickUnitController {     private MouseInput mouseInput; //Инпут мыши     private UnitSelector unitSelector; //Выделяет юнита      //Вызывается, когда происходит инициализация игры     [GameInject]     public void Construct(MouseInput mouseInput, UnitSelector unitSelector)     {       this.mouseInput = mouseInput;       this.unitSelector = unitSelector;     }      //Вызывается, когда происходит старт игры     [GameStart]     public void Enable()     {         this.mouseInput.OnLeftButtonClicked += this.OnLeftButtonClicked;     }       //Вызывается, когда происходит окончание игры     [GameFinish]     public void Disable()     {         this.mouseInput.OnLeftButtonClicked -= this.OnLeftButtonClicked;     }      private void OnLeftButtonClicked(Vector2 clickPosition)     {         this.unitSelector.SelectUnit(clickPosition);     } }

В данном классе ClickUnitController есть методы Enable(), Disable(), которые вызываются в момент старта и завершения игры. Аннотации [GameStart], [GameFinish] можно придумывать в самому в зависимости от системы игры, наследуясь от базового атрибута ContextEvent:

//Абстрактное событие [MeansImplicitUse(ImplicitUseKindFlags.Access)] [AttributeUsage(AttributeTargets.Method)] public abstract class ContextEvent : Attribute { }

Например, в моем проекте есть следующие события-аннотации:

//Событие внедрения зависимостей public sealed class GameInject : ContextEvent { }  //Событие старта игры public sealed class GameStart : ContextEvent { }  //Событие паузы игры public sealed class GamePause : ContextEvent { }  //Событие возобновления игры public sealed class GameResume : ContextEvent { }  //Событие завершения игры public sealed class GameFinish : ContextEvent { }

Чтобы пушнуть то или иное событие игры, достаточно получить ссылку на родительский узел и вызвать метод ContextNode.PushEvent<T>();

//Менеджер игры: public sealed class GameManager : MonoBehaviour {     [SerializeField]     private ContextNode context; //Корневой узел       public void ConstructGame()     {         this.context.PushEvent<GameInject>();     }      public void StartGame()     {         this.context.PushEvent<GameStart>();     }      public void PauseGame()     {         this.context.PushEvent<GamePause>();     }      public void ResumeGame()     {         this.context.PushEvent<GameResume>();     }      public void FinishGame()     {         this.context.PushEvent<GameFinish>();     } }

Особенность такого подхода заключается в том, что когда происходит пуш события, то вместе с ним происходит и внедрение зависимостей. То есть, если сделать метод Enable() с аргументом MouseInput, то при вызове события [GameStart] произойдет Dependency Injection.

[GameStart] public void Enable(MouseInput mouseInput) {     mouseInput.OnLeftButtonClicked += this.OnLeftButtonClicked; }

Таким образом, мы сразу убиваем двух зайцев: и события игры вызываем и зависимости внедряем 😉

Уход от монобехов. Один апдейт на всю игру

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

Проблема в том, что когда над Unity проектом работает больше 10 человек одновременно, то возникают сложности работы со сценами и объектами, поскольку помимо разработки компонентов системы и настройки их на сцене есть еще гейм-дизайнеры и левел-дизайнеры, которые настраивают баланс, собирают уровни на сцене и так далее. Поэтому хорошим решением будет разделить зоны ответственности в команде так, чтобы программисты решали все свои задачи в коде, а дизайнерам и художникам отдать сцены на растерзание…

К тому же классы монобехи занимают больше памяти, а вызов апдейта у каждого скрипта требует больше производительности. Поэтому такие системные классы, как контроллеры, менеджеры и сервисы написаны на обычных C# классах, а монобехи используются только в тех случаях, когда действительно нужно обработать Unity событие, например, OnTriggerEnter/Exit или OnCollisionEnter/Exit и так далее.

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

public sealed class RectSelectionInput : IContextUpdate {     public event Action OnStarted;     public event Action OnFinished;          private MouseInput mouse;      private bool isSelecting;     private Vector2 startPoint;     private Vector2 endPoint;      [GameInject]     public void Construct(MouseInput mouse)     {         this.mouse = mouse;     }      //Вызывается вместо Update     void IContextUpdate.OnUpdate()     {         var buttonState = this.mouse.LeftButton;         if (buttonState == MouseInput.ButtonState.DOWN)         {             this.isSelecting = true;             this.startPoint = this.mouse.Position;             this.endPoint = this.startPoint;             this.OnStarted?.Invoke();         }         else if (buttonState == MouseInput.ButtonState.PRESS)         {             this.endPoint = this.mouse.Position;         }         else if (buttonState == MouseInput.ButtonState.UP)         {             this.isSelecting = false;             this.endPoint = this.mouse.Position;             this.OnFinished?.Invoke();         }     } }

В данном примере, мы видим, что класс RectSelectionInput реализует интерфейс IContextUpdate, через который архитектура вызывает метод Update(). Таким образом, вместо того, чтобы писать монобехи, достаточно реализовать один из интерфейсов:

//Вызывает Update public interface IContextUpdate {     void OnUpdate(); }  //Вызывает FixedUpdate public interface IContextFixedUpdate {     void OnFixedUpdate(); }  //Вызывает LateUpdate public interface IContextLateUpdate {     void OnLateUpdate(); }

На самом деле, вызов апдейтов в архитектуре происходит практически таким же образом, как и отправка событий. Вызов Update() распространяется по всем узлам, начиная с корневого, и компонентам системы, которые реализуют эти интерфейсы.

Чтобы вызвать апдейт, достаточно получить ссылку на родительский узел и вызвать метод ContextNode.OnUpdate();

//Менеджер игры public sealed class GameManager : MonoBehaviour {     [SerializeField]     private ContextNode context; //Корневой узел       //Unity callback     private void Update()     {         this.context.OnUpdate();     }      //Unity callback     private void FixedUpdate()     {         this.context.OnFixedUpdate();     }      //Unity callback     private void LateUpdate()     {         this.context.OnLateUpdate();     } }

Результат: ContextNode в 380 строк

Итак, фактически вся архитектура держится на одном классе ContextNode. ContextNode представляет собой домен, который имеет список дочерних доменов и ссылку на родительский домен. Дальше можно прочитать код самому:

public class ContextNode : MonoBehaviour {     [SerializeField]     private List<ContextNode> children; //Дочерние узлы     private ContextNode parent; //Родительский узел      //Зарегистрированные зависимости     private readonly List<object> instances = new();     private readonly List<IContextUpdate> updaters = new();     private readonly List<IContextFixedUpdate> fixedUpdaters = new();     private readonly List<IContextLateUpdate> lateUpdaters = new();      #region Install      //Инициализация дерева     public void Install()     {         this.OnInstall();          for (int i = 0, count = this.children.Count; i < count; i++)         {             var node = this.children[i];             node.parent = this;             node.Install();         }     }      //Деинициализация дерева     public void Uninstall()     {         for (int i = 0, count = this.children.Count; i < count; i++)         {             var node = this.children[i];             node.parent = null;             node.Uninstall();         }          this.OnUninstall();     }      //Использовать для регистрации зависимостей в наследниках     protected virtual void OnInstall()     {     }      protected virtual void OnUninstall()     {     }      #endregion      #region Register      //Регистрирует зависимости в домен     public void RegisterInstances(IEnumerable<object> instances)     {         foreach (var instance in instances)         {             this.RegisterInstance(instance);         }     }      public void RegisterInstance(object instance)     {         if (instance == null)         {             return;         }          this.instances.Add(instance);          if (instance is IContextUpdate updater)         {             this.updaters.Add(updater);         }          if (instance is IContextFixedUpdate fixedUpdater)         {             this.fixedUpdaters.Add(fixedUpdater);         }          if (instance is IContextLateUpdate lateUpdater)         {             this.lateUpdaters.Add(lateUpdater);         }     }      #endregion      #region Push      //Отправляет событие во все компоненты, которые зарегистрированы в домене     public void PushEvent<T>() where T : ContextEvent     {         this.PsuhEventToInstances<T>();          for (int i = 0, count = this.children.Count; i < count; i++)         {             var node = this.children[i];             node.PushEvent<T>();         }     }      private void PsuhEventToInstances<T>() where T : ContextEvent     {         for (int i = 0, count = this.instances.Count; i < count; i++)         {             var instance = this.instances[i];             this.PushEventToInstance<T>(instance);         }     }      //Отправляет событие в компонент через рефлексию      private void PushEventToInstance<T>(object instance) where T : ContextEvent     {         var type = instance.GetType();         while (type != null && type != typeof(object) && type != typeof(MonoBehaviour))         {             var methods = type.GetMethods(                 BindingFlags.Instance |                 BindingFlags.Public |                 BindingFlags.NonPublic |                 BindingFlags.DeclaredOnly             );              for (int i = 0, count = methods.Length; i < count; i++)             {                 var method = methods[i];                 if (method.GetCustomAttribute<T>() != null)                 {                     this.InvokeInstanceMethod(instance, method);                 }             }              type = type.BaseType;         }     }      //Вызывает событие у метода компонента через рефлексию + делает DI     private void InvokeInstanceMethod(object instance, MethodInfo method)     {         var parameters = method.GetParameters();         var count = parameters.Length;          var args = new object[count];         for (var i = 0; i < count; i++)         {             var parameter = parameters[i];             args[i] = this.ResolveInstance(parameter.ParameterType);         }          method.Invoke(instance, args);     }      #endregion      #region Instances      //Ищет зависимость в домене или у родителей     public T ResolveInstance<T>()     {         var node = this;         while (node != null)         {             if (node.FindInstance<T>(out var instance))             {                 return instance;             }              node = node.parent;         }          throw new Exception($"Can't resolve instance {typeof(T).Name}!");     }      public object ResolveInstance(Type type)     {         if (type == typeof(ContextNode))         {             return this;         }          var node = this;         while (node != null)         {             if (node.FindInstance(type, out var instance))             {                 return instance;             }              node = node.parent;         }          throw new Exception($"Can't resolve instance {type.Name}!");     }      public IEnumerable<T> ResolveInstances<T>()     {         var node = this;         while (node != null)         {             if (node.FindInstance<T>(out var instance))             {                 yield return instance;             }              node = node.parent;         }     }          //Создает объект через конструктор и внедряет туда зависимости     public T NewInstance<T>()     {         var objectType = typeof(T);         var constructors = objectType.GetConstructors(             BindingFlags.Instance |             BindingFlags.Public |             BindingFlags.DeclaredOnly         );          if (constructors.Length != 1)         {             throw new Exception($"Undefined constructor for type {objectType.Name}");         }          var constructor = constructors[0];         var parameters = constructor.GetParameters();         var args = new object[parameters.Length];          for (int i = 0, count = parameters.Length; i < count; i++)         {             var parameter = parameters[i];             args[i] = this.ResolveInstance(parameter.ParameterType);         }          return (T) constructor.Invoke(args);     }      private bool FindInstance<T>(out T instance)     {         for (int i = 0, count = this.instances.Count; i < count; i++)         {             var current = this.instances[i];             if (current is T tInstance)             {                 instance = tInstance;                 return true;             }         }          instance = default;         return false;     }      private bool FindInstance(Type targetType, out object instance)     {         for (int i = 0, count = this.instances.Count; i < count; i++)         {             instance = this.instances[i];             var instanceType = instance.GetType();             if (targetType.IsAssignableFrom(instanceType))             {                 return true;             }         }          instance = default;         return false;     }      #endregion      #region Node      //Можно получить дочерние узлы по типу     public T[] GetChildren<T>()     {         var result = new List<T>();          for (int i = 0, count = this.children.Count; i < count; i++)         {             var node = this.children[i];             if (node is T tNode)             {                 result.Add(tNode);             }         }          return result.ToArray();     }      //Можно найти дочерний узел по условию     public T GetChild<T>(Predicate<T> predicate = null) where T : ContextNode     {         if (predicate == null)         {             predicate = _ => true;         }          for (int i = 0, count = this.children.Count; i < count; i++)         {             var node = this.children[i];             if (node is not T tNode)             {                 continue;             }              if (predicate.Invoke(tNode))             {                 return tNode;             }         }          throw new Exception($"Node of type {typeof(T).Name} is not found!");     }      public void AddChild(ContextNode node)     {         this.children.Add(node);         node.parent = this;         node.Install();     }      public void RemoveChild(ContextNode node)     {         if (this.children.Remove(node))         {             node.parent = null;         }     }      #endregion      #region Unity      //Можно вызывать     public virtual void OnUpdate()     {         for (int i = 0, count = this.updaters.Count; i < count; i++)         {             var listener = this.updaters[i];             listener.OnUpdate();         }          for (int i = 0, count = this.children.Count; i < count; i++)         {             var child = this.children[i];             child.OnUpdate();         }     }      public virtual void OnFixedUpdate()     {         for (int i = 0, count = this.fixedUpdaters.Count; i < count; i++)         {             var listener = this.fixedUpdaters[i];             listener.OnFixedUpdate();         }          for (int i = 0, count = this.children.Count; i < count; i++)         {             var child = this.children[i];             child.OnFixedUpdate();         }     }      public virtual void OnLateUpdate()     {         for (int i = 0, count = this.lateUpdaters.Count; i < count; i++)         {             var listener = this.lateUpdaters[i];             listener.OnLateUpdate();         }          for (int i = 0, count = this.children.Count; i < count; i++)         {             var child = this.children[i];             child.OnLateUpdate();         }     }      #endregion }

Выводы

Вот мы и рассмотрели реализацию нодовой архитектуры, которая решает поставленные задачи:

• Использование Dependency Injection

• Обработка игровых событий

• Слабо-связанна с Unity

• Поддерживает несколько игроков

На мой взгляд решение получилось лаконичным в 400 строк кода и три скрипта:

И все-таки меня часто спрашивают: «Почему своя архитектура, а не Zenject или VContainer?»

Ответ: Я просто люблю свои велосипеды, потому что свое решение всегда можно улучшить и адаптировать под нужды проекта. Использование DI фреймворка — тоже хорошо, но важно помнить, что фреймворк всегда накладывает ограничения, и их нужно понимать при проектировании архитектуры.

На этом все, спасибо за внимание! 🙂

---

Тем, кто глубоко интересуется разработкой игр, хочу порекомендовать онлайн‑курсы от OTUS, где практикующие эксперты делятся самой актуальной информацией. В рамках курсов также проходят бесплатные уроки, на которые может зарегистрироваться любой желающий. Вот ближайшие из них:

• 12 октября: Состояния игровых объектов

• 18 октября: Рабочие будни игрового сценариста и нарративного дизайнера — на примере Ведьмак 3 Дикая Охота

• 26 октября: Профессия разработчик на Unreal Engine: задачи и перспективы

• 2 ноября: Тестировщик игр: настоящее и будущее профессии в 2023 году