Масштабирование рабочих процессов Unity: Уроки средних и крупных проектов

Эта запись в блоге — первая в серии от Mega Cat Studios, где они делятся своим опытом работы с Unity и решениями для реальных задач коммерческой разработки игр. Ознакомьтесь с другими публикациями в этой серии, которые охватывают ввод данных, а также дизайн уровней и окружения:

• Попадание в десятку: Как управляемая событиями Input System в Unity обеспечивает управление в Backyard Baseball 2026
• Как переосмыслить классическую спортивную игру для нового поколения с помощью дизайна уровней, построения мира и визуальных эффектов
• Рендеринг в масштабе: Эффективные стратегии для огромного количества объектов

Надеемся, вы почерпнете для себя несколько отличных советов!

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

В Mega Cat Studios мы начинаем все наши проекты со страстью, поэтому понимаем привлекательность работы в быстром и свободном темпе, когда хочется сделать всё как можно скорее. Для прототипа такой подход вполне подходит, и, по правде говоря, мы его рекомендуем! Мудрый разработчик знает, когда нужно отдавать приоритет скорости итерации, а когда — стабильности. Потому что, когда вы выходите из фазы прототипирования, этот «быстрый и свободный» подход становится обузой.

Мы много раз переживали этот переход в Mega Cat Studios и с каждым проектом узнаём что-то новое. Мы хотели бы поделиться некоторыми уроками, которые мы извлекли, чтобы подготовить наш самый последний проект, Backyard Baseball, к запуску.

Урок 1: Структура для масштабирования

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

• Организуйте по типу и назначению: Мы группируем по типу, а затем по назначению. Тип включает такие категории, как арт, код и аудио. Назначение — это то, для чего они используются. Интуитивно понятная организация снижает порог вхождения; новый художник должен точно знать, где находится спрайт «Character Idle», не задавая вопросов.
• Упрощайте сцены: Мы отказались от «мега-сцен» в пользу небольших сцен, таких как главная сцена, содержащая данные сохранений и критически важные системы, а также титульный экран и сцены с бейсбольным полем, которые загружаются аддитивно в зависимости от того, находится ли игрок в матче. Аналогичным образом мы используем префабы для автономных функций, поэтому изменения с меньшей вероятностью будут сериализованы в файле сцены, который их содержит. Это позволяет художнику работать над окружением, пока дизайнер настраивает игровой процесс на том же «уровне» без конфликтов файлов (подробнее об этом позже).
• Настройте систему Addressables: Вместо традиционных папок Resources мы используем систему Addressables для загрузки ассетов только по мере необходимости, что позволяет экономно расходовать память. Кроме того, загрузка ассета с помощью его ключа Addressable более понятна и менее подвержена сбоям, чем загрузка по пути к файлу в конкретном месте папки Resources.

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

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

«На этапе прототипирования, поскольку кода почти нет, допустимо сначала сделать функционал рабочим, а уже потом модульным», — говорит Паоло Роксас, разработчик Backyard Baseball. «Мы хотим посмотреть, как будет развиваться проект, прежде чем усложнять его».

Урок 2: Работайте с Unity, а не против нее

«Нет ничего мощнее, чем создание строительных блоков — будь то компоненты, ScriptableObjects или пользовательские классы, — которые являются сфокусированными, лаконичными и самодостаточными», — говорит Дэвид Чавес Арментерос, руководитель отдела разработки в Mega Cat Studios. Unity в своей основе поддерживает модульность. Чтобы оставаться гибкими, мы следуем трем классическим принципам:

1. Единственная ответственность: Каждый скрипт или класс должен иметь одну четко определенную роль.

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

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

Урок 3: Используйте ограничения, чтобы обрести свободу

Assembly Definitions (AsmDefs) — это конструкции C#, которые группируют ваш код. Их заявленное преимущество — сокращение времени компиляции, но их секретная суперсила — обеспечение модульности.

Нико Гауденци, ведущий разработчик и ненавистник спагетти-кода, ручается за них.

«В Backyard Baseball слой Input System и слой игрового процесса находятся в разных DLL. Игровой процесс полностью не зависит от деталей ввода».

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

Урок 4: Тестируйте умнее, а не усерднее

По мере роста проектов может возникнуть «эффект домино»: Небольшое изменение здесь ломает что-то там. Хорошая архитектура очень помогает, но это не панацея.

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

«Тесты работают как список требований», — говорит Нико. «Они описывают, чего ожидать, и предоставляют ключевые варианты использования».

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

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

Часто ломается то, чего совсем не ожидаешь, и именно поэтому тестирование так важно.

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

Test Runner в Unity работает наиболее эффективно, когда ваши системы модульны, что является еще одной причиной, по которой мы используем Assembly Definitions.

Урок 5: Приведите свои ассеты в порядок

«Человеку свойственно ошибаться, а прощать — божественно».

Но создать системы, предотвращающие человеческие ошибки изначально, — это просто легендарно.

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

Чтобы снизить этот риск, можно ограничить доступ к ассетам, но это приведет к возникновению «узкого места» из-за множества причин, по которым игровой контент требует корректировки:

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

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

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

Автоматизация помогает и здесь:

• AssetPostprocessor: Мы пишем собственную логику импорта, которая обеспечивает соблюдение стандартов проекта.
• OnValidate: Мы используем метод OnValidate для сообщения об отсутствующих ссылках в редакторе, который всегда срабатывает перед сборкой.

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

«Никогда не тратьте 10 дней на автоматизацию задачи, которая занимает 10 минут при ручном выполнении», — предостерегает Дэвид.

Урок 6: Освойте человеческий фактор (сотрудничество)

Системы Version Control, такие как Git, — это первое, что приходит на ум при координации сотен изменений от десятков разработчиков каждый день. Дэвид рекомендует эти проверенные методики для всех наших проектов в Mega Cat:

• Небольшие атомарные изменения: Избегайте «мегакоммитов», затрагивающих сразу множество систем. Изолируйте работу над отдельными функциями в ветках до тех пор, пока они не станут стабильными и не пройдут проверку. Сохраняйте отдельные изменения в отдельных коммитах для хорошо документированной истории версий, что также упрощает cherry picking и другую магию Git, когда это необходимо.
• Ежедневное слияние с основной веткой: Поддерживайте ветки функций, отделов и долгоживущие ветки в актуальном состоянии относительно основной ветки, так как это может уменьшить размер и сложность финальных слияний, помогая предотвратить масштабные конфликты.
• Проверка запросов на слияние: Это первый рубеж контроля качества, где вы находите ошибки, обеспечиваете соблюдение стандартов проекта и гарантируете согласованность с общей системой.

«В крупных проектах Unity проверка кода — это не просто формальность», — советует Дэвид. «Это ключевая часть предотвращения конфликтов и обеспечения общего качества проекта».

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

Существуют особые советы и рекомендации, которые помогут сделать Version Control в Unity максимально эффективным. Сцены и префабы составляют основу вашего проекта, поэтому оптимизируйте их не только для производительности CPU, но и для совместной работы разработчиков.

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

Это важно, поскольку конфликты слияния в сценах и префабах сложнее всего разрешить, так как их данные трудно читаемы для разработчиков. Чтобы упростить этот процесс, мы сериализуем эти файлы как текст, а не как бинарные данные, и включаем функцию автоматического слияния в нашей конфигурации Git для YAML-файлов. Благодаря этому Git с большей вероятностью самостоятельно разрешит конфликты слияния и сэкономит время разработчиков для важной работы над новыми функциями.

Но несмотря на все это:

«Предотвращение конфликтов — это обычно лучшая стратегия, чем попытки их разрешить», — говорит Нико.

Четкое распределение ответственности за ассеты может значительно помочь в этом.

«Определите, кто может изменять конкретные сцены или префабы», — говорит Дэвид. «Тогда члены команды будут запрашивать изменения для объектов, не входящих в их зону ответственности, вместо того чтобы редактировать ассеты напрямую».

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

Как и всегда, найдите процедуру, которая лучше всего подходит вашей команде.

Создание будущего

В Mega Cat Studios мы поняли, что масштабирование проекта на Unity — это не столько «усердное написание кода», сколько архитектурная дисциплина. Уважая компонентную природу Unity, устанавливая границы с помощью Assembly Definitions и организуя ассеты с прицелом на будущее, мы сохраняем творческий поток этапа прототипирования, не допуская накопления технического долга до запуска проекта.

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

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