Интервью с разработчиками игры «Лествица»

Привет всем! В этой статье я задам несколько вопросов разработчикам «Лествицы». Они любезно согласились на них ответить. Пообщаться удалось сразу с двумя ключевыми участниками команды — арт-директором Валерием Гончаренко и техническим директором Никой Бурименко.

Разберемся, как устроен художественный и технический пайплайн «Лествицы», какое влияние на игру оказали Pillars of Eternity и Disco Elysium, как разработчики смогли получить такую необычную картинку и какие хитрости сокрыты под капотом.

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

Арт и визуальный стиль игры «Лествица»

Приветствую! Я Валерий Гончаренко, арт-директор проекта «Лествица». Я принимаю все решения, связанные с визуальным стилем проекта, помогаю художникам достигать новых высот, а также лично создаю концепт-арты и портреты ключевых персонажей, работаю со светом, цветокором и растительностью для каждой локации и много чего еще :)

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

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

Стоит отметить, «Лествицу» я не вёл как арт-директор с самого начала разработки, потому на момент моего появления в команде проекта у последнего уже был фундамент как технический, так и нарративный. Когда на собеседовании я услышал про сеттинг начала 2000-х годов, лето в маленьком северном городке и ориентир в техническом плане на 2,5D пайплайн Disco Elysium — решение о желании работать над «Лествицей» было принято почти моментально.

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

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

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

В итоге, основа визуального стиля окружения нашей игры стоит на двух столпах:

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

Картина Владимира Орловского “Полдень”.

Работы Джереми Манна.

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

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

Второй столп — ностальгический. Цветовые схемы времён суток, приглушенная желтоватая палитра, VHS-эстетика в UI — напрямую ссылаются на плёночную фотографию, эпоху недорогих «мыльниц» и компактных видеокамер с кассетами, так популярных в начале 2000-х годов. Аляповатые, вычурные формы «футуристичного» сглаженного дизайна бытовой техники, броские цвета разномастных дешёвых китайских безделушек, контрастирующие с фактурной, слегка побитой жизнью советской мебелью, потёртыми коврами и немного уставшим линолеумом — создают почти что капсулу времени, которую я с удовольствием передаю в руки каждому игроку.

“Московский двор 90-х”. Загружено arriva177.

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

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

Работы Антона Фролова.

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

Отдельно хочу поговорить о дизайне персонажей и портретов, не в последнюю очередь потому, что все они вышли из-под моего цифрового пера.

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

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

Пример концептов персонажей “Лествицы”.

С точки зрения стилизации форм и фигур персонажей мне хотелось высказаться заметно более приземлённо, чем это делают Disco Elysium, Zero Parades или Rue Valley, но некоторую долю стилизации, всё же, оставить. Основным референсом для стиля концептов персонажей стали работы Оливера Оддмарка из Remedy для Alan Wake и Control, Лейндекера, а также отдельные стилевые приёмы работы с живыми, экспрессивными линиями, позаимствованные у мастеров комиксной стилизации.

Работы Оливера Оддмарка для Alan Wake II и Control.

Чтобы оптимизировать временные затраты и оставить в своем графике время на огромный перечень остальных задач, отрисовка концептов и портретов мной сильно оптимизировалась:

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

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

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

Портреты персонажей “Лествицы”

А почему решили использовать именно 2.5D-подход? Это художественное решение или способ оптимизировать производство?

Учитывая, насколько технически сложно реализовать некоторые визуальные задумки в 2.5D пайплане и насколько тщательное требуется планирование при создании окружения, не прощающее ошибок — язык не поворачивается назвать выбор 2.5D пайплайна решением исключительно для оптимизации.

Я бы сказал, что тут честные 50 на 50. Мы определенно выигрываем с точки зрения оптимизации, поскольку проект подобного уровня визуального качества в честном современном 3D пайплайне обошелся бы точно прилично дороже, но и открываем перед собой невероятное количество возможностей для креативных, по-настоящему творческих решений и подходов.

3. Как устроен полный пайплайн создания одной локации: от референсов и концепта до готовой сцены в Unity? Какие программы используете и как распределяете работу между художниками?

Поверхностно, схема пайплайна разработки локации, с точки зрения команды Арта, выглядит так: Level Design Blockout-> Concept -> Environment 3D -> Final Render.

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

Теперь подробнее:

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

Следующим этапом идёт работа Level Designer’а, на котором тестируется комфорт перемещения игрока, расположение основных элементов, масштаб и прочие нюансы. Работа останавливается на этапе блокаута.

Далее, используя блокаут, концепт локации делает уже 2D Художник со специализацией на концепт-арте. Здесь окончательно фиксируется настроение локации, ее палитра, дизайн отдельных элементов, а также различные отсылки и мелочи.

Концепт-арт локации “Двор дома Алексея”.

Следующими в работу включаются 3D-художники по окружению, которые, используя концепт и блокаут локации, подробно воплощают её уже в трёхмерном пространстве. Стоит сразу отметить — в Blender, на работу с которым наши пайплайны сильно завязаны.

High-poly 3D модель локации “Двор дома Алексея”.

Сделаю ремарку: мне было важно, чтобы на каждом этапе создания локации каждый член команды не просто выполнял рутинную задачу, строго следуя наработкам из предыдущего этапа или моим указаниям, но и получал искреннее удовольствие от творческого процесса. Поэтому даже на этапе воплощения локации в 3D, который часто достаточно строго зажат в рамки ТЗ, концепта и требований, оставалось пространство для самовыражения, выстраивания интересных мини-композиций, старых-добрых «неидеальностей» в структурах и формах или небольших интересных деталей.

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

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

Готовые 3D модели локации не текстурировалась.

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

На выходе мы получаем набор карт, но среди этих карт нет Albedo, поскольку она полностью вручную, без использования AI (об этом позже), отрисовывается 2D-художниками. И здесь не обошлось без интересных решений и инструментов.

Одним из таких инструментов стал кастомный плагин для Blender, который позволяет частично разрешить одну из самых назойливых проблем 2,5D пайплайна с живописной Albedo — несоответствие Albedo и Depth Map. В Disco Elysium, чтобы художникам было проще отрисовывать многочисленные мелкие предметы на пререндеренной базе, использовались, как ориентиры, карты AO и т.н. clownpass, где каждый отдельный объект отбит отдельным цветом. Но кроме того, что работа с таким фундаментом всё равно скатывается в огромное количество ручного труда по выделению отдельных объектов с помощью Лассо, она еще и приводит к несовпадению Albedo, вручную отрисованной 2D-художниками, и Depth Map, отрендеренной в Blender. Результат такого несоответствия — целые массивы пикселей по краям объектов, которые можно увидеть, когда позади этих объектов оказывается честная 3D модель, например, главного героя.

Пример подхода с clownpass, от которого, впоследствии, отказались.

Моя команда со временем пришла к элегантному решению, которое я с удовольствием помог довести до полной интеграции в наш пайплайн. Этим решением стало использование связки рендеринга квадов Albedo в MultiLayerEXR в Blender и последующим импортом и доработкой их кастомными скриптами в Photoshop.

Еще одно отличие от Disco Elysium — над одной локацией у нас могли работать сразу несколько 2D-художников, поделив между собой зоны ответственности. Это позволяло, по нужде, кратно ускорить «выдачу» отдельной конкретной локации. Я потратил немало времени на то, чтобы 2D-художники работали практически как единый организм и могли синхронизировать между собой даже самые незначительные мазки кисти, не затрачивая при этом время на лишние согласования.

Готовая Albedo, отрисованная 2D Художниками.

Какую роль в производстве сыграли поездки по городам Русского Севера? Использовали ли фотографии, фотограмметрию или реальные архитектурные объекты для создания ассетов?

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

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

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

Рендеринг и технический пайплайн игры «Лествица»

Привет! Меня зовут Ника Бурименко. Я занимаю должность технического директора в студии «Хорошие игры» и веду разработку проекта «Лествица» с самого старта. Я принимаю решения по всем техническим аспектам разработки, и большая часть кода игры написана мной.

Расскажите, почему выбрали Unity? Какую версию и какой рендер-пайплайн используете — Built-in, URP или HDRP?

Начну с небольшой предыстории :)

В далёком 2015 году я играла в Pillars of Eternity (игра от Obsidian), и тогда меня по-настоящему поразила эта игра, в том числе и то, как в ней была реализована графика. Это были пререндеренные задники, что уже не совсем характерно для тех лет, когда все старались переходить на полноценное 3D. Но эти задники были сделаны на совершенно новом уровне: они реагировали на освещение в реальном времени и от этого выглядели очень натурально. И что немаловажно, игра спокойно работала на слабеньком нетбуке и выглядела потрясающе. Тогда это породило во мне огромное любопытство: как же это было сделано? Правда, в то время опыта разобраться с такой технологией мне ещё не хватало.

И вот мы «сегодня»: мне поступает предложение заняться проектом, который будет вдохновлён Disco Elysium. А ведь там тоже изометрия и, вероятно, тоже пререндеренные задники, а значит, я наконец-то смогу пощупать эту технологию. Когда я начала проводить исследование, всё подтвердилось. Оказалось, что разработчики из ZA/UM тоже смотрели на Pillars of Eternity и даже хотели связаться с Obsidian, чтобы те помогли с реализацией. Но что-то не сложилось, и ZA/UM пришлось разбираться с этим самостоятельно. Как, собственно, и нам :)

Поначалу были большие сомнения и страхи: а стоит ли вообще браться за такой пайплайн? Ведь я всё ещё не имела полного представления о том, как его реализовать. На тот момент казалось, что для этого потребуется написать целиком свой рендеринг с кастомным освещением и прочим. Но было ясно одно: стандартный реалистичный пайплайн не подойдёт (планка качества хорошего продукта окажется слишком дорогой), и нужно искать способы стилизации. Мы не исключали и стилизацию обычного 3D-пайплайна с применением фильтра Kuwahara (https://www.youtube.com/watch?v=LDhN-JK3U9g), процедурных штриховок (https://youtu.be/NrYGC4hyCVg) или старого доброго cell/toon shading.

В итоге мы совместно с ещё одним программистом всё-таки смогли сделать первый прототип, который реализовывал запечённые задники, и дорога в этом направлении начала открываться. Изначально разработка велась в Unity с использованием Built-in Render Pipeline, но я сразу же портировала её на URP. Это оказалось верным решением, потому что Unity уже совсем скоро прекращает поддержку Built-in и HDRP. Сейчас я чувствую, что мне не хватает даже имеющегося функционала URP, и в планах есть написать собственный SRP. Подробнее о том, зачем нужен свой SRP, расскажу дальше.

Сделаю небольшое отступление и расскажу, почему выбор пал именно на Unity. С одной стороны, всё просто: и Pillars of Eternity, и Disco Elysium сделаны на Unity, и это доказывает состоятельность и уместность этого движка для нашего проекта. Плюс у меня большой опыт работы с ним: и во времена мобильной разработки, и во время работы над «Pathfinder: Wrath of the Righteous» в Owlcat Games. Также я рассматривала вариант делать проект на Unreal, ведь опыт работы с ним у меня тоже есть («The Expanse: Osiris Reborn» от Owlcat). Но Unreal быстро отбросили. По моим представлениям, на нём не так просто добиться стилизованной и нетребовательной к железу картинки. А ведь мы тоже ставим перед собой задачу сделать так, чтобы игра могла комфортно работать на ноутбуке со встроенным графическим чипом. Другие движки я не рассматривала, поэтому выбор окончательно закрепился за Unity. На данный момент это Unity 6.3 LTS, и я с нетерпением жду возможности обновиться до 6.7 LTS.

Как технически реализован ваш 2.5D-рендеринг? Это полноценные трёхмерные уровни с изометрической камерой, пререндеренные фоны, спрайты в 3D-пространстве или гибридная система?

А сейчас время вернуться к нашему графическому пайплайну и окунуться в него с головой. Валерий уже рассказал, как устроен этот процесс с точки зрения производства, я лишь отмечу некоторые технические нюансы. В Blender 3D-художники на основе блокаута делают два представления локации: low-poly и high-poly. Low-poly возвращается в Unity в виде 3D-модели, заменяет исходный блокаут и служит основой для построения nav mesh, а также используется в качестве shadow caster для источников освещения в реальном времени. А high-poly используется для создания пререндеренного задника. Самая большая хитрость заключается в запекании карты глубины: делать это приходится не строго top-down, а в изометрической проекции, как и в самой игре. Но если в таком случае взять карту глубины как есть, то на горизонтальных стыках секторов возникнут резкие перепады. Чтобы это исправить, во время запекания карта глубины с помощью тригонометрии преобразуется в карту высот в проекции камеры. От Metallic/Roughness на данном этапе мы отказались, так как запечённых карт и так уже довольно много.

Когда все карты для всех секторов готовы, они импортируются в Unity и с помощью скрипта раскладываются по плоским квадам. Далее в дело вступает наш шейдер, который реконструирует 3D-сцену на основе информации, полученной из всех запечённых карт. Тут и происходит вся магия: в шейдере мы применяем семантику SV_Depth. Таким образом, мы можем задать плоскому кваду настоящую глубину, и сортировка объектов будет работать из коробки для каждого пикселя. А добавив в эту формулу карту нормалей, мы получаем полноценное освещение в реальном времени и тени! Есть у этого подхода и свои ограничения: такая сцена может только принимать тени от других объектов, но не может отбрасывать собственные (кроме запечённых), потому что информации о перекрытых объектах не хватает. Но тут на помощь приходит low-poly 3D-сцена, о которой мы упоминали ранее. Ещё одно ограничение (опять же, из-за того, что информация о перекрытых участках не сохраняется): мы не можем, например, скрыть стены или сделать их полупрозрачными, если персонаж оказался позади них. Ну и, естественно, такой подход работает только с ортографической камерой. А ортографическая камера — это, на самом деле, тоже вызов с точки зрения визуального восприятия глубины и пропорций.

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

Стоит ещё отдельно отметить работу с освещением: здесь мы пошли заметно дальше, чем Disco Elysium. У нас тоже есть смена дня и ночи, реализованная через запечённые карты освещения, которые проходят цветокоррекцию для создания нужного настроения. Но вдобавок у нас есть карта непрямого освещения, которая передаёт отражённый свет, и даже тёмные переулки выглядят по-разному в разное время суток. Особенно это актуально для интерьерных локаций, которые у нас, в отличие от Disco Elysium, проходят полный цикл смены дня и ночи. Но на этом мы не останавливаемся. Ещё одна наша находка — это рассеянные тени, реализованные на основе технологии капсульных теней. Когда мы семплируем тень, то проверяем, находится ли этот пиксель глобально на свету или в тени. В первом случае семплируется стандартная тень от солнца, а во втором берётся капсульная тень от ближайшего источника рассеянного света, например окна.

Какие именно текстуры и карты материалов используются в кадре? Есть ли normal, roughness/smoothness, metallic, AO, depth? Как организованы материалы и используются ли собственные шейдеры?

Частичный ответ содержится выше, в техническом объяснении Ники к вопросу 6: карты глубины и нормалей, отказ от Metallic/Roughness на текущем этапе, восстановление геометрии шейдером. Отдельного разбора AO, smoothness и полного перечня карт в присланных материалах нет.

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

Но не одним лишь 2D живёт наша игра. Практически любой анимированный объект — будь то персонаж, дверь, дерево или VFX — это 3D-объект. Как мы уже поняли, сортировка 2D- и 3D-объектов для нас не проблема, но важно, чтобы 3D-объекты хорошо вписывались в окружение и одновременно визуально считывались, а не терялись на его фоне. Для этого используется ещё один кастомный шейдер, который делает границу светотени более выраженной и добавляет по контуру эффект, похожий на френель.

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

Только что я написала «стандартная тень от солнца», хотя это не та же самая тень, которую предоставляет рендер Unity. Мне очень хотелось избавить игру от «привкуса Unity» — то, что ещё называют Unity-feel. И главный кандидат здесь — это система каскадных теней от солнца. Я не большой специалист в графике, и, возможно, для профи это было бы очевидно, но для меня стало открытием, что обычные каскадные тени не очень-то подходят для изометрических игр. Изначально каскадные тени дают наилучшее качество вблизи камеры, а она находится высоко в небе, из-за чего весь смысл теряется. Чтобы обойти это ограничение, нам пришлось написать собственный пасс для рендеринга теней. Вот только URP не даёт заменить пасс теней на кастомный, что очень обидно. И это как раз тот самый повод перейти на полностью свой SRP. А пока что каскады Unity и наш пасс работают в паре, что, конечно, не оптимально с точки зрения производительности, но в будущем это будет исправлено.

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

Говоря об оптимизации, мы не так много в неё вкладывались, потому что сам пайплайн подразумевал быстродействие по умолчанию. И это подтвердилось тестами: игра вполне сносно работает даже на достаточно слабых ноутбуках со встроенным видеочипом Intel. Поэтому силы были брошены на то, чтобы лучше отполировать другие аспекты игры. Но в будущем слабые компьютеры ещё ждёт прибавка FPS :) Виртуализацию текстур мы пока тоже обошли стороной. Такая фича появилась в Unity, но она всё ещё экспериментальная. При этом локации у нас загружаются с такой же скоростью, как и в Disco Elysium, где виртуализация используется.

Нарративный дизайн и инструменты

Какие инструменты используются для создания ветвящихся диалогов и квестов? Рассматривали ли Articy:draft, Ink, Yarn Spinner или другие специализированные решения? Почему остановились на выбранном инструменте?

Для создания нарратива в игре мы используем программу Articy:Draft. Я провела исследование и выяснила, что Disco Elysium и практически каждая Disco-like-игра используют этот инструмент, и он действительно очень хорош для своих целей! Возможности кастомизации и добавления собственных сущностей в диалоги настолько широки, что ни разу не возникает ощущения связанных рук. Функционал позволяет внедрять в диалоги с помощью специальных нод и проверки навыков, и отслеживание квестов, и работу с инвентарём, и даже разметку анимаций и мизансцен прямо по ходу диалога. Мы добились того, что практически каждой системой игры можно управлять из диалога. В Articy есть и система глобальных переменных, с помощью которой можно управлять развилками в диалогах, а также использовать её для ивентов внутри игры, таким образом меняя состояние не только диалогов, но и игрового мира. Эти глобальные переменные могут легко стать частью системы сохранений в игре. Но есть и ложка дёгтя: производительность этой программы оставляет желать лучшего. Даже на очень мощном компьютере навигация по диалогам может сопровождаться долгими и непрекращающимися фризами. Из-за этого я планирую при первой же возможности заменить Articy на внутренний инструмент, который мы сделаем быстрым :)

Тестирование

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

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

Использование ИИ

Насколько широко применялся генеративный ИИ при разработке «Лествицы»? Для каких конкретно задач — концепты, текстуры, анимация, код, сценарий, озвучка?

Валерий Гончаренко:

Я занимаю достаточно открытую позицию по отношению к искусственному интеллекту, но спойлер: в визуале «Лествицы» применения ему в том виде, в котором кто-то может его ожидать, не нашлось. И этому есть вполне конкретные причины. Более того, я почти все их уже упомянул.

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

Одно из самых больших разочарований в работе с генеративными моделями — они так работать (в данный момент времени) просто не умеют. Никакие. Точка.

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

На текущий момент для AI в графике видеоигр я вижу место в достаточно понятных, четко-сформулированных, механически исполненных направлениях. Одно из таких — casual и hyper casual в мобильных играх. Это понятные системы с четкими, воспроизводимыми правилами, часто очень строгими рамками не просто общей стилизации форм, но даже соотношений их размеров внутри фигуры и точного расположения/цвета таких мелочей, как рефлексов и бликов. Для генеративной модели это буквально праздник живота и, на мой взгляд, с такими задачами она справляется наиболее эффективно. Но даже здесь, в такой понятной системе, всё равно нет-нет, а требуется рука художника, который тут и там подправит косячки, там и здесь добавит живости. И чем сложнее становится система, чем менее закрытыми становятся её рамки, чем больше она полагается на эмоции и чувство прекрасного — тем чаще происходит это «нет-нет» и тем ниже становится ценность результата со стороны генеративной модели и тем неэффективнее она себя показывает.

При создании «Лествицы» генеративные модели использовались, но использовались они для генерации удобных референсов для отрисовки складок ткани, для быстрой проверки шальных визуальных гипотез, а также, например, для помощи в создании дополнительных референсных изображений при текстурировании 3D моделей персонажей на основе концептов. Эксперименты с обучением собственных LorA проводились, но применения они так и не нашли.

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

Ника Бурименко:

Когда речь заходит об LLM, я занимаю достаточно консервативную позицию, даже когда речь идёт о написании кода, который якобы никто не видит и поэтому неважно, какой он. Спойлер: на самом деле важно, и сейчас я об этом поговорю. В нашем проекте доля кода, написанного LLM, исчезающе мала. На то есть две основные причины. Во-первых, я всё ещё считаю, что код нейронок не дотягивает до той планки качества, которую я устанавливаю для проекта. Добиться от них именно того, что нужно мне, оказывается дольше, чем написать этот код самой. Во-вторых, и это гораздо важнее, залог продуктивной работы программиста — хороший дизайн кодовой базы, с которым нейронки откровенно плохо справляются. Можно сказать, что дизайн в данном случае — это архитектура проекта, но мне бы хотелось уйти от термина «архитектура», потому что он несёт слишком много стереотипных и шаблонных смыслов. Я хочу сказать о том, что код должен полностью подчиняться конкретному замыслу, то есть быть глобально осмысленным. И только так он становится понятным, лаконичным, практичным и, можно даже сказать, красивым — это и есть признаки хорошего дизайна. Можно услышать мнение, что сейчас программисты должны думать об архитектуре, продумывать её, осмыслять, а непосредственное написание кода уже отдавать на откуп нейронкам. Честно сказать, я вообще не представляю, как это в принципе достижимо, если самые лучшие озарения по поводу архитектуры случаются только тогда, когда ты часами бьёшься над своим или чужим кодом и через страдания находишь решение. Как говорится: «No pain, no gain». Здесь ещё можно было бы сказать много философских и практических вещей, но, кажется, это тема для отдельного разговора :)

Огромное спасибо Валерию и Нике за такие подробные ответы, интересные технические детали и возможность заглянуть во внутреннюю кухню проекта. Будем с интересом следить за развитием игры и с нетерпением ждать полного релиза!