[Перевод] Советы и рекомендации по работе с Unity3D14.10.2016 17:03

2b069053fc8346048e303f60b445d1cc.png

Я опубликовал первую статью »50 советов по работе с Unity» 4 года назад. Несмотря на то, что бóльшая её часть всё ещё актуальна, многое изменилось по следующим причинам:

  • Unity стал лучше. Например, теперь я могу доверять счётчику FPS. Возможность использования Property Drawers снизила необходимость написания пользовательских редакторов (Custom Editors). Способ работы с префабами стал меньше требовать заданных встроенных префабов (nested prefabs) и их альтернатив. Скриптуемые объекты стали более дружелюбными.
  • Улучшилась интеграция с Visual Studio, отладка стала намного проще и уменьшилась потребность в «обезьяньем» дебаггинге.
  • Стали лучше сторонние инструменты и библиотеки. В Asset Store появилось очень много ассетов, упрощающих такие аспекты, как визуальная отладка и логирование. Большая часть кода нашего собственного (бесплатного) плагина Extensions описана в моей первой статье (и многое из него описано здесь).
  • Усовершенствован контроль версий. (Но, может быть, я просто научился использовать его более эффективно). Например, теперь не нужно создавать множественные или резервные копии для префабов.
  • Я стал более опытным. За последние 4 года я поработал над многими проектами в Unity, в том числе над кучей прототипов игр, завершёнными играми, такими как Father.IO, и над нашим основным ассетом Unity Grids.

Эта статья является версией первоначальной статьи, переработанной с учётом всего вышеперечисленного.

Прежде чем перейти к советам, сначала я оставлю небольшое примечание (такое же, как и в первой статье). Эти советы подходят не ко всем проектам Unity:
  • Они основаны на моём опыте работы над проектами в составе небольших команд (от 3 до 20 человек).
  • У структурированности, возможности повторного использования, ясности кода и других аспектов есть своя цена: от размера команды, объёма проекта и целей проекта зависит то, стоит ли платить эту цену. Например, для геймджема вы всё это использовать не будете.
  • Использование многих советов — вопрос вкуса (возможно, есть отличающиеся, но всё равно хорошие техники для любого из перечисленных здесь советов).

На сайте Unity также есть рекомендации по работе над проектами (однако большинство из них направлены на повышение производительности проектов) (все они на английском):
  • Best Practices
  • Best practices for physically based content creation https://youtu.be/OeEYEUCa4tI
  • 2D Best practices in Unity https://youtu.be/HM17mAmLd7k
  • Internal Unity tips and tricks https://youtu.be/Ozc_hXzp_KU
  • Unity Tips and Tricks https://youtu.be/2S6Ygq58QF8
  • http://docs.unity3d.com/Manual/HOWTO-ArtAssetBestPracticeGuide.html

Рабочий процесс


1. С самого начала определитесь с масштабом и создавайте всё одного масштаба. Если вы этого не сделаете, возможно, позже вам придётся переделывать ассеты (например, анимация не всегда правильно масштабируется). Для 3D-игр наверно лучше всего принять 1 единицу Unity равной 1 метру. Для 2D-игр, не использующих освещение и физику, обычно подходит 1 единица Unity, равная 1 пикселю (в «рабочем» разрешении). Для UI (и 2D-игр) выберите рабочее разрешение (мы используем HD или 2xHD) и создавайте все ассеты под масштаб в этом разрешении.

2. Сделайте каждую сцену запускаемой. Это позволит вам не переключаться между сценами для запуска игры и ускорит таким образом процесс тестирования. Это может быть сложным, если вы используете передаваемые между загрузками сцен (persistent) объекты, которые требуются во всех сценах. Один из способов добиться этого — сделать передаваемые объекты синглтонами, которые будут загружать себя сами, если они отсутствуют в сцене. Синглтоны подробнее рассматриваются в другом совете.

3. Применяйте контроль исходного кода и научитесь использовать его эффективно.

  • Сериализируйте ассеты как текст. На самом деле это не сделает сцены и префабы более совместимыми, но при этом будет проще отслеживать изменения.
  • Освойте стратегию обмена сценами и префабами. Обычно над сценой или префабом не должны работать несколько человек. В маленькой команде перед началом работы над сценой или префабом может быть достаточно попросить всех не работать над ними. Может быть полезным использование физических токенов, обозначающих того, кто в текущий момент работает над сценой (вы можете работать над сценой, только если у вас на столе лежит соответствующий токен).
  • Используйте теги в качестве закладок.
  • Выберите стратегию ветвления и придерживайтесь её. Поскольку соединение сцен и префабов невозможно сделать плавным, организация ветвления может стать довольно сложной. Какой бы способ ветвления вы ни выбрали, он должен работать с вашей стратегией обмена сценами и префабами.
  • Используйте подмодули с осторожностью. Подмодули могут стать отличным способом поддержки повторно используемого кода, однако существует несколько опасностей:
    • Метафайлы для разных проектов в общем случае неодинаковы. Обычно это не является проблемой для кода, не использующего MonoBehaviour или скриптуемые объекты, однако для MonoBehaviour и скриптуемых объектов использование подмодулей может привести к утере кода.
    • Если вы работаете над несколькими проектами (один или несколько из которых используют подмодули), то иногда вы можете столкнуться с «лавиной обновлений», когда необходимо выполнить несколько итераций pull-merge-commit-push для разных проектов, чтобы стабилизировать код во всех проектах (а если во время этого процесса кто-то ещё вносит изменения, лавина может стать непрерывной). Одним из способов минимизации этого эффекта является внесение изменений в подмодули из проектов, которые к ним относятся. При этом проекты, использующие подмодули, должны будут всегда выполнять pull, и им никогда не придётся делать push.

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

5. Выполняйте обновление инструментов (в особенности Unity) одновременно. Unity уже гораздо лучше сохраняет связи при открытии проекта из отличных от текущей версий, однако связи всё равно иногда теряются, если члены команды работают в разных версиях.

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

  • Возможно возникновение коллизий (файлов или имён), особенно для ассетов, содержащих файлы в корне папки Plugins, или для тех, которые используют в своих примерах ассеты из Standard Assets.
  • Они могут быть неупорядоченными и раскидать свои файлы по всему вашему проекту. Это становится особенной проблемой, если вы решаете не использовать его и хотите удалить его.

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

1. Создайте новый проект и импортируйте ассет.
2. Запустите примеры и убедитесь, что они работают.
3. Упорядочьте ассет в более подходящую структуру папок. (Обычно я не подгоняю ассет под свою собственную структуру папок. Но я проверяю, что все файлы находятся в одной папке и что в важных местах нет файлов, которые могут перезаписать уже имеющиеся файлы моего проекта.)
4. Запустите примеры и убедитесь, что они всё ещё работают. (Иногда случалось, что ассет «ломался», когда я перемещал его составляющие, но обычно такой проблемы не возникает.)
5. Теперь удалите составляющие, которые вам не нужны (такие как примеры).
6. Убедитесь, что ассет по-прежнему компилируется и префабы всё ещё имеют все свои связи. Если осталось ещё что-то незапущенное, протестируйте его.
7. Теперь выберите все ассеты и экспортируйте пакет.
8. Импортируйте его в свой проект.

7. Автоматизируйте процесс сборки. Это полезно даже в небольших проектах, но в особенности это полезно, когда:

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

Информацию о том, как это сделать, читайте в Unity Builds Scripting: Basic and advanced possibilities.

8. Документируйте свои настройки. Бóльшая часть документации должна находиться в коде, но кое-что необходимо задокументировать за его пределами. Заставлять разработчиков рыться в коде в поисках настроек значит тратить их время. Документированные настройки повышают эффективность (если поддерживается актуальность документов). Документируйте следующее:

  • Использование тегов.
  • Использование слоёв (для коллизий, culling и raycasting — указывайте, что в каком слое должно быть).
  • Глубина GUI для слоёв (что над чем должно располагаться).
  • Настройки сцены.
  • Структура сложных префабов.
  • Выбранные идиомы.
  • Настройка сборки.

Общие советы по коду


9. Размещайте весь свой код в пространстве имён. Это позволяет избежать конфликта кода ваших собственных библиотек и стороннего кода. Но не полагайтесь на пространства имён, когда стремитесь избежать конфликтов кода с важными классами. Даже если вы используете другие пространства имён, не берите в качестве имён классов «Object», «Action» или «Event».

10. Используйте утверждения (assertions). Утверждения полезны для тестирования инвариантов в коде и помогают избавиться от логических багов. Утверждения доступны через класс Unity.Assertions.Assert. Они проверяют условие и записывают в консоль сообщение, если оно неверно. Если вы не знаете, для чего могут быть полезны утверждения см. The Benefits of programming with assertions (a.k.a. assert statements).

11. Не используйте строки ни для чего, кроме отображения текста. В частности, не используйте строки для идентификации объектов или префабов. Существуют исключения (в Unity всё ещё есть некоторые элементы, к которым можно получить доступ только через имя). В таких случаях определяйте такие строки как константы в файлах, таких как AnimationNames или AudioModuleNames. Если такие классы становятся неуправляемыми, применяйте вложенные классы, чтобы ввести что-то вроде AnimationNames.Player.Run.

12. Не используйте Invoke и SendMessage. Эти методы MonoBehaviour вызывают другие методы по имени. Методы, вызываемые по имени, тяжело отследить в коде (вы не сможете найти «Usages», а SendMessage имеет широкую область видимости, которую отследить ещё сложнее).

Можно легко написать собственную версию Invoke c помощью Coroutine и actions C#: 

public static Coroutine Invoke(this MonoBehaviour monoBehaviour, Action action, float time)
{
return monoBehaviour.StartCoroutine(InvokeImpl(action, time));
}

private static IEnumerator InvokeImpl(Action action, float time)
{
yield return new WaitForSeconds(time);

action();
}

Затем вы можете использовать её в MonoBehaviour таким образом: 
this.Invoke(ShootEnemy); //где ShootEnemy - это невозвращающий значения (void) метод без параметров.

(Дополнение: кто-то предложил использовать в качестве альтернативы класс ExecuteEvent, часть системы событий Unity. Пока я знаю о нём не так много, но похоже, что его стоит изучить подробнее.)

13. Не позволяйте спауненным (spawned) объектам запутывать иерархию при выполнении игры. Установите в качестве родителя для них объект в сцене, чтобы при выполнении игры было проще находить объекты. Можно использовать пустой (empty) игровой объект или даже синглтон (см. ниже в этой статье) без поведения (behaviour), чтобы проще было получать к нему доступ в коде. Назовите этот объект DynamicObjects.

14. Будьте точны при использовании null в качестве допустимых значений, и избегайте их там, где это возможно.

Значения null полезны при поиске некорректного кода. Однако если вы приобретёте привычку игнорировать null, некорректный код будет успешно выполняться и вы ещё долго не заметите ошибок. Более того, она может объявиться глубоко внутри кода, поскольку каждый слой игнорирует переменные null. Я стараюсь вообще не использовать null как допустимое значение.

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

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

Обычный сценарий часто используется для значений, настраиваемых в инспекторе. Пользователь может указать значение, но если он этого не сделает, будет использоваться значение по умолчанию. Лучший способ сделать это — использовать класс Optional‹T›, который оборачивает значения T. (Это немного похоже на Nullable‹T›.) Можно использовать специальный рендерер свойств для рендеринга поля с флажком и показывать поле значения только когда флажок установлен. (К сожалению, невозможно использовать непосредственно generic-класс, необходимо расширить классы для определённых значений T.)

[Serializable]
public class Optional
{
   public bool useCustomValue;
   public T value;
}

В своём коде вы можете использовать его таким образом: 
health = healthMax.useCustomValue ? healthMax.Value : DefaultHealthMax;

Дополнение: многие люди подсказывают мне, что лучше использовать struct (не создаёт мусора и не может быть null). Однако это означает, что вы не сможете использовать его в качестве базового класса для non-generic-классов так, чтобы применять его для полей, которые можно использовать в инспекторе.

15. Если вы используете корутины (Coroutines), научитесь использовать их эффективно. Корутины могут быть удобным способом решения многих проблем. Однако они сложны в отладке, и с их помощью вы можете легко превратить код в хаос, в котором никто, даже вы, не разберётся.

Вы должны понимать:

  • Как исполнять корутины параллельно.
  • Как исполнять корутины последовательно.
  • Как создавать новые корутины из существующих.
  • Как создавать собственные корутины с помощью CustomYieldInstruction.

//Это сама корутина
IEnumerator RunInParallel()
{
   yield return StartCoroutine(Coroutine1());
   yield return StartCoroutine(Coroutine2());
}

public void RunInSequence()
{
   StartCoroutine(Coroutine1());
   StartCoroutine(Coroutine1());
}

Coroutine WaitASecond()
{
   return new WaitForSeconds(1);
}

16. Используйте методы расширений для работы с компонентами, имеющими общий интерфейс. (Дополнение: Похоже, что GetComponent и другие методы теперь также работают и для интерфейсов, поэтому этот совет избыточен) Иногда удобно получать компоненты, реализующие определённый интерфейс или находить объекты с такими компонентами.

В реализации ниже используется typeof вместо generic-версий этих функций. Generic-версии не работают с интерфейсами, а typeof работает. Представленный ниже метод оборачивает его в generic-методы.

public static TInterface GetInterfaceComponent(this Component thisComponent)
   where TInterface : class
{
   return thisComponent.GetComponent(typeof(TInterface)) as TInterface;
}

17. Используйте методы расширения (extension methods), чтобы сделать синтаксис более удобным. Например: 
public static class TransformExtensions
{
   public static void SetX(this Transform transform, float x)
   {
      Vector3 newPosition =
         new Vector3(x, transform.position.y, transform.position.z);
 
      transform.position = newPosition;
   }
   ...
}

18. Используйте более «мягкую» альтернативу GetComponent. Иногда принудительное добавление зависимостей через RequireComponent может быть неприятным, оно не всегда возможно или приемлемо, в особенности когда вы вызываете GetComponent для чужого класса. В качестве альтернативы может использоваться следующее расширение GameObject, когда объект должен выдавать сообщение об ошибке, если он не найден.
public static T GetRequiredComponent(this GameObject obj) where T : MonoBehaviour
{
   T component = obj.GetComponent();
 
   if(component == null)
   {
      Debug.LogError("Ожидается компонент типа "
         + typeof(T) + ", но он отсутствует", obj);
   }
 
   return component;
}

19. Избегайте использования разных идиом для выполнения одинаковых действий. Во многих случаях существуют различные идиоматические способы выполнения действий. В таких случаях выберите одну идиому и используйте её для всего проекта. И вот почему:
  • Некоторые идиомы плохо совместимы. Использование одной идиомы направляет разработку в направлении, не подходящем для другой идиомы.
  • Использование одной идиомы для всего проекта позволяет участникам проекта лучше понимать происходящее. При этом структура и код становятся более понятными и снижается вероятность ошибок.

Примеры групп идиом:
  • Корутины — конечные автоматы.
  • Встроенные префабы — привязанные префабы — god-префабы.
  • Стратегии разделения данных.
  • Способы использования спрайтов для состояний в 2D-играх.
  • Структура префабов.
  • Стратегии спаунинга.
  • Способы нахождения объектов: по типу/имени/тегу/слою/ссылке.
  • Способы группировки объектов: по типу/имени/тегу/слою/массиву ссылок.
  • Способы вызова методов других компонентов.
  • Поиск групп объектов/self-registration.
  • Контроль порядка выполнения (использование настройки порядка выполнения Unity — yield-логики — Awake / Start и Update / Late Update — manual methods — произвольная архитектура
  • Выбор объектов / положений / целей в игре мышью: менеджер выбора — локальное самоуправление.
  • Хранение данных при смене сцен: через PlayerPrefs или с помощью объектов, которые не уничтожаются (Destroy) при загрузке новой сцены.
  • Способы сочетания (блендинг, добавление и наслаивание) анимации.
  • Обработка ввода (центральная — локальная)

20. Создайте и поддерживайте свой собственный класс времени, чтобы сделать работу с паузами удобнее. Оберните Time.DeltaTime и Time.TimeSinceLevelLoad для управления паузами и масштабом времени. Для использования класса требуется дисциплина, но он делает всё намного проще, в особенности при выполнении с различными счётчиками времени (например, анимации интерфейса и игровые анимации).

Дополнение: Unity поддерживает unscaledTime и unscaledDeltaTime, которые делают собственный класс времени избыточным во многих ситуациях. Но он всё равно может полезен, если масштабирование глобального времени влияет на компоненты, которые вы не писали нежелательными способами.

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

22. Используйте общую структуру для выполнения вызовов WWW. В играх с большим объёмом коммуникаций с сервером обычно существуют десятки вызовов WWW. Вне зависимости от того, используете ли вы сырой класс WWW Unity или плагин, удобно будет написать тонкий слой поверх, который будет работать как boilerplate.

Обычно я определяю метод Call (отдельно для Get и Post), корутину CallImpl и MakeHandler. В сущности, метод Call создаёт с помощью метода MakeHandler «суперобработчик» (super hander) из парсера, обработчик on-success и on-failure. Также он вызывает корутину CallImpl, которая формирует URL, выполняет вызов, ожидает его завершения, а потом вызывает «суперобработчик».

Вот как это приблизительно выглядит: 

public void Call(string call, Func parser, Action onSuccess, Action onFailure)
{
	var handler = MakeHandler(parser, onSuccess, onFailure);
	StartCoroutine(CallImpl(call, handler));
} 

public IEnumerator CallImpl(string call, Action handler)
{
	var www = new WWW(call);
	yield return www;
	handler(www);
}

public Action MakeHandler(Func parser, Action onSuccess, Action onFailure)
{
   return (WWW www) =>
   {
      if(NoError(www)) 
      {
         var parsedResult = parser(www.text);
         onSuccess(parsedResult);
      }
      else
      {
         onFailure("Текст ошибки");
      }
   }
}

У такого подхода есть несколько преимуществ.
  • Он позволяет избежать написания большого объёма boilerplate-кода
  • Он позволяет обрабатывать нужные элементы (например, отображение загружающегося компонента UI или обработка определённых общих ошибок) в первую очередь.

23. Если у вас много текста, поместите его в файл. Не помещайте его в поля для редактирования в инспекторе. Сделайте так, чтобы его можно было быстро менять, не открывая редактор Unity, и в особенности без необходимости сохранения сцены.

24. Если вы планируете локализацию, отделите все строки в одно место. Существует несколько способов сделать это. Один из них — это определить класс Text с строчным полем типа public для каждой строки, по умолчанию, например, будет установлен английский. Другие языки будут дочерними классам и повторно инициализируют поля с языковыми аналогами.

Более сложный способ (он подходит при большом объёме текста или высоком числе языков) — считывание электронной таблицы и создание логики для выбора нужной строки на основнии выбранного языка.

Дизайн классов
25. Решите, как будут использоваться инспектируемые поля, и сделайте это стандартом. Есть два способа: сделать поля public, или сделать их private и пометить как [SerializeField]. Последнее «более корректно», но менее удобно (и этот способ не очень популяризируется самой Unity). Что бы вы ни выбрали, сделайте это стандартом, чтобы разработчики в вашей команде знали, как интерпретировать поле public.
  • Инспектируемые поля являются public. В этом случае public означает: «переменная может безопасно изменяться дизайнером в процессе выполнения приложения. Не задавайте её значение в коде».
  • Инспектируемые поля являются private и помечены как Serializable. В этом случае public означает: «можно безопасно изменять эту переменную в коде» (поэтому их будет не очень много, а в MonoBehaviours и ScriptableObjects не будет полей public).

26. Никогда не делайте переменные компонентов public, если они не должны настраиваться в инспекторе. Иначе они будут изменяться дизайнером, в особенности если непонятно, что они делают. В некоторых редких случаях этого нельзя избежать (например, если какой-то скрипт редактора должен использовать переменную). В этом случае нужно использовать атрибут HideInInspector, чтобы скрыть её в инспекторе.

27. Используйте property drawers, чтобы сделать поля более удобными для пользователей. Property drawers можно использовать для настройки контролов (controls) в инспекторе. Это позволит вас создавать контролы, наиболее подходящие под вид данных и вставлять защиту (например ограничение значений переменных). Используйте атрибут Header для упорядочивания полей, а атрибут Tooltip — для предоставления дизайнерам дополнительной документации.

28. Отдавайте предпочтение property drawers, а не пользовательским редакторам (custom editors). Property drawers реализуются по типам полей, а значит, требуют гораздо меньше времени на реализацию. Их также удобнее использовать повторно — после реализации для типа их можно использовать для того же типа в любом классе. Пользовательские редакторы реализуются в MonoBehaviour, поэтому их сложнее использовать повторно и они требуют больше работы.

29. По умолчанию «запечатывайте» MonoBehaviours (применяйте модификатор sealed). В общем случае MonoBehaviours Unity не очень удобны для наследования:

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

В случаях, когда наследование необходимо, не используйте message-методов Unity, если этого можно избежать. Если вы всё-таки их используете, не делайте их виртуальными. При необходимости можно определить пустую виртуальную функцию, вызываемую из message-метода, которую дочерний класс может переопределить (override) для выполнения дополнительных действий.
public class MyBaseClass
{
   public sealed void Update()
   {
      CustomUpdate();
      ... // update этого класса 
   }

   //Вызывается до того, как этот класс выполняет свой update
   //Переопределение для выполнения вашего кода update.
   virtual public void CustomUpdate(){};
}

public class Child : MyBaseClass
{
   override public void CustomUpdate()
   {
      //Выполняем какие-то действия
   }
}

Это предотвратит случайное переопределение вашего кода классом, но всё равно позволяет задействовать сообщения Unity. Я не люблю такой порядок, потому что он становится проблематичным. В примере выше дочернему классу может потребоваться выполнение операций сразу после того, как класс выполнил собственный update.

30. Отделяйте интерфейс от игровой логики. Компоненты интерфейса в целом не должны ничего знать об игре, в которой они используются. Передавайте им данные, которые нужно отображать, и подпишите на события, проверяемые при взаимодействии пользователя с компонентами UI. Компоненты интерфейса не должны выполнять игровую логику. Они могут фильтровать вводимые данные, проверяя их правильность, но основные правила должны выполняться не в них. Во многих играх-головоломках элементы поля являются расширением интерфейса, и не должны содержать правил. (Например, шахматная фигура не должна рассчитывать разрешённые для неё ходы.)

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

Вот урезанный пример компонента UI, позволяющего пользователю выбрать оружие из заданного списка. Единственное, что знают эти классы об игре, это класс Weapon (и только потому, что класс Weapon — полезный источник данных, которые этот контейнер должен отображать). Игра тоже ничего не знает о контейнере; ей нужно только зарегистрировать событие OnWeaponSelect.

public WeaponSelector : MonoBehaviour
{
   public event Action OnWeaponSelect {add; remove; } 
   //GameManager может регистрировать это событие

   public void OnInit(List  weapons)
   {
      foreach(var weapon in weapons)
      {

          var button = ... //Создаёт дочернюю кнопку и добавляет её в иерархию          
 
          buttonOnInit(weapon, () => OnSelect(weapon)); 
          // дочерняя кнопка отображает опцию, 
          // и отправляет сообщение о нажатии этому компоненту
      }
   }
   public void OnSelect(Weapon weapon)
  {
      if(OnWepaonSelect != null) OnWeponSelect(weapon);
   }
}

public class WeaponButton : MonoBehaviour
{
    private Action<> onClick;

    public void OnInit(Weapon weapon, Action onClick)
    {
        ... //установка спрайта и текста оружия

        this.onClick = onClick;
    }

    public void OnClick() //Привязываем этот метод как OnClick компонента UI Button
    {
       Assert.IsTrue(onClick != null);  //Не должно происходить

       onClick();
    }    
}

31. Разделите конфигурацию, состояние и вспомогательную информацию.
  • Переменные конфигурации — это переменные, настраиваемые в объекте для определения объекта через его свойства. Например, maxHealth.
  • Переменные состояния — это переменные, полностью определяющие текущее состояние объекта. Это переменные, которые необходимо сохранять, если ваша игра поддерживает сохранение. Например, currentHealth.
  • Вспомогательные (bookkeeping) переменные используются для скорости, удобства и переходных состояний. Они могут быть целиком определены из переменных состояния. Например, previousHealth.

Разделив эти типы переменных, вы будете понимать, что можно изменять, что нужно сохранять, что нужно отправлять/получать по сети. Вот простой пример такого разделения.
public class Player
{
   [Serializable]
   public class PlayerConfigurationData
   {
      public float maxHealth;
   }

   [Serializable]
   public class PlayerStateData
   {
      public float health;
   }

   public PlayerConfigurationData configuration;
   private PlayerState stateData;

   //вспомогательная информация
   private float previousHealth;

   public float Health
   {
      public get { return stateData.health; }
      private set { stateData.health = value; }
   }
}

32. Не используйте связанные индексами массивы типа public. Например, не определяйте массив оружия, массив пуль и массив частиц таким образом: 
public void SelectWeapon(int index)
{ 
   currentWeaponIndex = index;
   Player.SwitchWeapon(weapons[currentWeapon]);
}
 
public void Shoot()
{
   Fire(bullets[currentWeapon]);
   FireParticles(particles[currentWeapon]);
}

Проблема здесь скорее не в коде, а в сложности безошибочной настройки в инспекторе.

Лучше определите класс, инкапсулирующий все три переменные, и создайте из него массив: 

[Serializable]
public class Weapon
{
   public GameObject prefab;
   public ParticleSystem particles;
   public Bullet bullet;
}

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

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

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

public void FireAttack()
{
   /// поведение
   Fire(bullets[0]);
}
 
public void IceAttack()
{
   /// поведение
   Fire(bullets[1]);
}
 
public void WindAttack()
{
   /// поведение
   Fire(bullets[2]);
}

Enums могут выглядеть красивее в коде…
public void WindAttack()
{
   /// behaviour
   Fire(bullets[WeaponType.Wind]);
}

…но не в инспекторе.

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

[Serializable]
public class Bullets
{
   public Bullet fireBullet;
   public Bullet iceBullet;
   public Bullet windBullet;
}

Это подразумевает, что других данных Fire, Ice и Wind нет.

34. Группируйте данные в сериализируемые классы, чтобы всё выглядело удобнее в инспекторе. Некоторые элементы могут иметь десятки настроек. Поиск нужной переменной может стать кошмаром. Чтобы упростить себе жизнь, следуйте этим инструкциям:

  • Определите отдельные классы для групп переменных. Сделайте их public и serializable
  • В основном классе определите public переменные каждого определённого выше типа.
  • Не инициализируйте эти переменные в Awake или Start; они сериализируемые, поэтому Unity позаботится о них сама.
  • Вы можете указать значения по умолчанию, назначив их при определении.

Так вы создадите сворачиваемые в инспекторе группы переменных, которыми легче управлять.
[Serializable]
public class MovementProperties //Не MonoBehaviour!
{
   public float movementSpeed;
   public float turnSpeed = 1; //указываем значение по умолчанию
}
 
public class HealthProperties //Не MonoBehaviour!
{
   public float maxHealth;
   public float regenerationRate;
}
 
public class Player : MonoBehaviour
{
   public MovementProperties movementProeprties;
   public HealthPorperties healthProeprties;
}

35. Сделайте не являющиеся MonoBehaviour классы Serializable, даже если они не используются для полей public. Это позволит просматривать поля класса в инспекторе, когда он находится в режиме Debug mode. Это работает и для вложенных классов (private или public).

36. Старайтесь не изменять в коде настраиваемые в инспекторе данные. Настраиваемая в инспекторе переменная — это переменная конфигурации, и с ней нужно обращаться как с константой при выполнении приложения, а не как с переменной состояния. Если вы будете соблюдать это правило, вам будет проще писать методы, сбрасывающие состояние компонента на первоначальное, при этом вы будете чётче понимать, что делает переменная.

public class Actor : MonoBehaviour
{
   public float initialHealth = 100;
   
   private float currentHealth;

   public void Start()
   {
      ResetState();
   }   

   private void Respawn()
   {
      ResetState();
   } 

   private void ResetState()
   {
      currentHealth = initialHealth;
   }
}

Паттерны
Паттерны — это способы решения часто возникающих проблем стандартными методами. Книга Роберта Нистрома «Паттерны программирования игр» (можно прочитать её бесплатно онлайн) — ценный ресурс для понимания того, как паттерны применимы для решения проблем, возникающих при разработке игр. В самой Unity есть множество таких паттернов: Instantiate — это пример паттерна «прототип» (prototype); MonoBehaviour — это версия паттерна «шаблонный метод» (template), в UI и анимации используется паттерн «наблюдатель» (observer), а новый движок анимации использует конечные автоматы (state machines).

Эти советы относятся к использованию паттернов конкретно в Unity.

37. Используйте для удобства синглтоны (паттерн «одиночка»). Следующий класс автоматически сделает синглтоном любой наследующий его класс: 

public class Singleton : MonoBehaviour where T : MonoBehaviour
{
   protected static T instance;
 
   //Возвращает экземпляр этого синглтона.
   public static T Instance
   {
      get
      {
         if(instance == null)
         {
            instance = (T) FindObjectOfType(typeof(T));
 
            if (instance == null)
            {
               Debug.LogError("В сцене нужен экземпляр " + typeof(T) + 
                  ", но он отсутствует.");
            }
         }
 
         return instance;
      }
   }
}

Синглтоны полезны для менеджеров, например для ParticleManager, AudioManager или GUIManager.

(Многие программисты настроены против классов, расплывчато называемых XManager, потому что это указывает на то, что для класса выбрано плохое имя или у него слишком много несвязанных друг с другом задач. В целом, я с ними согласен. Однако в играх есть всего несколько менеджеров, и они выолняют в играх одни и те же задачи, так что эти классы фактически являются идиомами.)

  • Не используйте синглтоны для уникальных экземпляров префабов, не являющихся менеджерами (например, Player). Придерживайтесь этого принципа, чтобы не усложнять иерархию наследования и внесение определённых типов изменений. Лучше храните ссылки на них в GameManager (или в более подходящем классе God;-)).
  • Определите свойства static и методы для переменных и методов public, которые часто используются за пределами класса. Это позволит вам писать GameManager.Player вместо GameManager.Instance.player.

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

38. Используйте конечные автоматы (state machines) для создания различного поведения в разных состояниях или для выполнения кода при смене состояний. Лёгкий конечный автомат имеет множество состояний и для каждого состояния вы можете указать действия, выполняемые при входе или нахождении в состоянии, а также действие обновления. Это позволить сделать код более чистым и менее подверженным ошибкам. Хороший признак того, что вам пригодится конечный автомат: код метода Update содержит конструкции if или switch, изменяющие его поведение, или такие переменные как hasShownGameOverMessage.

public void Update()
{
   if(health <= 0)
   {
      if(!hasShownGameOverMessage) 
      {
         ShowGameOverMessage();
         hasShownGameOverMessage = true; //При респауне значение становится false
      }
   }
   else
   {
      HandleInput();
   }   
}

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

39. Используйте поля типа UnityEvent для создания паттерна «наблюдатель» (observer) в инспекторе. Класс UnityEvent позволяет связывать методы, которые получают до четырёх параметров в испекторе, с помощью того же интерфейса UI, что и события в Button

© Habrahabr.ru