Перестройка классики PS2 с помощью «Наследия Каина»

При работе над ремастерами классических игр дело редко бывает настолько простым, как увеличение разрешения, замена текстур и выпуск результата на современных платформах. В случае с «Legacy of Kain: Defiance» компаниям PlayEveryWare и Crystal Dynamics пришлось заново изучить полностью кастомный движок начала 2000-х, устранить устаревшие конвейеры ресурсов, модернизировать презентацию игры и сохранить оригинальный стиль одной из самых любимых игр жанра dark fantasy action-adventure того времени.

Чтобы узнать больше о процессе создания «Legacy of Kain: Defiance Remastered», мы поговорили с руководителем разработки PlayEveryWare Райаном Мейером, старшим инженером Джиной Хён и арт-директором Crystal Dynamics Моникой Еросовой. Команда обсудила сложности переноса оригинального движка с 32-битного на 64-битный, перестройку системы камеры, восстановление и систематизацию архивных материалов, восстановление неиспользуемого контента, обновление моделей персонажей и окружения, а также балансировку современных технических ожиданий с оригинальной художественной идентичностью игры.

Приступая к ремастеру «Legacy of Kain: Defiance», какие технические сложности были самыми большими при работе над такой знаковой игрой начала 2000-х? Были ли какие-то конкретные системы или ресурсы, которые особенно сложно было модернизировать?

Райан Мейер — руководитель разработки: Самая большая сложность заключалась в том, что Defiance была создана на полностью кастомном движке более двадцати лет назад. Она была разработана для оборудования той эпохи, поэтому прежде чем мы могли даже подумать о современных платформах, нам пришлось глубоко изучить движок и переписать значительные его части. Одной из первых проблем был перенос движка с 32-битного на 64-битный. Это была фундаментальная работа.

Без этого интеграция современных консольных SDK была бы невозможна. После этого конвейер рендеринга потребовал внимания. Оригинальная игра была разработана для соотношения сторон 4:3, поэтому при переносе на 16:9 многое ломалось. Привязка пользовательского интерфейса, экранные эффекты и предположения камеры были построены вокруг квадратного кадра. Исправление этого означало отслеживание и корректировку этих предположений и проверку того, что всё продолжает правильно рендериться.

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

Конвейер контента, вероятно, был самой необычной задачей. Для создания и редактирования ресурсов использовались специальные внутренние инструменты, но документации было мало или совсем не было. Сначала нам нужно было подтвердить, что эти инструменты вообще существуют, а затем выяснить, как они работают. Это было похоже на археологию кода. Как только мы разобрались в конвейере, мы столкнулись со следующей проблемой. Оригинальные ресурсы были созданы в версии 3D Studio Max, которая больше не доступна. Для практических целей этой цепочки инструментов больше не существует.

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

Как выглядел процесс восстановления и организации оригинальных материалов разработки? Вы работали с архивным исходным кодом и библиотеками ресурсов или некоторые части игры требовали реконструкции на основе розничных сборок?

РМ: Crystal Dynamics проделала очень хорошую работу по сохранению своих архивов, что имело большое значение для этого проекта. Мы работали с полными материалами проекта в том виде, в каком они существовали вокруг оригинального релиза, не пытаясь реконструировать игру на основе розничных сборок.

На самом деле архив выходил далеко за рамки исходного кода и библиотек ресурсов. Там было много предпроизводственных материалов, вырезанного контента и закулисных ресурсов. Это дало нам более чёткое представление о том, как изначально была построена игра и как развивались различные системы и контент.

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

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

Моника Еросова — арт-директор: Исходные материалы Defiance удивили нас тем, насколько много неиспользованного материала было доступно. Разработчики оригинала создавали более масштабные уровни, но они были отменены и так и не были завершены, когда сюжет был изменён. Они начали перепроектировать многие уровни-кузницы из предыдущей игры, Soul Reaver 2, но решили отправить Разиэля и Каина исследовать Цитадель, а не создавать выделенные уровни-кузницы для Разиэля.

Например, в схемах сверху и описаниях головоломок для локации «Водяная кузница» указано, что Разиэлю нужно было осушить главную комнату храма, чтобы получить доступ к фонтану Света посередине и открыть дверь в дальнем конце. Однако ни одна из этих механик не работает, так как на каком-то этапе разработки всё было заброшено.

Как вы решали, что восстанавливать, что документировать, а что оставить нетронутым для ремастера?

Я: Это хороший вопрос, ведь не всё стоит включать. Некоторые уровни состояли из одиночных комнат без текстур и без содержимого, поэтому мы их, естественно, пропустили. Было много разных тестовых комнат, например, специальные настройки для разрушаемых объектов, дверей, появления врагов и т. д. В одной комнате даже был гигантский чайник, не спрашивайте зачем! Для финального релиза мы тщательно составили список, в который вошли самые интересные уровни, например легендарная «Водяная кузница» или ранняя расширенная зона «Цитадель». В ней был отражён оригинальный сюжетный план, где Разиэль и Каин начинали с одной точки в Доме капитула, как это было видно в конце Soul Reaver 2. Когда сюжет был изменён так, чтобы действие происходило спустя годы после той игры, планировка Цитадели была переработана и полностью ретекстурирована.

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

РМ: С точки зрения инструментов, большинство из того, что мы использовали, было создано специально для работы рядом с оригинальным движком или прямо внутри него. Цель заключалась не в замене движка, а в его расширении таким образом, чтобы сделать его совместимым с современными платформами. Что касается рендеринга, мы опирались на наше знакомство с оборудованием Gen 8 и Gen 9 и реализовали собственные серверные части рендеринга, которые могли бы работать без проблем с Defiance.

Это включало добавление DirectX 11 и DirectX 12, чтобы мы могли выпускать игры в GDK, сохраняя при этом минимальные характеристики на одном уровне с предыдущими ремастерами Soul Reaver. Что касается ассетов, ключевым элементом был конвейер преобразования. Как только мы его создали, мы смогли перенести большую часть оригинальных ригов и данных анимации.

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

Многие ранние игры эпохи PlayStation 2 использовали сильно модифицированные движки. Как выглядел первоначальный технологический стек для Defiance и насколько он был совместим с современными рабочими процессами при начале ремастера?

РМ: Первоначальный технологический стек для Defiance был полностью настроенным движком, что было довольно стандартно для игр эпохи PS2. Возвращение к чему-то подобному действительно заставляет осознать, сколько мы сейчас воспринимаем как должное (или, по крайней мере, сколько я воспринимаю как должное). Многие системы, которые вы ожидаете просто увидеть в чём-то вроде Unreal Engine или Unity, просто отсутствовали, поэтому всё новое приходилось создавать с нуля.

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

Не знаю, помните ли вы, как в школе на уроках математики думали: «Когда я буду использовать это в реальной жизни?» Здесь. Здесь вы это используете. Всё это... и даже больше. Это один из тех моментов, когда всё, чему вы научились много лет назад, снова имеет значение.

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

Это открыло ещё одну проблему. Теперь игроки могли заглянуть в места, которые никогда не предназначались для просмотра. Многое из этого выглядело так, будто вы оказались не с той стороны съёмочной площадки. Были односторонние стены, отсутствующие полы и потолки, а также недостроенные комнаты. Чтобы исправить это, нам пришлось создать много новой геометрии и текстур, чтобы заполнить эти пробелы. И дело было не только в том, чтобы сделать его HD. Оно также должно было соответствовать оригинальному виду, чтобы не выглядеть неуместно.

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

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

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

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

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

При обновлении моделей персонажей, окружений и текстур, как команда балансировала между сохранением оригинального художественного замысла и использованием современных техник рендеринга?

Я: У Defiance был совершенно другой художественный подход по сравнению с Soul Reaver 2. Они переработали практически всё: от окружения и врагов до главных героев. Например, в Defiance больше классов охотников на вампиров, но их лица больше похожи на карикатуры, поэтому мы попытались смягчить это, улучшив черты лица, но при этом оставаясь верными оригинальным формам. Мы также разнообразили внешний вид охотниц-вампиров, которые раньше были просто перекраской и заменой голов между двумя классами.

Что касается текстур, мы в основном сосредоточились на поиске исходных фотографий, которые использовала оригинальная команда, поэтому при нажатии кнопки происходит плавный переход между режимами SD и HD. Я очень горжусь нашей командой за то, что мы смогли сохранить верность оригинальной работе с текстурами, благодаря тому объёму исследований текстур, который мы вложили в этот проект.

Как команда подходила к оптимизации производительности для современных платформ, сохраняя при этом ощущение оригинального боя, систем камеры и механики перемещения?

РМ: Когда вы заходите так далеко назад для ремастера, у вас на самом деле появляется приличный запас для работы, так что производительность не является основным ограничением в том же смысле, как это было бы для новой игры. Тем не менее, это не то, что можно игнорировать, особенно когда вы начинаете использовать более качественные активы. Мы внедряли HD-модели и текстуры более высокого разрешения по всем направлениям, что сразу увеличивает нагрузку на память и стоимость потоковой передачи.

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

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

Для разработчиков, заинтересованных в сохранении и работе над ремастерами, какие уроки извлекла команда из работы над Legacy of Kain: Defiance, которые могут помочь другим, работающим со старыми кодовыми базами и устаревшими конвейерами активов?

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

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

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

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

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

PlayEveryWare и Crystal Dynamics

Интервью провёл Дэвид Джагно