- PVSM.RU - https://www.pvsm.ru -
Я опубликовал первую статью «50 советов по работе с Unity» [1] 4 года назад. Несмотря на то, что бóльшая её часть всё ещё актуальна, многое изменилось по следующим причинам:
Эта статья является версией первоначальной статьи, переработанной с учётом всего вышеперечисленного.
Прежде чем перейти к советам, сначала я оставлю небольшое примечание (такое же, как и в первой статье). Эти советы подходят не ко всем проектам Unity:
На сайте Unity также есть рекомендации по работе над проектами (однако большинство из них направлены на повышение производительности проектов) (все они на английском):
1. С самого начала определитесь с масштабом и создавайте всё одного масштаба. Если вы этого не сделаете, возможно, позже вам придётся переделывать ассеты (например, анимация не всегда правильно масштабируется). Для 3D-игр наверно лучше всего принять 1 единицу Unity равной 1 метру. Для 2D-игр, не использующих освещение и физику, обычно подходит 1 единица Unity, равная 1 пикселю (в «рабочем» разрешении). Для UI (и 2D-игр) выберите рабочее разрешение (мы используем HD или 2xHD) и создавайте все ассеты под масштаб в этом разрешении.
2. Сделайте каждую сцену запускаемой. Это позволит вам не переключаться между сценами для запуска игры и ускорит таким образом процесс тестирования. Это может быть сложным, если вы используете передаваемые между загрузками сцен (persistent) объекты, которые требуются во всех сценах. Один из способов добиться этого — сделать передаваемые объекты синглтонами, которые будут загружать себя сами, если они отсутствуют в сцене. Синглтоны подробнее рассматриваются в другом совете.
3. Применяйте контроль исходного кода и научитесь использовать его эффективно.
4. Всегда отделяйте тестовые сцены от кода. Выполняйте коммиты временных ассетов и скриптов в репозиторий и удаляйте их из проекта, когда закончите работу с ними.
5. Выполняйте обновление инструментов (в особенности Unity) одновременно. Unity уже гораздо лучше сохраняет связи при открытии проекта из отличных от текущей версий, однако связи всё равно иногда теряются, если члены команды работают в разных версиях.
6. Импортируйте ассеты сторонних разработчиков в чистый проект и импортируйте новый пакет для своего использования уже оттуда. При непосредственном импорте в проект ассеты иногда могут приводить к проблемам:
Чтобы ассеты были в большей безопасности, пользуйтесь следующими инструкциями:
1. Создайте новый проект и импортируйте ассет.
2. Запустите примеры и убедитесь, что они работают.
3. Упорядочьте ассет в более подходящую структуру папок. (Обычно я не подгоняю ассет под свою собственную структуру папок. Но я проверяю, что все файлы находятся в одной папке и что в важных местах нет файлов, которые могут перезаписать уже имеющиеся файлы моего проекта.)
4. Запустите примеры и убедитесь, что они всё ещё работают. (Иногда случалось, что ассет «ломался», когда я перемещал его составляющие, но обычно такой проблемы не возникает.)
5. Теперь удалите составляющие, которые вам не нужны (такие как примеры).
6. Убедитесь, что ассет по-прежнему компилируется и префабы всё ещё имеют все свои связи. Если осталось ещё что-то незапущенное, протестируйте его.
7. Теперь выберите все ассеты и экспортируйте пакет.
8. Импортируйте его в свой проект.
7. Автоматизируйте процесс сборки. Это полезно даже в небольших проектах, но в особенности это полезно, когда:
Информацию о том, как это сделать, читайте в Unity Builds Scripting: Basic and advanced possibilities. [14]
8. Документируйте свои настройки. Бóльшая часть документации должна находиться в коде, но кое-что необходимо задокументировать за его пределами. Заставлять разработчиков рыться в коде в поисках настроек значит тратить их время. Документированные настройки повышают эффективность (если поддерживается актуальность документов). Документируйте следующее:
9. Размещайте весь свой код в пространстве имён. Это позволяет избежать конфликта кода ваших собственных библиотек и стороннего кода. Но не полагайтесь на пространства имён, когда стремитесь избежать конфликтов кода с важными классами. Даже если вы используете другие пространства имён, не берите в качестве имён классов «Object», «Action» или «Event».
10. Используйте утверждения (assertions). Утверждения полезны для тестирования инвариантов в коде и помогают избавиться от логических багов. Утверждения доступны через класс Unity.Assertions.Assert [15]. Они проверяют условие и записывают в консоль сообщение, если оно неверно. Если вы не знаете, для чего могут быть полезны утверждения см. The Benefits of programming with assertions (a.k.a. assert statements) [16].
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 [17], часть системы событий Unity [18]. Пока я знаю о нём не так много, но похоже, что его стоит изучить подробнее.)
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), научитесь использовать их эффективно. Корутины могут быть удобным способом решения многих проблем. Однако они сложны в отладке, и с их помощью вы можете легко превратить код в хаос, в котором никто, даже вы, не разберётся.
Вы должны понимать:
//Это сама корутина
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. Избегайте использования разных идиом для выполнения одинаковых действий. Во многих случаях существуют различные идиоматические способы выполнения действий. В таких случаях выберите одну идиому и используйте её для всего проекта. И вот почему:
Примеры групп идиом:
20. Создайте и поддерживайте свой собственный класс времени, чтобы сделать работу с паузами удобнее. Оберните Time.DeltaTime и Time.TimeSinceLevelLoad для управления паузами и масштабом времени. Для использования класса требуется дисциплина, но он делает всё намного проще, в особенности при выполнении с различными счётчиками времени (например, анимации интерфейса и игровые анимации).
Дополнение: Unity поддерживает unscaledTime [21] и 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<T>(string call, Func<string, T> parser, Action<T> onSuccess, Action<string> onFailure)
{
var handler = MakeHandler(parser, onSuccess, onFailure);
StartCoroutine(CallImpl(call, handler));
}
public IEnumerator CallImpl<T>(string call, Action<T> handler)
{
var www = new WWW(call);
yield return www;
handler(www);
}
public Action<WWW> MakeHandler<T>(Func<string, T> parser, Action<T> onSuccess, Action<string> onFailure)
{
return (WWW www) =>
{
if(NoError(www))
{
var parsedResult = parser(www.text);
onSuccess(parsedResult);
}
else
{
onFailure("Текст ошибки");
}
}
}
У такого подхода есть несколько преимуществ.
23. Если у вас много текста, поместите его в файл. Не помещайте его в поля для редактирования в инспекторе. Сделайте так, чтобы его можно было быстро менять, не открывая редактор Unity, и в особенности без необходимости сохранения сцены.
24. Если вы планируете локализацию, отделите все строки в одно место. Существует несколько способов сделать это. Один из них — это определить класс Text с строчным полем типа public для каждой строки, по умолчанию, например, будет установлен английский. Другие языки будут дочерними классам и повторно инициализируют поля с языковыми аналогами.
Более сложный способ (он подходит при большом объёме текста или высоком числе языков) — считывание электронной таблицы и создание логики для выбора нужной строки на основнии выбранного языка.
25. Решите, как будут использоваться инспектируемые поля, и сделайте это стандартом. Есть два способа: сделать поля public, или сделать их private и пометить как [SerializeField]. Последнее «более корректно», но менее удобно (и этот способ не очень популяризируется самой Unity). Что бы вы ни выбрали, сделайте это стандартом, чтобы разработчики в вашей команде знали, как интерпретировать поле public.
26. Никогда не делайте переменные компонентов public, если они не должны настраиваться в инспекторе. Иначе они будут изменяться дизайнером, в особенности если непонятно, что они делают. В некоторых редких случаях этого нельзя избежать (например, если какой-то скрипт редактора должен использовать переменную). В этом случае нужно использовать атрибут HideInInspector [22], чтобы скрыть её в инспекторе.
27. Используйте property drawers, чтобы сделать поля более удобными для пользователей. Property drawers [23] можно использовать для настройки контролов (controls) в инспекторе. Это позволит вас создавать контролы, наиболее подходящие под вид данных и вставлять защиту (например ограничение значений переменных). Используйте атрибут Header [24] для упорядочивания полей, а атрибут Tooltip [25] — для предоставления дизайнерам дополнительной документации.
28. Отдавайте предпочтение property drawers, а не пользовательским редакторам (custom editors). Property drawers реализуются по типам полей, а значит, требуют гораздо меньше времени на реализацию. Их также удобнее использовать повторно – после реализации для типа их можно использовать для того же типа в любом классе. Пользовательские редакторы реализуются в MonoBehaviour, поэтому их сложнее использовать повторно и они требуют больше работы.
29. По умолчанию «запечатывайте» MonoBehaviours (применяйте модификатор sealed). В общем случае MonoBehaviours Unity не очень удобны для наследования:
В случаях, когда наследование необходимо, не используйте 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. Разделите конфигурацию, состояние и вспомогательную информацию.
Разделив эти типы переменных, вы будете понимать, что можно изменять, что нужно сохранять, что нужно отправлять/получать по сети. Вот простой пример такого разделения.
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. Группируйте данные в сериализируемые классы, чтобы всё выглядело удобнее в инспекторе. Некоторые элементы могут иметь десятки настроек. Поиск нужной переменной может стать кошмаром. Чтобы упростить себе жизнь, следуйте этим инструкциям:
Так вы создадите сворачиваемые в инспекторе группы переменных, которыми легче управлять.
[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;
}
}
Паттерны — это способы решения часто возникающих проблем стандартными методами. Книга Роберта Нистрома «Паттерны программирования игр» [26] (можно прочитать её бесплатно онлайн) — ценный ресурс для понимания того, как паттерны применимы для решения проблем, возникающих при разработке игр. В самой Unity есть множество таких паттернов: Instantiate — это пример паттерна «прототип» (prototype); MonoBehaviour — это версия паттерна «шаблонный метод» (template), в UI и анимации используется паттерн «наблюдатель» (observer), а новый движок анимации использует конечные автоматы (state machines).
Эти советы относятся к использованию паттернов конкретно в Unity.
37. Используйте для удобства синглтоны (паттерн «одиночка»). Следующий класс автоматически сделает синглтоном любой наследующий его класс:
public class Singleton<T> : 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, потому что это указывает на то, что для класса выбрано плохое имя или у него слишком много несвязанных друг с другом задач. В целом, я с ними согласен. Однако в играх есть всего несколько менеджеров, и они выолняют в играх одни и те же задачи, так что эти классы фактически являются идиомами.)
Как объяснено в других советах, синглтоны полезны для создания точек спауна по умолчанию и объектов, передаваемых между загрузками сцен и хранящих глобальные данные.
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, что и события в Buttons. Это особенно полезно при работе с вводом.
40. Используйте паттерн «наблюдатель», чтобы определять, когда изменяется значение поля. Проблема исполнения кода только при изменении переменной часто возникает в играх. Мы создали стандартное решение этой проблемы с помощью generic-класса, позволяющего регистрировать события изменения переменных. Ниже представлен пример со здоровьем. Вот как он создаётся:
/*Наблюдаемое значение*/ health = new ObservedValue(100);
health.OnValueChanged += () => { if(health.Value <= 0) Die(); };
Теперь вы можете менять его где угодно, не проверяя в каждом месте его значение, например, вот так:
if(hit) health.Value -= 10;
Когда здоровье становится ниже 0, вызывается метод Die. Подробные обсуждения и реализацию см. в этом посте [27].
41. Используйте для префабов паттерн Actor. (Это «нестандартный» паттерн. Основная идея взята из презентации [28] Кирана Лорда (Kieran Lord).)
Actor (актор) — это основной компонент префаба. Обычно это компонент, обеспечивающий «индивидуальность» префаба, и тот, с которым наиболее часто будет взаимодействовать код более высокого уровня. Actor часто использует другие компоненты – помощники (helpers) – для того же объекта (и иногда для дочерних объектов), чтобы выполнить свою работу.
При создании объекта «кнопка» через меню Unity создаётся игровой объект с компонентами Sprite и Button (и дочерний с компонентом Text). В этом случае актором будет являться Button. Главная камера также обычно имеет несколько компонентов (GUI Layer, Flare Layer, Audio Listener), прикреплённые к компоненту Camera. Camera здесь является актором.
Для правильной работы актора могут потребоваться другие компоненты. Можно сделать префаб более надёжным и полезным с помощью следующих атрибутов компонента-актора:
[RequiredComponent(typeof(HelperComponent))]
[DisallowMultipleComponent]
[SelectionBase]
public class Actor : MonoBehaviour
{
...//
}
42. Используйте генераторы случайных и паттернизированных потоков данных. (Это нестандартный паттерн, но мы считаем его чрезвычайно полезным.)
Генератор похож на генератор случайных чисел: это объект с методом Next, вызываемым для получения нового элемента определённого типа. В процессе конструирования генераторы можно изменять для создания широкого диапазона паттернов и различных типов случайности. Они полезны, потому что позволяют хранить логику генерирования нового элемента отдельно от участка кода, в котором нужен элемент, что делает код намного чище.
Вот несколько примеров:
var generator = Generator
.RamdomUniformInt(500)
.Select(x => 2*x); //Генерирует чётные числа от 0 до 998
var generator = Generator
.RandomUniformInt(1000)
.Where(n => n % 2 == 0); //Делает то же самое
var generator = Generator
.Iterate(0, 0, (m, n) => m + n); //Числа Фибоначчи
var generator = Generator
.RandomUniformInt(2)
.Select(n => 2*n - 1)
.Aggregate((m, n) => m + n); //Случайные скачки с шагом 1 или -1
var generator = Generator
.Iterate(0, Generator.RandomUniformInt(4), (m, n) => m + n - 1)
.Where(n >= 0); //Случайная последовательность, увеличивающая среднее
Мы уже использовали генераторы для спауна препятствий, смены цветов фона, процедурной музыки, генерирования последовательности букв для создания слов, как в играх со словами и для многого другого. С помощью следующей конструкции генераторы можно удачно использовать для управления корутинами, повторяющимися с переменными интервалами:
while (true)
{
//Что-то делаем
yield return new WaitForSeconds(timeIntervalGenerator.Next());
}
Прочитайте этот пост [32], чтобы больше узнать о генераторах.
43. Используйте префабы для всего. Единственными игровыми объектами в сцене, которые не являются префабами (или частями префабов), должны быть папки. Даже уникальные объекты, которые используются только один раз, должны быть префабами. Это упрощает внесение изменений, не требующих изменения сцены.
44. Привязывайте префабы к префабам; не привязывайте экземпляры к экземплярам. Связи с префабами сохраняются при перетаскивании префаба в сцену, связи с экземплярами — нет. Привязывание к префабам там, где это возможно, уменьшает затраты на настройку сцены и снижает необходимость изменения сцен.
Везде, где только возможно, устанавливайте связи между экземплярами автоматически. Если вам нужно связать экземпляры, устанавливайте связи программно. Например, префаб Player может зарегистрировать себя в GameManager, когда он запускается, или GameManager может найти префаб Player, когда он запускается.
45. Не делайте сетки корнями префабов, если вы хотите добавлять другие скрипты. При создании префаба из сетки сначала сделайте родителем сетки пустой игровой объект, и пусть он будет корнем. Привязывайте скрипты к корню, а не к сетке. Так вам будет проще заменить сетку другой сеткой, не теряя значения, настроенные в инспекторе.
46. Используйте скриптуемые объекты, а не префабы для передаваемых данных конфигурации.
Если вы так сделаете:
47. Используйте скриптуемые объекты для данных уровней. Данные уровней часто хранятся в XML или JSON, но использование вместо них скриптуемых объектов имеет ряд преимуществ:
48. Используйте скриптуемые объекты для конфигурирования поведения в инспекторе. Скриптуемые объекты обычно связаны с данными конфигурирования, но они также позволяют использовать «методы» как данные.
Рассмотрим сценарий, в котором у вас есть тип Enemy, и у каждого врага есть какой-то набор суперсил SuperPowers. Можно сделать их обычными классами и получить их список в классе Enemy, но без пользовательского редактора вы не сможете настроить список различных суперсил (каждой со своими свойствами) в инспекторе. Но если вы сделаете эти суперсилы ассетами (реализуете их как ScriptableObjects), то у вас получится!
Вот как это работает:
public class Enemy : MonoBehaviour
{
public SuperPower superPowers;
public UseRandomPower()
{
superPowers.RandomItem().UsePower(this);
}
}
public class BasePower : ScriptableObject
{
virtual void UsePower(Enemy self)
{
}
}
[CreateAssetMenu("BlowFire", "Blow Fire")
public class BlowFire : SuperPower
{
public strength;
override public void UsePower(Enemy self)
{
///программа использования суперсилы blow fire
}
}
При использовании этого паттерна не нужно забывать о следующих ограничениях:
49. Используйте скриптуемые объекты для специализации префабов. Если конфигурация двух объектов отличается только некоторыми свойствами, то обычно вставляют два экземпляра в сцену и настраивают эти свойства в экземплярах. Обычно лучше сделать отдельный класс свойств, который может отличаться между двумя типами, отдельным классом скриптуемого объекта.
Это обеспечивает бóльшую гибкость:
Вот простой пример такой настройки.
[CreateAssetMenu("HealthProperties.asset", "Health Properties")]
public class HealthProperties : ScriptableObject
{
public float maxHealth;
public float resotrationRate;
}
public class Actor : MonoBehaviour
{
public HealthProperties healthProperties;
}
При большом количестве специализаций можно определить специализацию как обычный класс, и использовать их список в скриптуемом объекте, связанном с подходящим местом, в котором можно его применять (например, в GameManager). Для обеспечения его безопасности, скорости и удобства потребуется немного больше «клея»; ниже приведён пример минимально возможного использования.
public enum ActorType
{
Vampire, Wherewolf
}
[Serializable]
public class HealthProperties
{
public ActorType type;
public float maxHealth;
public float resotrationRate;
}
[CreateAssetMenu("ActorSpecialization.asset", "Actor Specialization")]
public class ActorSpecialization : ScriptableObject
{
public List healthProperties;
public this[ActorType]
{
get { return healthProperties.First(p => p.type == type); } //Небезопасная версия!
}
}
public class GameManager : Singleton
{
public ActorSpecialization actorSpecialization;
...
}
public class Actor : MonoBehaviour
{
public ActorType type;
public float health;
//Пример использования
public Regenerate()
{
health
+= GameManager.Instance.actorSpecialization[type].resotrationRate;
}
}
50. Используйте атрибут CreateAssetMenu [33] чтобы автоматически добавить создание ScriptableObject в меню Asset/Create.
51. Научитесь эффективно использовать инструменты отладки Unity.
52. Научитесь эффективному использованию отладчика вашей IDE. См., например, Debugging Unity games in Visual Studio [40].
53. Используйте визуальный отладчик, рисующий графики изменения значений со временем. Он чрезвычайно удобен для отладки физики, анимаций и других динамических процессов, и в особенности нерегулярно возникающих ошибок. Вы сможете увидеть эту ошибку на графике и отследить другие переменные, изменяемые в момент ошибки. Также визуальный контроль делает очевидными определённые типы странного поведения, например, слишком часто изменяемые значения или отклонения без явных причин. Мы используем Monitor Components [41], но существуют и другие инструменты визуальной отладки.
54. Пользуйтесь удобной записью в консоль. Используйте расширение редактора, позволяющее кодировать цветом вывод по категориям и фильтровать вывод согласно этим категориям. Мы применяем Editor Console Pro [42], но есть и другие расширения.
55. Используйте инструменты тестирования Unity, особенно для тестирования алгоритмов и математического кода. См., например, туториал Unity Test Tools [43] или пост Unit testing at the speed of light with Unity Test Tools [44].
56. Применяйте инструменты тестирования Unity для выполнения «черновых» тестов. Инструменты тестирования Unity пригодны не только для формальных тестов. Их также можно использовать для удобных «черновых» тестов, которые выполняются в редакторе без запуска сцены.
57. Используйте горячие клавиши, чтобы делать скриншоты. Многие баги связаны с визуальным отображением, и гораздо проще сообщать о них, если можно сделать снимок экрана. Идеальная система должна иметь счётчики PlayerPrefs, чтобы скриншоты не перезаписывались. Скриншоты не нужно сохранять в папке проекта, чтобы сотрудники случайно не фиксировали (commit) их в репозитории.
58. Используйте горячие клавиши для печати снепшотов важных переменных. Они позволят регистрировать информацию, когда во время игры происходит неожиданные события, которые можно исследовать. Набор переменных конечно же зависит от игры. Подсказками для вас могут стать типичные ошибки, возникающие в игре. Например, положения игрока и врагов или «состояние думания» AI-актора (скажем, путь, по которому он пытается следовать).
59. Реализуйте опции отладки, чтобы упростить тестирование. Примеры:
Будьте внимательны, чтобы случайно не зафиксировать опции отладки в репозитории; изменение этих опций может запутать других разработчиков в коллективе.
60. Определите константы для горячих клавиш отладки, и храните их в одном месте. Клавиши отладки, в отличие от игрового ввода, обычно не обрабатываются в одном месте. Чтобы избежать конфликтов горячих клавиш, в первую очередь определяйте константы. Альтернативой является обработка всех клавиш в одном месте, вне зависимости от того, имеют ли они функции отладки или нет. (Недостаток такого подхода в том, что этому классу могут понадобиться только для этого дополнительные ссылки на объекты).
61. При процедурной генерации сеток отрисовывайте или спауньте небольшие сферы в вершинах. Это позволит вам убедиться, что вершины находятся в нужных местах и они нужного размера, прежде чем начинать работу с треугольниками и UV для отображения сеток.
62. Будьте осторожны с общими рекомендациями по дизайну и структуре для обеспечения производительности.
63. Как можно раньше начинайте регулярно тестировать игру на целевых устройствах. Устройства имеют разные характеристики производительности; не позволяйте им подкидывать вам сюрпризы. Чем раньше вы узнаете о проблемах, тем более эффективно вы сможете их решать.
64. Научитесь эффективному использованию профайлера для отслеживания причин проблем с производительностью.
65. При необходимости используйте сторонний профайлер для более точного профайлинга. Иногда профайлер Unity не может предоставить чёткую картинку происходящего: у него могут закончиться кадры профайла, или глубокий профайлинг настолько тормозит игру, что результаты тестов не имеют смысла. В этом случае мы используем наш собственный профайлер, но вы можете найти альтернативные в Asset Store.
66. Замеряйте эффект улучшений производительности. При внесении изменений для повышения производительности замеряйте её, чтобы убедиться, что изменение действительно улучшает производительность. Если изменение неизмеряемо или незначительно, откажитесь от него.
67. Не пишите менее читаемый код для повышения производительности. Исключения:
ИЛИ
68. Следуйте задокументированным соглашению о присвоении имён и структуре папок. Благодаря стандартизированному присвоению имён и структуре папок проще искать объекты и разбираться в них.
Скорее всего, вы захотите создать своё собственное соглашение о присвоении имён и структуру папок. Вот одно для примера.
Используйте символы подчёркивания между основным именем и частью, описывающей «аспект» элемента. Например:
Не используйте это соглашение для различения разных типов элементов, например, Rock_Small, Rock_Large должны называться SmallRock, LargeRock.
Схема сцен, папки проекта и папки скриптов должна иметь похожий шаблон. Ниже представлены примеры, которые можно использовать.
MyGame
Helper
Design
Scratchpad
Materials
Meshes
Actors
DarkVampire
LightVampire
…
Structures
Buildings
…
Props
Plants
…
…
Resources
Actors
Items
…
Prefabs
Actors
Items
…
Scenes
Menus
Levels
Scripts
Tests
Textures
UI
Effects
…
UI
MyLibray
…
Plugins
SomeOtherAsset1
SomeOtherAsset2
...
Main
Debug
Managers
Cameras
Lights
UI
Canvas
HUD
PauseMenu
…
World
Ground
Props
Structures
…
Gameplay
Actors
Items
…
Dynamic Objects
Debug
Gameplay
Actors
Items
…
Framework
Graphics
UI
...
Автор: PatientZero
Источник [51]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/c-2/199103
Ссылки в тексте:
[1] «50 советов по работе с Unity»: http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/
[2] Extensions: https://www.assetstore.unity3d.com/en/#%21/content/19323
[3] кучей прототипов игр: http://www.gamasutra.com/blogs/JonathanBailey/20131206/206337/How_we_made_30_games_in_30_days.php
[4] Father.IO: https://www.indiegogo.com/projects/father-io-massive-multiplayer-laser-tag-app
[5] Grids: https://www.assetstore.unity3d.com/en/#%21/content/66291
[6] для геймджема вы всё это использовать не будете: http://www.gamasutra.com/blogs/HermanTulleken/20140119/208901/Rapid_Game_Prototyping_Tips_for_Programmers.php
[7] Best Practices: http://unity3d.com/learn/tutorials/topics/best-practices
[8] https://youtu.be/OeEYEUCa4tI: https://youtu.be/OeEYEUCa4tI
[9] https://youtu.be/HM17mAmLd7k: https://youtu.be/HM17mAmLd7k
[10] https://youtu.be/Ozc_hXzp_KU: https://youtu.be/Ozc_hXzp_KU
[11] https://youtu.be/2S6Ygq58QF8: https://youtu.be/2S6Ygq58QF8
[12] http://docs.unity3d.com/Manual/HOWTO-ArtAssetBestPracticeGuide.html: http://docs.unity3d.com/Manual/HOWTO-ArtAssetBestPracticeGuide.html
[13] Подмодули: https://git-scm.com/book/en/v2/Git-Tools-Submodules
[14] Unity Builds Scripting: Basic and advanced possibilities.: http://www.gamasutra.com/blogs/EnriqueJGil/20160808/278440/Unity_Builds_Scripting_Basic_and_advanced_possibilities.php
[15] Unity.Assertions.Assert: https://docs.unity3d.com/ScriptReference/Assertions.Assert.html
[16] The Benefits of programming with assertions (a.k.a. assert statements): http://pgbovine.net/programming-with-asserts.htm
[17] ExecuteEvent: https://docs.unity3d.com/ScriptReference/EventSystems.ExecuteEvents.html
[18] системы событий Unity: http://docs.unity3d.com/Manual/EventSystem.html
[19] собственные корутины: http://blogs.unity3d.com/2015/12/01/custom-coroutines/
[20] PlayerPrefs: http://docs.unity3d.com/Documentation/ScriptReference/PlayerPrefs.html
[21] unscaledTime: https://docs.unity3d.com/ScriptReference/Time-unscaledDeltaTime.html
[22] HideInInspector: https://docs.unity3d.com/ScriptReference/HideInInspector.html
[23] Property drawers: https://docs.unity3d.com/Manual/editor-PropertyDrawers.html
[24] Header: https://docs.unity3d.com/ScriptReference/HeaderAttribute.html
[25] Tooltip: https://docs.unity3d.com/ScriptReference/TooltipAttribute.html
[26] «Паттерны программирования игр»: http://gameprogrammingpatterns.com/
[27] посте: http://gamelogic.co.za/2016/07/21/the-new-class-in-extensions-observedvalue-what-is-it-for-and-how-to-use-it/
[28] презентации: https://gamedevacademy.org/lessons-learned-in-unity-after-5-years/
[29] RequiredComponent: https://docs.unity3d.com/ScriptReference/RequireComponent.html
[30] DisallowMultipleComponent: https://docs.unity3d.com/ScriptReference/DisallowMultipleComponent.html
[31] SelectionBase: https://docs.unity3d.com/ScriptReference/SelectionBaseAttribute.html
[32] пост: http://gamelogic.co.za/2016/07/11/new-generators-designed-from-scratch-for-use-in-procedural-content/
[33] CreateAssetMenu: https://docs.unity3d.com/ScriptReference/CreateAssetMenuAttribute.html
[34] Debug.Log: http://docs.unity3d.com/ScriptReference/Debug.Log.html
[35] Debug.Break: http://docs.unity3d.com/ScriptReference/Debug.Break.html
[36] Debug.DrawRay: http://docs.unity3d.com/ScriptReference/Debug.DrawRay.html
[37] Debug.DrawLine: http://docs.unity3d.com/ScriptReference/Debug.DrawLine.html
[38] Gizmos: http://docs.unity3d.com/ScriptReference/Gizmos.html
[39] DrawGizmo: http://docs.unity3d.com/ScriptReference/DrawGizmo.html
[40] Debugging Unity games in Visual Studio: https://unity3d.com/learn/tutorials/topics/scripting/debugging-unity-games-visual-studio
[41] Monitor Components: https://www.assetstore.unity3d.com/en/#!/content/23765
[42] Editor Console Pro: https://www.assetstore.unity3d.com/en/#!/content/11889
[43] Unity Test Tools: https://unity3d.com/learn/tutorials/topics/production/unity-test-tools
[44] Unit testing at the speed of light with Unity Test Tools: http://blogs.unity3d.com/2014/07/28/unit-testing-at-the-speed-of-light-with-unity-test-tools/
[45] Введение в профайлер: https://unity3d.com/learn/tutorials/topics/interface-essentials/introduction-profiler
[46] Profiler.BeginFrame: http://docs.unity3d.com/ScriptReference/Profiler.BeginSample.html
[47] Profiler.EndFrame: http://docs.unity3d.com/ScriptReference/Profiler.EndSample.html
[48] встроенный профайлер для iOS: https://docs.unity3d.com/Manual/iphone-InternalProfiler.html
[49] профайлинг в файл: http://docs.unity3d.com/ScriptReference/Profiler-logFile.html
[50] отображать данные в профайлере: http://docs.unity3d.com/ScriptReference/Profiler.AddFramesFromFile.html
[51] Источник: https://habrahabr.ru/post/309478/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.