Unity3D Структура кода GameObject

Question

Я возился в Unity3D, создавая 2D-проект. Я хочу создать свою собственную архитектуру кода для системы на основе компонентов Unity.

Поскольку я не хочу создавать сценарии God-Controller и больше использовать решения разделения разделителей кода (имея в виду MVC, MVVM), я пытаюсь найти хорошее решение.

Мой первый дубль выглядит следующим образом:

GameObject создается из:

компоненты Unity - напр. SpriteRenderer, аниматор, Rigidbody2D

контроллер - только resposibility этого компонента для обработки функций Unity (как Update, FixedUpdate, OnCollision), и выполняет функции от модели.

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

Мне интересно, что вы думаете об этом aproach, каковы ваши кодовые habbits в проектах Unity3D и какие решения сработали для вас.

Answer 1

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

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

Если у проекта есть фиксированные уровни, я сделаю каждый уровень сценой, и я сохраню макет уровня и другую информацию о конкретном уровне в сцене. Если я выполняю более процедурный проект, я создам объект «LevelGenerator» со сценариями компонентов, которые собирают и заполняют уровень во время выполнения.

Если я создаю систему, в которой есть много преимущественно независимых агентов (, например, например, вражеских существ) Я стараюсь поддерживать логику игры и необходимую информацию о состоянии для каждого агента, как можно ближе к ней в иерархии. Например, положение и вращение агента будут сохранены в его преобразовании. Я могу хранить агенты, здоровье, боеприпасы, скорость и текущие статусные эффекты, а также функции перемещения, стрельбы, исцеления и смерти в сценарии компонентов в GameObject агента.

Хотя существует бесчисленное множество других подходов, которые могли бы работать, мне нравится этот подход к нескольким причинам:

• Это избавляет меня от необходимости вручную управлять тонн доступа к данным в центральном сценарии. Если мне нужно знать, где все монстры, я могу просто сохранить список игровых объектов, а не использовать пользовательские типы данных.
• Когда агент уничтожается, все локальные данные идут вместе с ним. (Нет сложных функций для очистки мертвых агентов.)
• С точки зрения игровой логики (на проектах, которые я обычно работаю) обычно имеет смысл, что каждый агент будет «знать» о себе, а не о всех остальных.
• Я по-прежнему могу использовать все полезные свойства, такие как полиморфизм и т. Д., Когда это необходимо.

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

---

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

Answer 2

Я использую другой подход.

1. Я не использую много контроллеров, прикрепленных к игровым объектам. У меня просто есть какой-то GameController, который создает другие структуры.

2. У меня есть отдельный проект, который можно использовать в других играх. Этот проект содержит шаблоны проектирования и строится до того, как основной проект был выполнен. Я широко использую шаблоны State, Observer, Builder, ObjectPool и т. Д., Чтобы сделать мой код ясным и простым.

3. Еще одна причина, по которой я использую такой подход, - оптимизация производительности. Я создаю объекты один раз, а затем повторно их использую. Также я делаю такие вещи, как gameObject.GetComponent и т. Д. Когда мне нужно создать много объектов с использованием одного и того же префава, я использую ObjectPool, чтобы избежать CreateInstance/Destroy.

4. Мои логические игровые объекты (актеры) обмениваются данными друг с другом с использованием шаблона Observer. Мой единственный GameController просто посылает такие события, как Awake, Update для актеров. Некоторые объекты имеют StateController, которые ретранслируют события типа Awake и Update в текущее состояние объекта. Это полезно для разделения поведения каждого состояния объекта.

5. У меня есть архитектура системы компонентов, похожая на Unity. И у меня также есть такие сервисы, как InputService, к которым можно получить доступ через ServiceLocator в любом объекте.

У меня также есть пункты, но идея понятна и проста в обслуживании. Это сложно с помощью стандартных контроллеров Unity и метода SendMessage.