Катсцены и синематики в ААА-играх

С вами на связи как и раньше, я, гейм/синематик дизайнер, прошедший несколько крупных ААА проектов, в том числе ваш любимый Cyberpunk 2077

Сегодня поговорим про обещанную тему: катсцены и синематики в АА+ играх.

Геймдев - это процесс на 99% состоящий из решения и создания проблем, и на 1% состоящий из творческого безудержного креатива. Поэтому, большая часть поста будет про проблемы разработки. Я пишу пост для широкой аудитории, поэтому постараюсь писать как можно проще. Итак:

Катсценой (cutscene), обычно называется игровая сцена которая 1) сделана на движке игры (в особенности это касается real-time рендера) и 2) "врезается" в геймплей (а значит, разработка катсцены требует от синематик-дизайнера непосредственного взаимодействия с геймплеем игры, тригеррами и пр.) То есть, если вкратце - это сцена, использующая ассеты и realtime рендер игры.

Синематиком (cinematic) обычно называется видео, которое сделано на движке игры, но отрендерено и закодировано в видео-контейнер, или сделано по рендер-пайплайну в стороннем софте, смонтированно и озвучено. То есть, вкратце - это сцена использующая разные технологии, невозможные для реализации в реальном времени.
Есть еще разные подвиды и тех и других, или игры, в которых все нарративные сцены - это кат сцены, но камерой является сам игрок.

Основной инструментарий синематик дизайнера катсцен, это:

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

Так же, катсцены как правило, используют анимацию, и озвучку, воспроизводимую в реальном времени (с привязкой к fps).

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

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

Почему смена ракурсов критична для производительности? Все дело в том, что в движках используется стриминг геометрии, освещения и текстур. Вы наверняка могли заметить значительные просадки fps при повороте камеры например на город, и резкое повышение fps при взгляде куда-нибудь на пустое пространство. Во время стриминга геометрия и текстуры выгружаются из памяти, и если при повороте камеры скачок fps может быть не так заметен, то при смене камеры - LODы статичных мешей будут быстро подгружаться в память, спрайты превращаться в 3D модели, сжатые текстуры заменяться на high-resolution, а анимации будут скакать из-за перехода от режима компрессии (скажем 8 кадров в секунду ) к режиму realtime.

Допустим, у вас есть секвенция из двух кадров, в котором первый (А) - это вид сверху на едущую машину, а второй (Б) - кадр в салоне автомобиля.

Разница в ракурсах огромная - если в первом кадре это условный мост, и условная машина на нем, то в следующем карте нужно подгрузить уже целый город, и детальную модель персонажей в машине. Самый казалось бы простой способ избежать прогрузки стриминга - это сделать так, чтобы движок учитывал ракурс кадра А и кадра Б, и подгружал стриминг кадра (Б) уже на кадре "А". Но это будет значить то, что во время кат-сцены, у вас будет двойная нагрузка ресурсов, по сравнению с геймплеем. Поэтому второй способ, к которому приходят все студии в мире - это уменьшение "бюджета" геометрии и текстур в самих шотах катсцен.

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

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

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

Работая над Phantom Liberty, например во время установки засады на Max-Tac, мне приходилось учитывать больше шести возможных вариантов старта сцены игроком. Ведь он мог зайти в сцену с разных дверей, забраться по строительным лесам, запрыгнуть через... нелинейность, мать её.

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

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

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

Обычный инструмент ААА синематик-дизайнера, это в 90% случаев - те же блюпринты (visual scripting), как и у геймплей дизайнеров. Только фокус в меньшей степени на переменные и логику, а инструментарий использует разные инегрированные тулкиты - например, редактор диалогов, а так же анимации.

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

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

И это совершенно нормально - небольшие побочные openworld квесты удесятеряли бы бюджет игры, если бы на них выделяли все те же ресурсы, как и на 'golden path'.

Неплохой пример одной из таких сцен - побочное задание (gig) с Эль-Капитаном. Работая над этой цепочкой квестов, я использовал в основном, базовые анимации и немного анимаций, играющихся на разные части тела отдельно.

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

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

Гораздо хуже, если кат-сцена интегрирована с комбат-сценой или выходами из нее (когда нужно придумать что делать с горой трупов в кадре).

Катсцена должна учитывать:

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

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

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

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

С диалоговыми сценами всё еще сложнее - lipsync требует разного времени для каждого из N языков локализации. А значит, четырехсекундный шот на английском, превращается в 9 секунд на русском, и в 8 секунд например, на японском.

А ту самую злосчастную дверь, персонаж открывает всего десять секунд. Значит все персонажи в сцене три секунды неистово айдлят в Т-позе? Не подходит, давайте это чинить.

Казалось бы, анимация не требует больших ресурсов, но что такое CG-скелетная анимация? Это сотни т.н "ключей", описывающих положение, поворот и размер десятков костей скелета в пространстве каждый кадр.

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

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

Самый простой - это тело с ногами + руки. Почему отдельно руки, потому что "естественная", комфортная камера для игрока обычно располагается где-то в грудной клетке модели.

Ноги персонажа, часто используют систему IK (инверсная кинематика, сгибающая конечность например при наступании на ступеньку лестницы)

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

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

В случае с "говорящими" персонажами, лицо - это отдельная система, играющая свои анимации, синхронизирующаяся с речью (lipsync), а глаза имеют еще и свою, отдельную надстройку систем.

Разница motion и performance capture очень заметна там, где лицо актера накладывается на лицо игрового персонажа, часто отличающееся по физиологическим характеристикам. Поэтому в более дорогих проектах используют performance capture, где в роли актера мокапа играет актер, с лица которого методом сканирования создана 3D модель персонажа игры.

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

Как вы помните, синематики - это те сцены, которые делаются по pre-render пайплайну, иногда на стороннем софте, или ресурсами вообще другой студии.

Такой пайплайн, обычно гораздо ближе к Full-CG пайплайну, ведь сложность синематика никак не влияет на быстройдействие.

Часто, кстати, синематики заменяют канонические Fallout/TES экраны загрузки, а под капотом в это время идет компиляция или загрузка уровня и других данных.

Обычный инструментарий синематик артиста, работающего именно с синематиками, или трейлерами, отличается от катсцен-дизайнера, и включает в себя следующие инструменты:

В целом, как я и говорил, инструментарий синематик-дизайнера с большей мере похож на CGI и пост-продакшн, и в меньшей на работу программиста / геймдизайнера.

Над каждой сценой в ААА+ проектах работает большая команда. Главные ограничения - это:

Процесс производства синематиков и катсцен

Любое производство в геймдеве - процесс очень итеративный (финальный продукт проходит десятки итераций и изменения вносятся каждый день)

От пре-продакшна до финального полишинга продукта.

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

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

На этом всё, я планирую на днях выпустить Q&A пост, с ответами на вопросы, так как мне показалось это будет слишком много для одного поста.

Я какое-то время в отпуске, так что у меня будет время ответить на большинство вопросов, но врядли на все. Самые лучшие вопросы из прошлого поста и из комментариев к этому посту я включу в следующий пост с Q&A
Оскорбляющие личность автора комментарии, особенно мат - будут удаляться, а авторы попадают в чс.
Я не собираю донаты и в целом не получаю никакой выгоды от размещения постов на DTF, кроме интересного общения, поэтому я пишу так, как мне удобно и когда удобно.