С успешным появлением Nintendo Switch разработчики получили новую уникальную платформу для выпуска своих продуктов. Для многих студий это означает привлечение ранее выпущенных игр к совершенно новой аудитории. В Bulkhead Interactive мы решили перенести нашу головоломку 2016 года «The Turing Test» на Nintendo Switch.
Первым шагом в проекте была подгонка проекта под самую последнюю версию движка, чтобы мы могли опираться на последнюю и лучшую версию Unreal Engine. Хотя это был огромный скачок для игры трехлетней давности, переход кода был в основном быстрым, в сочетании с некоторыми незначительными изменениями, которые мы должны были внести по пути.
Обновление повлекло за собой некоторые существенные изменения рендеринга, которые сделали конечную презентацию заметно отличающейся , помимо прочего, благодаря появлению нового кинематографического тонального преобразователя . Это изменение потребовало работы по градации цвета, некоторых настроек зеркальности и нового прохода по настройке отражения в уровнях, чтобы привести внешний вид игры в большее соответствие с первоначальным видением художников.
Погружение важно для сюжетной игры, поэтому мы хотим, чтобы игроки проводили как можно меньше времени глядя на загрузочные экранов. С этой целью Unreal Engine предлагает несколько решений для потоковых уровней, нацеленных на широкий спектр игровых архитектур от потокового вещания общего уровня до более специализированной мировой композиции. Для в основном линейной игры, такой как The Turing Test, потоковое вещание общего уровня - надежное решение, которое позволило нам амортизировать затраты на загрузку фрагментов игрового мира, сохраняя при этом низкую нагрузку на память и избавляя от максимально возможного количества блокирующих нагрузок.
Недостатком, однако, является то, что сборщик мусора должен работать сверхурочно, вызывая всплески игрового потока во время игры. На относительно ограниченной портативной системе, такой как Nintendo Switch, это вызвало у нас значительные проблемы во время потоковой передачи уровней. Новые акторы и компоненты должны быть зарегистрированы, инициализированы и сопоставлены, когда они представлены в мире, в то время как сборщик мусора имеет дело с вещами, покидающими активный игровой набор. Это было осложнено сложными акторами с десятками компонентов, которые использовались на протяжении всей игры, что, в общем, просто не возникало как проблема на других платформах.
Мы экспериментировали с возможностью не замечать заминки и позволять игрокам свободно перемещаться во время переходов, однако это привело к нестабильному физическому взаимодействию в виде жизненно важных игроков (объекты, необходимые для прохождения уровня), выбрасываемые из сцены после столкновения с ними во время голодный мир тикает. В конце концов, мы решили ввести небольшую задержку, когда игрок будет укореняться на месте, но нам было позволено осмотреться, пока идет следующий уровень, в качестве своего рода решения на полпути.
Если есть один большой совет, который мы можем поделиться с подобными случаями, это изучить доступные варианты потоковой передачи уровней (Настройки проекта> Потоковая передача). Они могут ограничивать количество времени на кадр, затрачиваемое на инициализацию и демонтаж субъекта и компонента, а также другие подобные ценные переменные.
Все предыдущие выпуски The Turing Test были доступны только на английском языке, но локализация EFIGS является базовым требованием для прохождения сертификации на Nintendo Switch. Это оказалось непростой задачей, поскольку в тесте Тьюринга содержится много письменной информации, встроенной в текстуры среды, которые выступают в качестве важных элементов рассказывания историй.
Решением этой проблемы было динамическое создание виджетов и их рендеринг в текстуры. Это было сделано только во время загрузки экранов или когда игрок вручную меняет язык игры. Эта система избавила нас от необходимости иметь несколько текстур для каждого экземпляра текста в мире и не требовала дополнительной работы во время итераций по переводам.
Чтобы игроку было комфортно, нам нужно было уменьшить влияние рендеринга и игровых потоков на частоту кадров в игре. По большей части, мы оказались в узком месте, когда код геймплея был оптимизирован по всем направлениям. Для диагностики основных областей нашей деятельности мы использовали различные команды STAT, доступные через командную строку. После того как мы обнаружили проблему, мы углубились в анализ встроенных профилировщиков, в том числе недавно представленного Unreal Insights, или графического отладчика, предоставленного платформой, для анализа источников затрат и разработки решений.
Мы перевели более дорогие операции Blueprint на C ++ и по возможности избегали ненужных тиков акторов. Замена большого количества скелетных сеток статическими и удаление столкновений с движущимися объектами (например, вентиляторами) гарантировали, что затраты на игровые нити будут более управляемыми. Мы столкнулись с несколькими проблемными областями, где прозрачность помечена как проблема. Использование режима просмотра сложности шейдера помогло нам определить, где происходило перерисовывание. Затем мы изменили материалы, сетки и системы частиц, чтобы обеспечить постоянство частоты кадров.
Потенциально поляризационный выбор, который мы сделали, заключался в том, чтобы ограничить частоту кадров игры до 45 кадров в секунду, так как мы обнаружили, что это разумная цель, которую мы можем поддерживать в сценах различной логической и графической интенсивности. Это не совсем желанные 60 кадров в секунду, но все же на шаг выше 30. Мы увидели небольшой выигрыш в небольшой модуляции некоторых графических опций вверх или вниз для любой из стандартных частот кадров.
В качестве альтернативы мы могли бы опираться на современные функции рендеринга, предоставляемые Unreal Engine, такие как динамическое разрешение, но после некоторого обсуждения мы остановились на более традиционном подходе.
Среди наиболее интенсивных функций рендеринга в реальном времени, которые мы определили на Nintendo Switch, были окружающая окклюзия и отражения на экране, Мы посчитали их жизненно важными для визуальной достоверности окружающей среды, поэтому с осторожностью настроили их качество на то, что мы сочли разумным для достижения наших целей. Большая часть графической тонкой настройки была сделана на лету во время разработки благодаря блестящей поддержке этого в двигателе. Поскольку мы постепенно сходились к конечным значениям, мы использовали профили устройств, ведущие к концу проекта.
В конце концов, инструменты и функции, предоставляемые Unreal Engine, позволили нашей игре быстро принять форму на Nintendo Switch и дали нам время для оптимизации наших ресурсов и кода, предоставляя игрокам более плавный, адаптированный опыт.
Первым шагом в проекте была подгонка проекта под самую последнюю версию движка, чтобы мы могли опираться на последнюю и лучшую версию Unreal Engine. Хотя это был огромный скачок для игры трехлетней давности, переход кода был в основном быстрым, в сочетании с некоторыми незначительными изменениями, которые мы должны были внести по пути.
Обновление повлекло за собой некоторые существенные изменения рендеринга, которые сделали конечную презентацию заметно отличающейся , помимо прочего, благодаря появлению нового кинематографического тонального преобразователя . Это изменение потребовало работы по градации цвета, некоторых настроек зеркальности и нового прохода по настройке отражения в уровнях, чтобы привести внешний вид игры в большее соответствие с первоначальным видением художников.
Недостатком, однако, является то, что сборщик мусора должен работать сверхурочно, вызывая всплески игрового потока во время игры. На относительно ограниченной портативной системе, такой как Nintendo Switch, это вызвало у нас значительные проблемы во время потоковой передачи уровней. Новые акторы и компоненты должны быть зарегистрированы, инициализированы и сопоставлены, когда они представлены в мире, в то время как сборщик мусора имеет дело с вещами, покидающими активный игровой набор. Это было осложнено сложными акторами с десятками компонентов, которые использовались на протяжении всей игры, что, в общем, просто не возникало как проблема на других платформах.
Если есть один большой совет, который мы можем поделиться с подобными случаями, это изучить доступные варианты потоковой передачи уровней (Настройки проекта> Потоковая передача). Они могут ограничивать количество времени на кадр, затрачиваемое на инициализацию и демонтаж субъекта и компонента, а также другие подобные ценные переменные.
Решением этой проблемы было динамическое создание виджетов и их рендеринг в текстуры. Это было сделано только во время загрузки экранов или когда игрок вручную меняет язык игры. Эта система избавила нас от необходимости иметь несколько текстур для каждого экземпляра текста в мире и не требовала дополнительной работы во время итераций по переводам.
В качестве альтернативы мы могли бы опираться на современные функции рендеринга, предоставляемые Unreal Engine, такие как динамическое разрешение, но после некоторого обсуждения мы остановились на более традиционном подходе.
Среди наиболее интенсивных функций рендеринга в реальном времени, которые мы определили на Nintendo Switch, были окружающая окклюзия и отражения на экране, Мы посчитали их жизненно важными для визуальной достоверности окружающей среды, поэтому с осторожностью настроили их качество на то, что мы сочли разумным для достижения наших целей. Большая часть графической тонкой настройки была сделана на лету во время разработки благодаря блестящей поддержке этого в двигателе. Поскольку мы постепенно сходились к конечным значениям, мы использовали профили устройств, ведущие к концу проекта.
Комментарии
Отправить комментарий