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

Этот блог — первый в серии от Mega Cat Studios, где они делятся своим опытом работы с Unity и решениями для реальных задач коммерческой разработки игр. Надеемся, вы найдете здесь несколько полезных советов!

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

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

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

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

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

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

Самое сложное — это не понять эти лучшие практики. Это придерживаться их с самого начала и сохранять эту дисциплину даже спустя годы.

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

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

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

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

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

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

3. Подключай и играй: Соединяйте небольшие, целенаправленные блоки для создания сложного поведения, а не написание разрастающихся скриптов "бога".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Урок 5: Подготовьте свои активы

"Ошибаться - это человечно, прощать - божественно."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Строительство будущего

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

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

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