24. Используйте расширения, чтобы сделать синтаксис более удобным. Например:

public static class CSTransform
{
public static void SetX(this Transform transform, float x)
{
Vector3 newPosition =
new Vector3(x, transform.position.y, transform.position.z);

Transform.position = newPosition;
}
...
}

25. Используйте безопасную альтернативу GetComponent. Иногда внедрение зависимостей компонентов (через RequiredComponent ), может быть болезненным. Например, это затрудняет изменение компонентов в инспекторе (даже, если они имеют тот же базовый тип). В качестве альтернативы, может быть использовано, следующее расширение GameObject , для вывода ошибки, если компонент не найден.

public static T GetSafeComponent(this GameObject obj) where T: MonoBehaviour
{
T component = obj.GetComponent();

If(component == null)
{
Debug.LogError("Expected to find component of type "
+ typeof(T) + " but found none", obj);
}

Return component;
}

Идиомы

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

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

Примеры групп идиом:

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

(*vs — против)

Время

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

Спаун объектов

28. Не позволяйте порождаемым объектам загромождать иерархию, когда игра запущена. Установите для них родителя — объект сцены, для облегчения поиска объектов, при запущенной игре. Вы можете воспользоваться пустым объектом игры, или даже единичным объектом без поведения, чтобы легко получить доступ из кода. Вызовите этот объект DynamicObjects .

Дизайн классов

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

public class Singleton : MonoBehaviour where T: MonoBehaviour
{
protected static T instance;

/**
Returns the instance of this singleton.
*/
public static T Instance
{
get
{
if(instance == null)
{
instance = (T) FindObjectOfType(typeof(T));

If (instance == null)
{
Debug.LogError("An instance of " + typeof(T) +
" is needed in the scene, but there is none.");
}
}

Return instance;
}
}
}

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

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

30. Для компонентов, никогда не делайте переменные общедоступными, если они не должны изменяться через инспектор. Иначе, ее может «покрутить» дизайнер, не зная, что переменная делает. В редких случаях, это неизбежно. В таком случае, используйте два, или даже четыре подчеркивания в качестве префикса, в имени переменной, чтобы отпугнуть «крутильщиков»:

public float __aVariable;

31. Отделяйте интерфейс от логики игры. Это, по сути паттерн MVC.

Каждый контроллер ввода, должен лишь давать команды соответствующим компонентам, чтобы дать им знать, что контроллер был вызван. Например, в логике контроллера, можно решать, какие команды давать, основываясь на состоянии игрока. Но это плохо (например, это приведет к дублированию логики, если добавлено несколько контроллеров). Вместо этого, объект Игрока должен быть уведомлен о намерениях двигаться вперед, а затем на основе текущего состояния (замедлен или оглушен, например) установить скорость и обновить направление игрока. Контроллеры должны делать только то, что относится к их собственному состоянию (контроллер не меняет состояние, когда игрок изменяет состояние, поэтому контроллер вообще не должен знать о состоянии игрока). Другим примером является смена оружия игроком. Правильный способ сделать это в Player , с помощью метода SwitchWeapon(Weapon newWeapon) , который можно вызвать из GUI. GUI не должен манипулировать трансформациями, родителями и т.д..

Любой компонент интерфейса, должен только поддерживать данные, и выполнять обработку, связанную с его собственным состоянием. Например, отображение карты, на основе расчетов движения игрока. Тем не менее, это данные состояния игры, и не принадлежат к GUI. GUI должен лишь отображать данные состояния игры, хранить их нужно в другом месте. Картографические данные должны быть сохранены в другом месте (в GameManager , например).

Объекты геймплея не должны знать практически ничего о GUI. Единственным исключением является режим паузы, которая может контролироваться глобально посредством Time.timeScale (что не является хорошей идеей). Геймплейные объекты должны знать, если игра приостановлена. И это всё. Поэтому, не должно быть ссылок, на GUI-компоненты из объектов геймплея.

В общем, по идее, если вы удалите все классы GUI, игра должна компилироваться.

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

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

• сохранение состояния игры
• отладку состояния игры

Один из способов сделать это, определение класса SaveData для каждого класса игровой логики:

PlayerSaveData
{
public float health; //public for serialisation, not exposed in inspector
}

Player
{
//... bookkeeping variables (переменные промежуточных данных)

//Don’t expose state in inspector. State is not tweakable.
private PlayerSaveData playerSaveData;
}

33. Отделяйте конфигурацию специализаций.

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

• Определите шаблонный класс для каждого класса игровой логики. Для экземпляра врага, мы определим класс EnemyTemplate . Где будут храниться, все отличительные характеристики.
• В классе игровой логики, определите переменную типа нашего шаблона.
• Сделайте префаб врага, и два шаблонных префаба WeakEnemyTemplate и StrongEnemyTemplate .
• При загрузке и порождении объектов, задайте переменной шаблона нужный шаблон.

Этот метод может стать довольно сложным (а иногда, излишне сложным, так что будьте осторожны!).

Например, лучше будет использование полиморфизма обобщения, мы можем определить класс, так:

public class BaseTemplate
{
...
}

Public class ActorTemplate: BaseTemplate
{
...
}

Public class Entity where EntityTemplateType: BaseTemplate
{
EntityTemplateType template;
...
}

Public class Actor: Entity
{
...
}

34. Не используйте строки ни для чего, кроме отображаемого текста. В частности, не используйте строки для идентификации объектов, префабов и т.д.. Досадным исключением является анимация, доступ к которым осуществляется по строковым именам.

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

public void SelectWeapon(int index)
{
currentWeaponIndex = index;
Player.SwitchWeapon(weapons);
}

Public void Shoot()
{
Fire(bullets);
FireParticles(particles);
}

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

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

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

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

public void FireAttack()
{
/// behaviour
Fire(bullets);
}

Public void IceAttack()
{
/// behaviour
Fire(bullets);
}

Public void WindAttack()
{
/// behaviour
Fire(bullets);
}

Перечисления могут сделать ваш код лучше …

public void WindAttack()
{
/// behaviour
Fire(bullets);
}

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

public class Bullets
{
public Bullet FireBullet;
public Bullet IceBullet;
public Bullet WindBullet;
}

Здесь предполагается, что нет других данных для огня, льда и воздуха.

37. Группируйте данные в сериализуемых классах, чтобы сделать параметры в инспекторе упорядоченнее. Некоторые объекты могут иметь десятки параметров. Это может стать кошмаром, при попытке найти правильную переменную в инспекторе. Чтобы упростить это дело, выполните следующие действия:

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

Это сгруппирует переменные в инспекторе в блоки, и облегчит управление ими.

public class MovementProperties //Not a MonoBehaviour!
{
public float movementSpeed;
public float turnSpeed = 1; //default provided
}

Public class HealthProperties //Not a MonoBehaviour!
{
public float maxHealth;
public float regenerationRate;
}

Public class Player: MonoBehaviour
{
public MovementProperties movementProeprties;
public HealthPorperties healthProeprties;
}

Текст

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

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

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

Тестирование и отладка

42. Реализуйте свой собственный FPS-счетчика. Да. Никто не знает, что на самом деле измеряет FPS-счетчик Unity, но это не скорость кадров. Реализуйте собственный, так чтобы FPS соответствовал интуиции и визуальному контролю.

43. Реализуйте сочетаний клавиш, для снятия снимков экрана. Многие ошибки являются визуальными, и гораздо проще, сообщить о них, когда можно сделать скриншот. Идеальная система должна содержать счетчик в PlayerPrefs, чтобы последовательные скриншоты не перезаписывались. Скриншоты должны быть сохранены за пределами папки проекта, чтобы избежать случайного коммита в репозиторий.

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

45. Реализуйте опции отладки для упрощения тестирования. Некоторые примеры:

• Разблокировать все предметы (айтемы).
• Отключить врагов.
• Отключить GUI.
• Сделать игрока непобедимым.
• Отключить весь геймплей.

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

• Члены команды не закоммитят свои опции отладки по случайности, и никого не затронут.
• Изменение опций отладки не изменит сцену.

47. Держите сцену со всеми элементами геймплея. Например, сцена со всеми врагами, все объекты, с которыми можно взаимодействовать, и т.д. Это делает легкой проверку функциональности, без необходимости играть слишком долго.

48. Определите константы для отладки сочетания клавиш, и держите их в одном месте. Клавиши отладки не нормально (не удобно) обрабатываются в едином месте, как и остальные части игрового ввода. Чтобы избежать конфликтов между сочетаниями клавиш, определите константы в одном месте. Альтернативой является, обрабатывать все клавиши в одном месте, независимо от того, является функция отладочной, или нет. (Недостатком является то, что этому классу могут понадобиться дополнительные ссылки на объекты).

Документация

49. Документируйте ваши настойки. Большинство документации должно быть в коде, но некоторые вещи должны быть задокументированы вне кода. Документация, повышает эффективность (если она актуальная).

Документируйте следующее:

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

Стандарт именования и структура папок

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

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

Общие принципы именования.

• Называйте вещи своими именами. Птица должна называться Bird .
• Выбирайте имена, легко произносимые и запоминающиеся. Если вы делаете игру о Майя, не называйте свой уровень QuetzalcoatisReturn .
• Будьте последовательными. Выбрав имя, придерживайтесь его.
• Используйте стиль PascalCase, например: ComplicatedVerySpecificObject . Не используйте пробелы, подчеркивания или дефисы, с одним исключением (см. «Именования различных аспектов одного и того же»).
• Не используйте номера версий, или слова для обозначения стадии прогресса (WIP, финал).
• Не используйте аббревиатуры: DVamp@W должно быть DarkVampire@Walk .
• Используйте терминологию из дизайн документации: если в документе анимация смерти называется Die, то надо использовать имя DarkVampire@Die , а не DarkVampire@Death .
• Держите наиболее специфический дескриптор слева: DarkVampire , вместо VampireDark ; PauseButton , вместо ButtonPaused . Легче, например, найти кнопку паузы в инспекторе, когда не все кнопки, начинаются со слова «Button». [Многие люди предпочитают делать наоборот, потому что, это делает группировки, визуально более очевидными. Имена существуют не для группировок, для этого есть папки. Имена для различения объектов, одного и того же типа, и они должны помогать делать это быстро.]
• Некоторые имена образуют последовательность. Используйте номера в этих названиях, например, PathNode0 , PathNode1 . Всегда начинайте с 0, а не 1.
• Не используйте цифры для вещей, которые не образуют последовательность. Например, Bird0 , Bird1 , Bird2 , должно быть Flamingo , Eagle , Swallow .
• Ставьте префикс временным объектам в виде двойного подчеркивания __Player_Backup .

Именования различных аспектов одного и того же

Используйте подчеркивание между основным именем, и тем, что описывает «Аспект». Например:

• Состояние GUI-кнопок: EnterButton_Active, EnterButton_Inactive.
• Текстуры: DarkVampire_Diffuse, DarkVampire_Normalmap.
• Скайбоксы: JungleSky_Top, JungleSky_North.
• LOD-группы: DarkVampire_LOD0, DarkVampire_LOD1.

Не используйте, это соглашение просто, для различия типов предметов, например, Rock_Small , Rock_Large , должно быть SmallRock , LargeRock .

Структура

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

Структура папок:

Materials
GUI
Effects
Meshes
Actors
DarkVampire
LightVampire
...
Structures
Buildings
...
Props
Plants
...
...
Plugins
Prefabs
Actors
Items
...
Resources
Actors
Items
...
Scenes
GUI
Levels
TestScenes
Scripts
Textures
GUI
Effects
...

Структура сцены:

Cameras
Dynamic Objects
Gameplay
Actors
Items
...
GUI
HUD
PauseMenu
...
Management
Lights
World
Ground
Props
Structure
...

Структура папки скриптов:

ThirdParty
...
MyGenericScripts
Debug
Extensions
Framework
Graphics
IO
Math
...
MyGameScripts
Debug
Gameplay
Actors
Items
...
Framework
Graphics
GUI
...

Как переопределить отрисовку инспектора.

1. Определите базовый класс для всех ваших редакторов:

BaseEditor : Editor
where T: MonoBehaviour
{
override public void OnInspectorGUI()
{
T data = (T) target;

GUIContent label = new GUIContent();
label.text = "Properties"; //

DrawDefaultInspectors(label, data);

If(GUI.changed)
{
EditorUtility.SetDirty(target);
}
}
}

2. Используйте рефлексию и рекурсию, чтобы составить компоненты:

public static void DrawDefaultInspectors(GUIContent label, T target)
where T: new()
{
EditorGUILayout.Separator();
Type type = typeof(T);
FieldInfo fields = type.GetFields();
EditorGUI.indentLevel++;

Foreach(FieldInfo field in fields)
{
if(field.IsPublic)
{
if(field.FieldType == typeof(int))
{
field.SetValue(target, EditorGUILayout.IntField(
MakeLabel(field), (int) field.GetValue(target)));
}
else if(field.FieldType == typeof(float))
{
field.SetValue(target, EditorGUILayout.FloatField(
MakeLabel(field), (float) field.GetValue(target)));
}

///etc. for other primitive types

Else if(field.FieldType.IsClass)
{
Type parmTypes = new Type{ field.FieldType};

String methodName = "DrawDefaultInspectors";

MethodInfo drawMethod =
typeof(CSEditorGUILayout).GetMethod(methodName);

If(drawMethod == null)
{
Debug.LogError("No method found: " + methodName);
}

Bool foldOut = true;

DrawMethod.MakeGenericMethod(parmTypes).Invoke(null,
new object
{
MakeLabel(field),
field.GetValue(target)
});
}
else
{
Debug.LogError(
"DrawDefaultInspectors does not support fields of type " +
field.FieldType);
}
}
}

EditorGUI.indentLevel--;
}

Описанный выше метод использует вспомогательный метод:

private static GUIContent MakeLabel(FieldInfo field)
{
GUIContent guiContent = new GUIContent();
guiContent.text = field.Name.SplitCamelCase();
object descriptions =
field.GetCustomAttributes(typeof(DescriptionAttribute), true);

If(descriptions.Length > 0)
{
//just use the first one.
guiContent.tooltip =
(descriptions as DescriptionAttribute).Description;
}

Return guiContent;
}

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

3. Определите новые пользовательские редакторы.

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

public class MyClassEditor: BaseEditor
{}

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

Перевод Максим Саликов .

• Tutorial

Как создать внутриигровое меню в Unity

Создание и дизайн главного меню и меню настроек

Теперь можем приступать к созданию пользовательского интерфейса. Откройте сцену Menu и добавьте Panel. Сразу добавляется Canvas(Холст) и дочерним объектом к нему добавляется Panel (Панель).

Немного информации:

Screen Space – Overlay:

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

Важен порядок размещения объектов в иерархии. Холст Screen Space – Overlay должен находиться в самом верху иерархии, иначе он может пропасть из виду.

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

Так же для Холста с такими настройками важно размещение относительно других объектов. На переднем плане будут объекты, которые находятся ближе к камере, не зависимо от того, это UI или другие GameObjects.

Холст размещается, как любой другой объект без привязки к камере или экрану, он может быть ориентирован как вам угодно, размер Холста задается с помощью RectTransform, но то, как его будет видно во время игры, будет зависеть от положения камеры.
В данном задании мы будем использовать Screen Space – Overlay.
Давайте настроим цвет панели. Можно также добавить картинку на фон. Для этого нужно обратить внимание на компонент Image в Инспекторе панели.

Цвет выбирается в поле Color, либо с помощью инструмента пипетки.
Важно знать, что пипетка позволяет выбрать цвет за пределами Unity.
После того, как выбрали цвет или картинку, нам нужно разместить кнопки, которые всем будут управлять, а так же текст. Чтобы упростить себе задачу, для Panel мы добавим еще один компонент, который называется Vertical Layout Group. И сразу настроим его.

Нам необходимо разместить все кнопки и текст по центру экрана. Для этого находим в компоненте Vertical Layout Group пункт Child Alignment и выбираем Middle Center. Теперь все наши элементы, будь то кнопки или текст, будут выравниваться по центру, независимо от разрешения экрана.

Так же убираем галочки с ChildForceExpand. Должно получиться так:

В нашем меню должны быть следующие кнопки:

1. Start Game
2. Settings
3. Exit

Сейчас, добавляем Text дочерним элементом нашей Панели. Можете заметить, как он прикрепляется по центру. Иногда для этого требуется созданный элемент в окне Scene просто передвинуть на Panel и тогда он выровняется. Настраиваем текст так, как хочется с помощью компонента Text(Script) в инспекторе.

Разберем компонент Button нашей кнопки. Нас интересует Transition – то, как кнопка будет реагировать на действия мышки. В Unity реализовано несколько способов. Пока рассмотрим довольно простой Color Tint. Это значит, что кнопка будет менять свой цвет при определенных состояниях. Интерфейс для настройки довольно удобный. Настраиваем так, как нравится.

Кажется, Текст и Кнопки находятся слишком близко друг к другу.

Что бы это исправить для нашего Текста Menu добавляем еще один компонент, который называется Layout Element. И ставим галочку напротив Ignore Layout.

Переходы между main menu и settings

За контроль Fullscreen будет отвечать элемент Toggle.
За громкость – Slider.
За качество изображения и разрешение – Dropdown.

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

Можно настроить Spacing в Vertical layout group, чтобы между элементами было немного пространства. Добавим на панель картинку и в итоге получим такой результат:

Программирование кнопок

Нам нужно, чтобы по нажатию кнопки Play у нас запускалась другая сцена с нашей игрой, а по нажатию кнопки Exit игра закрывалась.

Это мы и пропишем в нашем скрипте.

Для MainMenu добавляем новый компонент MenuControls.cs и отрываем его.

Первое что надо сделать – удалить существующие методы Start() и Update() – тут они нам не нужны.

Using UnityEngine.SceneManagement;
После этого напишем свой метод для нажатия кнопки Play. Метод должен быть public - нам нужно иметь возможность видеть его за пределами нашего скрипта.

За загрузку сцены отвечает SceneManager и у него есть метод LoadScene. Существует несколько перегрузок метода. Можно передавать имя сцены, которую вы хотите загрузить. В нашем случае это сцена «Game».

В итоге функция будет выглядеть следующим образом.

Public void PlayPressed() { SceneManager.LoadScene("Game"); }
Так же создаем метод для выхода из игры:

Public void ExitPressed() { Application.Quit(); }
Однако в Unity мы не увидим результата работы этого метода, так как подобное работает только в билде. Для того что бы проверить, что все работает правильно, добавляем в метод строчку

Debug.Log("Exit pressed!");
Теперь необходимо прикрепить события кнопок к этим методам. Выбираем кнопку Play и находим в инспекторе следующее:

В появившееся окно нужно перетащить объект, в котором содержится нужный скрипт. В нашем случае это Main Menu.

После этого нужно выбрать скрипт MenuControls и найти метод PlayPressed().

Суть в том, что мы будем активировать GameObject. На этом этапе у вас должен быть активным MainMenu, а Settings не должно быть видно. Так же видим, что когда мы активируем Settings, он полностью перекрывает Menu. Суть в том, что играет роль порядок расположения дочерних объектов Холста – в каком порядке они расположены в иерархии в том порядке они и будут прорисовываться. Поскольку Settings у нас находятся над Main Menu, то они перекрывают меню.
Это мы и будем использовать.

Выбираем кнопку Settings и в OnClick() перетаскиваем наш объект Settings. В функциях выбираем GameObject ->SetActive(); и ставим галочку. Вот так:

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

Настройки

Первое что мы пропишем это переключение полноэкранного и оконного режимов.
Нужно убрать галочку с пункта Is On нашего Toggle элемента.
Создаем скрипт для объекта Settings. Назовем его Settings.cs.

Для начала нам надо хранить переменную типа bool которая будет отображать текущее состояние – полноэкранный режим или нет. А потом, по изменению toggle эта переменная будет переключаться на противоположное значение.

У экрана есть свойство Screen.fullScreen типа bool. Можно просто будем присваивать значение нашей переменной isFullScreen этому свойству.

Код выглядит так:

Public void FullScreenToggle() { isFullScreen = !isFullScreen; Screen.fullScreen = isFullScreen; }
Увидеть результат можно только в билде. Давайте сейчас это сделаем. Учтите, что для того что бы билд был правильным нужно оставить активным только объект MainMenu, а Settings отключить. Если это сделано, то запускаем билд через File->BuildSettings и нажимаем кнопку Build.

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

Изменения громкости звука в игре

Добавим эти два элемента. Сначала добавляем AudioMixer. Правой кнопкой мыши в окне Project ->Create->AudioMixer.

Называем его GameSettings. После этого открываем окно AudioMixer: Window->Audio Mixer (Ctrl + 8).

Что бы контролировать параметры миксера через скрипт, их нужно сделать видимыми для этого скрипта. Эта процедура называется ExposeParameters. Для этого кликаем на Mixer и в инспекторе находим volume и кликаем правой кнопкой мыши. Выбираем Expose to script:

Переходим в Settings.cs и создаем поле AudioMixer, чтобы получить ссылку на него в коде.

Public AudioMixer am;
потом создаем метод

Public void AudioVolume(float sliderValue) { am.SetFloat("masterVolume", sliderValue); }
Метод SetFloat будет принимать значения нашего слайдера и присваивать это значение параметру “masterVolume”.

Осталось прикрепить наш метод к событиям слайдера. Находим в инспекторе слайдера поле On Value Changed и точно так же прикрепляем объект. Вот только теперь нам надо не просто выбирать метод из списка, а использовать поле Dynamic float. Как видите, там уже есть наш метод, и он будет получать переменную от самого слайдера. Также нужно не забыть перетащить AudioMixer в соответствующее поле в компоненте Settings.cs.

Качество изображения

Особенностью работы с настройками качества является следующее:
Каждой настройке соответствует индекс, который мы можем получить из Dropdown. Все что нужно сделать – переписать соответствующие пункты в нужные индексы в нашем UI элементе. Открываем его и в инспекторе находим Dropdown(Script) и в нем пункт Options. Дальше вписываем настройки в нужном порядке. У меня получилось так:

Public void Quality(int q) { QualitySettings.SetQualityLevel(q); }
Сохраняем скрипт и подключаем метод к событию на нашем меню. На этот раз это событие Dropdown – On Value Changed.

Поскольку наш метод будет получать значение от самого UI элемента, то мы выбираем название метода из группы Dymanic int. по аналогии с предыдущим пунктом.

Разрешение экрана

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

Однако для пунктов выпадающего списка тип – string. Поэтому создаем список List<> в который мы будем сохранять значения возможных разрешений. Для работы со списками необходимо подключить:

Using System.Collections.Generic;
Также нам понадобится ссылка на соответствующий Dropdown. Для работы с UI элементами следует также прописать:

Using UnityEngine.UI;
В скрипте получим следующие поля:

Resolution rsl; List resolutions; public Dropdown dropdown;
Инициализацию и заполнение проводим в методе Awake. Этот метод вызывается при запуске объекта, соответственно выполняется раньше, чем все остальные методы.

Получаем значения и каждое из них добавляем в List в формате ширина*высота. После этого очищаем список Dropdown и заполняем его новыми опциями.

Public void Awake() { resolutions = new List(); rsl = Screen.resolutions; foreach (var i in rsl) { resolutions.Add(i.width +"x" + i.height); } dropdown.ClearOptions(); dropdown.AddOptions(resolutions); }
Теперь нужно создать метод, который будет менять разрешение экрана. Как и в предыдущих пунктах – принимать значение будем от UI элемента. Создаем функцию, которая принимает int

Public void Resolution(int r) { Screen.SetResolution(rsl[r].width, rsl[r].height, isFullScreen); }
В SetResolution необходимо передать параметры – ширина, высота и булевскую переменную, отвечающую за полный экран. У нас такая уже есть – это isFullScreen. Передаем ее в функцию.
Дальше не забываем подключить к соответствующему событию наш метод Resolution из группы Dynamic Int, а так же добавить ссылку на нужный Dropdown.

Edit->ProjectSettings-> Display Resolution Dialog-Disabled

Теги: android Добавить метки