Как создавать сцены и префабы с упором на контроль версий
Цель этого руководства - предоставить лучшие практики для создания контента в Unity, который работает с контролем версий. Более подробную информацию об использовании контроля версий вы можете найти в блоге Unity " Как использовать контроль версий для более тесной совместной работы " или в электронной книге "Лучшие практики контроля версий". Хотя оба этих ресурса содержат хорошую общую информацию по работе с контролем версий, в этом блоге мы сосредоточимся на том, как контент интегрируется с контролем версий и как избежать конфликтов слияния, когда многие авторы одновременно работают над одним и тем же или смежным контентом.
В Интернете много путаницы по поводу .meta-файлов и контроля версий. Файлы .meta всегда следует проверять в системе контроля версий. Они содержат важную информацию, например, GUID файла, который связывает все ссылки между активами. Они должны быть синхронизированы с исходными файлами (имя и расположение всегда должны совпадать с соответствующим исходным файлом). Никогда не перемещайте и не переименовывайте файлы активов вне редактора Unity, если для этого не были созданы специальные инструменты или если вы не знаете функциональность .meta-файлов.
По умолчанию для управления версиями .meta-файлов используется режим Visible Files, который показывает .meta-файлы на диске в операционной системе, а не скрывает их. Если вы используете Perforce, выберите режим Perforce.
Первое, что должна сделать любая команда при работе с Unity и контролем версий, - настроить Smart Merge. По умолчанию Unity хранит YAML-файлы в текстовом виде, что позволяет объединять их в системе контроля версий. Изменение режима сериализации активов на двоичный лишит вас возможности объединять эти файлы с помощью контроля версий.
Поскольку YAML-файлы Unity являются текстовыми, многие программы для слияния версий пытаются объединить их, используя текст или правила кодирования. Smart Merge создан в Unity для слияния с учетом структуры YAML. Мы рекомендуем использовать Smart Merge в качестве инструмента слияния по умолчанию для всех файлов YAML.
Smart Merge значительно сократит количество потерянных работ из-за конфликтов слияния, но если ваша команда не терпит потенциальных потерь, мы рекомендуем также использовать блокировку файлов и вручную разрешать конфликты слияния для любых файлов YAML.
Блокировка файлов - обычная практика для крупных студий, где несколько создателей контента могут работать над одним и тем же двоичным файлом (или файлом YAML) одновременно. Контроль версий Unity не позволяет никому проверить заблокированный файл. Perforce не позволяет никому отправлять заблокированный файл.
Для поддержки блокировки файлов Git требует инициализации Git LFS. Мы рекомендуем использовать Git LFS для всех проектов, которые содержат большие файлы контента и используют Git для контроля версий.
Успешные команды часто имеют строгие рекомендации по именованию, структуре папок, расположению активов и их редактированию. Поскольку все команды разные, не существует единого набора универсальных рекомендаций. Выбрать правильную систему для своей команды и придерживаться ее до тех пор, пока она работает, - вот что самое важное.
Конкретные, строгие рекомендации упрощают разработку инструментов для проверки контента. Это позволяет предотвратить ошибки еще до того, как они появятся в игре. Проверка содержимого с помощью кода и инструментов становится намного проще, если четко определить местоположение и именование активов. После этого вы сможете легче обеспечить соблюдение стандартов импорта Unity с помощью постобработки активов и пресетов.
При создании контента важно использовать принцип разделения обязанностей. Продумайте, как разделить контент и где он должен находиться, чтобы сохранить проект чистым и предотвратить конфликты при слиянии, с которыми сталкивается большинство создателей контента. Он также может помочь в поиске и привлечении экспертов по функциям, когда отдельные функции живут в определенных подсценах или префабах. Основными строительными блоками, которые можно использовать для разделения содержимого на файлы, являются сцены, префабы и подграфы.
Сцены - это макросы, из которых строится любое приложение Unity. Каждая сцена сериализуется (сохраняется) в файл, что означает, что их можно использовать для организации контента таким образом, который удобен для управления исходным кодом и одновременного редактирования. Аддитивная загрузка сцены часто эффективно используется для создания очень больших сцен, потокового контента или даже очень простых сцен, состоящих из нескольких компонентов с отдельными задачами.
В целом, мы рекомендуем хранить данные, зависящие от сцены, в сценах. Например, в случае с запеченным освещением, светом, лайтмапами и настройками окружения все зависит от того, в какой сцене они находятся. Почти все остальное можно хранить в префабах. Если сцена небольшая и содержит особый контент, который будет редактироваться только в ней, имеет смысл хранить все эти данные в одной сцене. Однако важно отметить, что если в сцене присутствуют два объекта GameObject, то любые изменения одного из них приведут к изменениям в файле сцены.
Хотя Smart Merge справляется со сценарием, когда два создателя контента одновременно изменяют два разных объекта в сцене, более сложные изменения могут привести к неразрешимым конфликтам. Мы рекомендуем использовать префабы, чтобы смягчить эту проблему.
Что касается явной структуры сцены, то в Unity Netcode Demo есть полезная блок-схема стандартного расположения сцены для простого проекта, которая похожа на те, что мы видели во многих сценариях.
Сборные конструкции можно использовать для создания модульных, отдельных помещений. Для получения дополнительной информации ознакомьтесь с этим руководством по префабам и вложенным префабам. Самый важный раздел в этом руководстве - раздел "Лучшие практики". Нет никаких четких правил по созданию контента с помощью префабов. Каждая команда должна решить, что ей больше подходит, исходя из своего проекта. Однако есть несколько хороших рекомендаций, которым стоит следовать:
- Думайте о сборных конструкциях как о строительных блоках вашего дома или проекта. Как правило, есть корень Prefab, который представляет собой фундамент дома. Внутри него находятся префабы для каждого компонента многоразового использования, из которых строится остальная часть дома. Они могут быть гранулированными, как подоконник, или широкими, как стена с окнами. Необходимый уровень детализации будет зависеть от того, как создатели контента хотят редактировать свои префабы.
- Префабы могут быть вложены друг в друга. Это означает, что в приведенном выше примере может быть дом Prefab, а также стены, крыша, окна и двери Prefab, из которых состоит дом. Важно отметить, что чем глубже иерархия, тем больше вероятность того, что проект столкнется с проблемами производительности. Обычно мы рекомендуем не превышать 5-7 уровней глубины иерархии Prefab.
- При вложении префабов, как правило, рекомендуется редактировать префабы в режиме префаба. Это гарантирует, что свойства или переопределения Prefab будут установлены в нужном месте. Редактирование свойств префаба в режиме просмотра сцены может привести к тому, что переопределения будут находиться не в том префабе или в самой сцене. Это может привести к непредвиденным последствиям и вызвать конфликты слияния. Иногда необходимо переопределить свойство дочернего префаба в родительском префабе (таким образом можно добиться изменений, не затрагивая каждую ссылку на конкретный префаб). Это стандартный рабочий процесс, но важно быть внимательным, чтобы вносить изменения и применять переопределения в нужных префабах или сценах.
- Все, что находится в префабе, будет загружено и инстанцировано в память во время выполнения, когда префаб будет загружен и инстанцирован. Это означает, что если визуальные эффекты или прикрепленные объекты, которые не всегда присутствуют, находятся внутри префаба, эти объекты будут инстанцированы в память. Это может привести к разрастанию памяти, поскольку каждый инстанс Prefab будет инстанцировать все, что находится внутри него. Если к объектам периодически подключаются визуальные эффекты или модели, лучше иметь систему объединения и менеджер вложений, который добавляет эти компоненты во время выполнения. Все, что относится к системе бассейнов, как правило, не должно размещаться внутри сборного дома.
- Все не обязательно должно быть готовым. Более мелкими строительными блоками могут быть игровые объекты внутри префаба или даже сцены. Если объект уникален для сцены или префаба, нет необходимости создавать для него префаб.
- Сборные варианты следует использовать с осторожностью. Как правило, лучше всего использовать вариант Prefab, когда основные строительные блоки объекта идентичны и имеют лишь простые различия. Например, может быть полезно использовать вариант Prefab для игрового компонента, который имеет идентичный функционал, но разное визуальное оформление. В этом случае изменение основной функциональности повлияет на функциональность как самого префаба, так и его вариантов, но визуальная часть останется переопределенной. Будьте осторожны, создавая слишком сложные варианты префабов, так как изменения в корневом префабе могут привести к непредвиденным последствиям для переопределенного префаба. По общему правилу, система изменения персонажей или любая другая сложная система визуального скиннинга не должна основываться на вариантах Prefab, если только система не очень проста.
Мы рекомендуем создать последовательную стратегию для определения того, что должно быть префабами, а что - игровыми объектами в префабах или сценах.
Если префаб создается непосредственно из FBX-файла, создается специальный вид префаба, называемый моделью префаба. В результате вы получите Prefab-вариант FBX-файла. Любые дополнения или изменения будут сохранены в виде переопределений в файле Prefab. Однако, поскольку большая часть данных хранится в файле FBX, изменения и дополнения к префабу не могут быть применены к модели префаба. Если вы используете рабочий процесс с вариантом модели Prefab, важно свести структурные изменения к минимуму.
Существует два альтернативных рабочих процесса, которые позволяют создавать менее тесно связанные структуры между FBX-моделью и префабом:
Добавление FBX-файла непосредственно в сцену, а затем добавление компонентов или структурных модификаций к игровым объектам в сцене. В этом сценарии все изменения сохраняются в файле сцены. Это может привести к конфликтам слияния, если многие люди используют этот рабочий процесс в одной сцене. Мы рекомендуем этот рабочий процесс только в том случае, если изменения должны жить в сцене и конфликты не являются проблемой.
Создайте стандартный Unity Prefab из взорванной модели. В этом методе FBX-модель перетаскивается в сцену, а затем полностью распаковывается. Затем он используется для создания готового объекта. Эта методология полностью отделяет FBX-файл от префаба. Это удобно, если требуется очень тесная связь между FBX-файлом и префабом. Он больше не будет наследовать структурные изменения, внесенные в исходный FBX-файл. Связь будет только между именами сеток, материалов и анимаций. Все остальное будет находиться в самом файле Prefab. Это может быть полезно для создания совершенно уникальных вариантов FBX-модели. Например, если два персонажа используют одну и ту же модель, но им нужны совершенно разные сетки, материалы или даже разные иерархии, эта методика может быть лучше, чем создание нескольких FBX-файлов, которые занимают лишнюю память и дисковое пространство. Это может быть удобно, когда требуется очень сложная настройка компонентов. Вместо того чтобы исчезать и терять все компоненты игрового объекта, объект остается, и его компоненты можно перенести в новый объект, либо переименованную сетку или материал можно вставить обратно в игровой объект, который теперь ссылается на отсутствующую сетку или материал.
На двух изображениях ниже изменения вносятся в FBX-файл, а затем повторно импортируются. Круг вокруг логотипа Unity на мяче удален. Главная опорная стойка переименована. Материал основного мяча изменен с черного на зеленый, а над логотипом стенда появился новый родитель с трансформациями, которые поднимают его над моделью.
Все это тщательно согласовано как в FBX-файле, так и в модели Prefab. В немодельных Prefab сохраняется оригинальная иерархия, названия и материалы. Удаленный меш теперь является отсутствующим мешем, но объект GameObject все еще присутствует. Переименованная сетка также не видна, потому что она ссылается на имя сетки, которое больше не существует в модели. Измененный материал не обновляется, поскольку объект GameObject по-прежнему ссылается на исходный материал. Кроме того, изменение иерархии не соблюдается, и сетка остается на том же месте, поскольку ее родитель не изменился.
На приведенных ниже изображениях "до" и "после" результаты внесенных выше изменений отображаются в иерархии сцен. FBX-файл, на который ссылаются непосредственно в сцене, и стандартная модель Prefab реагируют на любые изменения, внесенные в исходный FBX-файл. Распакованный Prefab сохраняет свою первоначальную иерархию и не реагирует на удаление или изменение имени.
Важно тщательно выбирать, какая методология будет использоваться в том или ином сценарии. Если необходима тесная связь между редактором и FBX-файлами, то стандартная модель Prefab, вероятно, будет лучшим выбором. Если требуется очень тесная связь (например, очень гибкая система персонажей, в которой сетки или материалы могут часто меняться местами), то лучше всего подойдет создание немодельных префабов с мягкими ссылками на компоненты FBX-файла.
В случае графических инструментов, таких как Shader Graph или Visual Effect Graph, Shader Graph Subgraphs и Visual Effect Graph Subgraphs можно использовать для создания многократно используемых функциональных узлов, которые находятся в отдельном файле и могут быть отредактированы без возникновения конфликтов в каждом Shader Graph или Visual Effect Graph. Это позволяет пользователям разделять задачи подобно префабам и сценам. Мы рекомендуем разработать стратегию повторного использования, используя преимущества подграфов там, где это имеет наибольший смысл.
Избегайте глубоких иерархий - это универсальное утверждение для контента, относящегося к сценам, префабам, игровым объектам, анимации, пользовательскому интерфейсу и всему остальному. В целом, глубокие иерархии любого типа обычно приводят к проблемам с производительностью. Глубокая иерархия анимации в персонажах приведет к тому, что из-за проблем с производительностью процессора на экран будет выводиться меньше персонажей. В связи с этим мы рекомендуем размещать все анимированные иерархии в корневом узле сцены, чтобы повысить производительность. Выбор плоской иерархии при использовании UGUI и Canvases приведет к повышению производительности за счет меньшего количества каскадных обновлений макета. Глубоко вложенные префабы могут вызвать проблемы с производительностью, а также привести к путанице, если переопределения не были тщательно продуманы.
Мы часто видим, что команды хранят исходный контент в разных местах, от сетевых дисков до локальных машин. Мы рекомендуем помещать все важные исходные материалы в систему контроля версий тем или иным способом.
Чаще всего мы видим, что исходный контент помещается в папку в системе контроля версий, которая находится вне папки Assets. Это гарантирует, что Unity не попытается импортировать содержимое из исходных файлов напрямую. Файлы Maya, 3ds Max, Blender и Photoshop будут автоматически импортироваться в модели и текстуры, если они находятся в папке assets. Хотя Unity поддерживает это, мы не рекомендуем использовать такую практику. Кроме того, мы рекомендуем зеркалировать исходный каталог с содержимым в каталоге Assets, чтобы отслеживание активов было достаточно простым.
Исходное содержимое должно быть маскируемым для пользователей, поскольку большинству пользователей оно не понадобится, а исходное содержимое может занимать очень большой объем на диске (считайте, терабайты). В некоторых программах контроля версий создание масок содержимого довольно просто. В системе управления версиями Unity это достигается с помощью замаскированных файлов. В Perforce представления используются для маскировки содержимого от клиента. Git, однако, не предназначен для работы таким образом. В связи с этим мы рекомендуем создавать отдельный Git-репозиторий для исходного контента или отдельный репозиторий для каждого типа контента (например, 3D-художникам может никогда не понадобиться синхронизировать полный источник звука и наоборот).
Создание контента, работающего с системой контроля версий и поддерживающего нескольких пользователей, работающих в одних и тех же областях, - непростая задача. Однако Unity предоставляет строительные блоки, которые можно использовать при тщательном продумывании и планировании для создания масштабного контента, не приводящего к неразрешимым конфликтам слияния или потере работы.