Монджил

Mongil: Star Dive возрождает мир Monster Taming для мировой аудитории. Каковы были основные цели команды при модернизации франшизы для нового поколения игроков?

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

Мы также пересмотрели основные функции оригинальной игры и перестроили их в соответствии с более современной философией дизайна. Хорошим примером является слияние монстров, которое было одной из знаковых систем оригинальной игры. В Mongil: Star Dive это наследие развивается в систему «Monsterling Combine», сохраняя азарт от прогресса и открытий, делая при этом опыт более утончённым и интуитивно понятным. Мы применили аналогичный подход к бою, сделав прямое управление персонажем более быстрым, динамичным и приносящим большее удовлетворение современным игрокам.

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

Игра сочетает в себе повествование, основанное на персонажах, сбор монстров и динамичные боевые действия. Как команда подходила к балансировке повествования, характера персонажей и игровых систем для создания целостного опыта?

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

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

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

Mongil: Star Dive создан на движке Unreal Engine 5. Каковы были основные преимущества, которые UE5 предоставил при создании визуального стиля и мира игры?

На самом деле мы начали проект не на Unreal Engine 5. Разработка началась на Unreal Engine 4, и со временем мы постепенно переходили на него. Из-за этого наш опыт работы с UE5 был не столько связан с внедрением его функций с первого дня, сколько с оценкой того, как движок эволюционировал, чтобы поддержать технические задачи, которые мы уже решали сами.

Одним из самых больших преимуществ Unreal Engine для нас стал прямой доступ к исходному коду движка. Эта гибкость была особенно важна с визуальной точки зрения. Мы реализовали собственную модель затенения, чтобы иметь возможность контролировать конвейер освещения на более глубоком уровне и добиться именно того вида, который мы хотели. Наша цель заключалась не в полностью плоском мультяшном стиле, а в стилизованном виде с читаемостью в стиле cel-shading и более реалистичной реакцией материалов.

Стандартных моделей затенения было недостаточно для этого, поэтому возможность настраивать рендеринг и освещение на уровне движка была огромным преимуществом. Мы также получили большую пользу от таких инструментов, как Material Graph, Animation Blueprint и более широкой платформы Blueprint. Они дали программистам чёткий способ визуально организовать сложную логику, позволяя при этом художникам экспериментировать более непосредственно, не полагаясь на код для каждой итерации. Такой баланс дал команде большую творческую и техническую гибкость.

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

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

В игре используется художественный стиль, вдохновлённый аниме, который сочетает в себе лица персонажей в стиле cel-shading с более реалистичными материалами и освещением. Как команда технически добилась такого баланса между стилизованными персонажами и высококачественным рендерингом?

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

Для таких областей, как лицо и кожа, где стандартного затенения было недостаточно, мы также использовали методы Signed Distance Field (SDF) для получения более стабильных и управляемых результатов. Мы применили аналогичный подход к контурному освещению и бликам, настроив их вместо того, чтобы полагаться исключительно на стандартные реализации, чтобы они лучше поддерживали нужный нам стиль. В то же время для таких материалов, как одежда, мы хотели сохранить сильные стороны физически основанного рендеринга, потому что он добавлял богатство и достоверность материалов в общее изображение.

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

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

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

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

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

Одной из самых интересных механик игры является система Monsterling, где захваченные монстры становятся снаряжением, которое изменяет способности и боевые эффекты. Как эта система развивалась в процессе разработки и какие технические задачи возникли при её реализации?

Система Monsterling была создана как способ воплотить одну из определяющих идей оригинальной франшизы Monster Taming, адаптировав её к направлению Mongil: Star Dive. В оригинальной игре игроки собирали монстров, сливали их в формы более высокого уровня и выводили их непосредственно в бой. Однако для Star Dive мы хотели, чтобы основной игровой процесс и эмоциональная направленность оставались сосредоточенными на игровых персонажах. Это привело нас к переосмыслению монстров как «монстрлингов» — отдельной системы, которую персонажи используют, а не отдельного игрового списка.

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

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

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

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

Команда упомянула о разработке собственного триггерного инструмента для управления механикой боя, поведением ИИ и логикой событий. Можете объяснить, как работает этот инструмент и как он помог дизайнерам быстрее работать над сценариями боя?

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

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

На практике из-за производственных ограничений сторона отладки развивалась не так далеко, как мы надеялись. Вместо этого мы применили более прагматичный подход, настроив существующие интерфейсы Unreal Engine, такие как Outliner, Inspector и Blueprint Details, чтобы максимально упростить работу. Мы также уделили большое внимание удобству использования для дизайнеров, поэтому переменные внутри записей Событие, Условие и Действие можно было настраивать напрямую через простой рабочий процесс на основе кликов.

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

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

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

Mongil: Star Dive запускается на ПК, PlayStation 5 и мобильных устройствах. Какие технические трудности были самыми большими при создании кроссплатформенного опыта такого масштаба?

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

Одной из основных причин было то, что проект долгое время строился на Unreal Engine 4, и мы уже разработали собственную абстракцию ввода в соответствии с потребностями проекта. Хотя Unreal Engine 5 предлагает надёжные встроенные решения, такие как Common UI и Enhanced Input, полностью заменить структуру, которая накапливалась за годы разработки, было нереально. В то же время нам нужно было поддерживать навигацию на основе контроллера, фокус-поток и требования к консоли, специфичные для платформы, что требовало большой координации между геймдизайном, UI-дизайном и инженерией.

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

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

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

Оптимизация визуально насыщенной игры на Unreal Engine 5 для мобильного оборудования может быть особенно сложной. Какие стратегии использовала команда, чтобы поддерживать производительность и эффективность использования памяти на таких разных платформах?

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

Что касается искусства, то мы приложили немало усилий, особенно к ассетам окружения. Целью было максимально сократить количество полигонов, сохраняя при этом визуальные эффекты, которые не ощущались бы скомпрометированными на ПК. Достижение этого баланса потребовало от художественной команды много итераций. Со стороны рендеринга мы приняли очень требовательное решение, перейдя на отложенный рендеринг на базе Vulkan на мобильных устройствах. Запуск среды реального времени с отложенным рендерингом на мобильных устройствах чрезвычайно сложен как с точки зрения тепловыделения, так и с точки зрения производительности, но мы посчитали это необходимым, чтобы уменьшить визуальный разрыв между мобильными устройствами и другими платформами.

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

Что касается глубины сцены, то в версии для ПК используются Mesh Distance Fields, чтобы придать отдалённым структурам более сильное ощущение объёма. Чтобы приблизить аналогичный вид на мобильных устройствах, мы настроили Mobile SSAO и использовали его более агрессивно. Это дало нам удовлетворительные результаты в целом, но также создало побочные эффекты, особенно в отношении листвы, где глубина могла начать ощущаться преувеличенной. Чтобы решить эту проблему, мы разделили обработку листвы и не листвы на разные проходы, чтобы мы могли более точно настроить их.

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

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

Может показаться амбициозным сказать, что игра была разработана специально для пост-запускного расширения, но наша реальная цель была довольно проста: построить структуру, которая позволит нам продолжать добавлять контент, не требуя каждый раз больших объёмов новой разработки. Для внутриигрового контента ключевой частью этой стратегии является система триггеров, о которой мы упоминали ранее. Новые регионы, игровые механики, шаблоны боссов и сценарии с сценариями часто можно построить, комбинируя модули, которые уже существуют в системе.

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

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

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

Кен Ким, генеральный директор в Netmarble Monster

Интервью проведено Дэвидом Джагно (David Jagneaux)