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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя для GameObjects не существует определенного стандарта именования, рассмотрим приведенную выше таблицу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Windows C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[версия]/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 .

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