Лучшие практики для организации вашего проекта Unity

Хотя нет единого способа организовать проект Unity, вот несколько ключевых рекомендаций:

• Документируйте свои соглашения об именовании и структуру папок. Руководство по стилю и/или шаблон проекта упрощает поиск и организацию файлов. Выберите то, что подходит вашей команде, и убедитесь, что все согласны с этим.
• Будьте последовательны в ваших соглашениях о наименовании. Не отклоняйтесь от выбранного вами стиля или шаблона. Если вам нужно изменить правила наименования, обработайте и переименуйте все затронутые активы сразу. Если изменения затрагивают большое количество файлов, подумайте об автоматизации обновления с помощью скрипта.
• Не используйте пробелы в именах файлов и папок. Инструменты командной строки Unity имеют проблемы с именами путей, которые содержат пробелы. Используйте CamelCase в качестве альтернативы пробелам.
• Отделите тестовые или песочницы. Создайте отдельную папку для непроизводственных сцен и экспериментов. Подпапки с именами пользователей могут разделить вашу рабочую область по членам команды.
• Избегайте лишних папок на корневом уровне. В общем, храните ваши файлы контента в папке Assets. Не создавайте дополнительные папки на корневом уровне проекта, если это абсолютно не необходимо.
• Держите ваши внутренние активы отдельно от сторонних. Если вы используете активы из Asset Store или других плагинов, скорее всего, у них есть своя структура проекта. Держите свои собственные активы отдельно.

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

Хотя нет установленной структуры папок, следующие два раздела показывают примеры того, как вы можете настроить свой проект Unity. Эти структуры основаны на разделении вашего проекта по типу активов.

Страница Руководство по типам активов описывает наиболее распространенные активы более подробно. Вы можете использовать проекты Шаблон или Обучение для дальнейшего вдохновения при организации структуры папок. Хотя вы не ограничены этими именами папок, они могут стать хорошей отправной точкой.

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

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

Plastic SCM может обрабатывать перемещения файлов внутри Unity и сохранять историю любого файла, который был перемещен. Однако важно перемещать файлы в редакторе, чтобы файл .meta перемещался вместе с файлом актива.

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

Пустые папки могут создавать проблемы с контролем версий, поэтому старайтесь создавать папки только для того, что вам действительно нужно. С Git и Perforce пустые папки по умолчанию игнорируются. Если такие проектные папки настроены, и кто-то попытается их зафиксировать, это не сработает, пока в папку не будет помещен какой-либо элемент.

Примечание: Распространенное решение — поместить файл “.keep” в пустую папку. Этого достаточно, чтобы папка была зафиксирована в репозитории.

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

Это важно учитывать при работе в Unity. Unity генерирует файл .meta для каждого файла в проекте, включая папки. С Git и Perforce пользователь может легко зафиксировать файл .meta для пустой папки, но сама папка не будет находиться под контролем версий. Когда другой пользователь получает последние изменения, будет файл .meta для папки, которая не существует на его машине, и Unity затем удалит файл .meta. Plastic SCM полностью избегает этой проблемы, включая пустые папки под контроль версий.

Unity генерирует файл .meta для каждого другого файла в проекте, и хотя обычно не рекомендуется включать автоматически сгенерированные файлы в контроль версий, файл .meta немного отличается. Режим видимых файлов Meta должен быть включен в окне контроля версий (если вы не используете встроенные режимы Plastic SCM или Perforce).

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

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

Хотя нет окончательного стандарта именования для GameObjects, рассмотрите таблицу выше.

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

Во время выполнения ваш проект может загружать сцены аддитивно, используя SceneManager с LoadSceneAsync, передавая параметр LoadSceneMode.Additive.

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

В случае, если у вас возникнет конфликт сцен, Unity также имеет встроенный инструмент YAML (читаемый человеком язык сериализации данных), используемый для слияния сцен и префабов. Для получения дополнительной информации смотрите Умное слияние в документации Unity.

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

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

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

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

• Создайте объект игры с настройками по умолчанию: Перетащите и отпустите актив предустановки в Иерархию, чтобы создать новый объект игры с соответствующим компонентом, который включает значения предустановки.
• Ассоциируйте конкретный тип с предустановкой: В Менеджере предустановок (Настройки проекта > Менеджер предустановок) укажите одну или несколько предустановок для каждого типа. Создание нового компонента будет по умолчанию использовать указанные значения предустановки.
• Совет профессионала: Создайте несколько пресетов для каждого типа и используйте фильтр для ассоциации правильного пресета по имени.
• Сохранить и загрузить настройки менеджера: Используйте пресеты для окна менеджера, чтобы настройки можно было повторно использовать. Например, если вы планируете повторно применять одни и те же теги и слои или настройки физики, пресеты могут сократить время настройки для вашего следующего проекта.

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

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

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

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

Unity использует шаблон скрипта для чтения каждый раз, когда вы создаете новый MonoBehaviour в проекте. Каждый раз, когда вы создаете новый скрипт или шейдер, Unity использует шаблон, хранящийся в %EDITOR_PATH%\Data\Resources\ScriptTemplates:

• Windows: C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/Unity/Unity.app/Contents/Resources/ScriptTemplates

шаблон MonoBehaviour по умолчанию выглядит так: 81-C# Script-NewBehaviourScript.cs.txt

Существуют также шаблоны для шейдеров, других скриптов поведения и определений сборок.

Для шаблонов скриптов, специфичных для проекта, создайте папку Assets/ScriptTemplates и скопируйте шаблоны скриптов в эту папку, чтобы переопределить значения по умолчанию.

Вы также можете напрямую изменить шаблоны скриптов по умолчанию для всех проектов, но убедитесь, что вы сделали резервную копию оригиналов перед внесением каких-либо изменений. Каждая версия Unity имеет свою собственную папку шаблонов, поэтому, когда вы обновляетесь до новой версии, вам нужно снова заменить шаблоны. Пример кода ниже показывает, как выглядит оригинальный файл 81-C# Script-NewBehaviourScript.cs.txt.

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

• #SCRIPTNAME# указывает на имя файла, введенное вами, или имя файла по умолчанию (например, NewBehaviourScript).
• #NOTRIM# гарантирует, что скобки содержат строку пробела.

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

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