Как создавали процедурную разрушаемость в Control

На GDC Summer 2020 Йоханнес Рихтер, старший художник по VFX в Remedy, рассказал о том, как студия работала над разрушаемым окружением в Control. Мы выбрали из выступления главные тезисы.

Выступление пересказал: Артемий Леонов

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

Для того, чтобы воплотить такую концепцию в жизнь, была необходима реалистичная физика объектов — но разработчиков сдерживали технические ограничения платформ, на которых должна была выходить Control, и небольшой размер команды. В итоге окружение должно доносить до игрока примерно такую мысль: «Развлекайся, уходи в отрыв, устраивай полный хаос на своём пути… но в рамках разумного, пожалуйста, иначе игра не справится».

При работе над эффектами Рихтер придерживался принципа «гранулярности»: все детали, которые образуются в процессе «разрушения», — отдельные объекты, их части, обломки и мелкие частицы, — должны были быть отражены визуально. По такому же принципу создают эффекты для кино: если какому-то из этих элементов не уделить достаточно внимания, правдоподобная картинка не сложится.

Элементы разделили на три накладывающихся друг на друга уровня. Первый реализован при помощи Rigid Body Simulations: это целые объекты и детали окружения, а также их отдельные части. Второй уровень (Mesh particles, material decals) — это мелкие обломки и осколки. Третий (Particle Sprites, Mesh particles) — искры, дым, мелкие частицы материалов.

Рабочий процесс выглядел так:

• Художник по окружению задаёт геометрию уровня, создаёт конкретные пропсы и модули.
• Специалисты по VFX занимаются ригами и анимацией.
• Всё это имплементируется в Northlight — собственном движке Remedy.

Разрушаемость решили сделать «процедурной»: иными словами, игра должна была сама обрабатывать и интерпретировать поступающую информацию об игровом мире на основе заданного набора правил.

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

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

Помимо стандартных Rigid Body объектов, в Control используются так называемые «куски» (chunks) — несколько небольших объектов, соединённых «связями» (bonds). У них общий коллайдер, и они ведут себя как один большой объект — до тех пор, пока не распадутся на части. Месторасположение соединений (joints), — то есть точки, по которым объект распадается, — также создаются процедурно.

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

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

— На экране одновременно могут присутствовать не более 200 активных Rigid Body. Объекты вне поля зрения игрока исчезают и не обрабатывается.

— Когда происходят «крупные события», в которых задействовано очень много объектов — например, взрыв, — коллизия задерживается на 10 кадров, чтобы дать системе время.

— Объекты очень быстро «засыпают» после того, как были приведены в движение. По словам Рихтера, это вполне реалистично. Если объект — не шарик-попрыгунчик, который уронили на пол, то он вряд ли будет долго двигаться после падения.

— Также разработчики активно использовали частицы (particles), — в том числе чтобы маскировать несовершенства системы. Они появляются в результате выстрела, при разрыве соединения между «кусками» и в случае полного разрушения объекта: они не просто исчезают, а превращаются в «пыль».

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

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

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

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