Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 32)
У большинства может возникнуть впечатление, что коллизии – нечто, присущее в первую очередь трехмерным играм. Но все то же самое актуально и в 2D. Давайте посмотрим на примерах.
Допустим, вы играете в свой любимый
Когда же дело касается 2D, все в целом имеет схожую логику. Иной может быть лишь реализация. Сравнение зоны вокруг объектов в тех же платформерах может сводиться к сравнению пересечения прямоугольника с окружающей локацией. Это как зона кликабельности вокруг кнопки: мы ее не видим, но она есть. Такую зону иногда называют коллайдером. С физическими ускорителями у них общее только одно: и там, и там происходят столкновения.
Другой пример – это коллизии элементарных частиц, математических точек. Такое можно представить себе, посмотрев на шарики, которые летят в популярных бабл-брейкерах, арканоиды или расчеты попадания патрона в противника.
Для регистрации таких попаданий в игровую сущность добавляют так называемые ХИТБОКСЫ. В большинстве игр это просто невидимая коробка, грубо покрывающая модель снаружи и регистрирующая столкновение с другими игровыми сущностями. Это важно, потому что, например, стрелять, учитывая реальную геометрию, очень затратно.
Классическое дизайнерское решение: есть мускулистый воин и миниатюрная эльфийка. Очевидно, что попасть выстрелом в более крупный объект легче. В старых играх можно найти примеры, когда из-за разницы в хитбоксах имело смысл всегда играть за самого маленького персонажа. Если персонажи больше ничем не отличаются, чтобы эльфийка не имела геймплейных преимуществ, часто им делают одинаковые хитбоксы. Например, в шутере
Следующая непростая задача – реализация удара по объекту. Вы наверняка замечали, что во многих MMO, когда персонаж бьет мечом по своему сопернику, он даже не попадает по модели: просто машет оружием, а с противника списывается XP. Дело в том, что адекватно показать удар холодного оружия по телу непросто. В жизни довольно странно представить себе ситуацию, что ты про-ткнул кого-то мечом, а он остался стоять, как стоял. Поэтому многие дизайнеры скрывают такое соприкосновение за столпом искр, чтобы не было заметно, что оружие не касается персонажа. Для огнестрельного оружия такой ширмой часто служит эффект разлетающихся брызг крови.
RAGDOLL – процедурный вид анимации в рамках физики, заданной в игровом движке, или же законов эволюции, которые написал программист, – при этом художник не задает параметров движения. Персонаж ведет себя как тряпичная кукла, которую уронили (отсюда и название). Теперь каждая кость и сустав отдельно подчиняются только физике. Представьте себе, что в персонажа выстрелили из оружия или он подорвался на мине. Пока у него есть XP и он жив, заданная анимация определяет, что будет происходить с его телом в этот момент. После смерти же он превращается просто в еще один физический объект, который может красиво отлететь в сторону или эпично врезаться в стену.
Есть программы для анимации одежды, волос, пролитой жидкости, ведь сделать ее для всех вариантов движения невозможно. Например, плащ не может просто висеть, его движение как минимум напрямую зависит от движений персонажа. Но даже такие готовые решения необходимо соединять со своими моделями, что уже требует определенной квалификации. Поэтому начинающие разработчики нередко предпочитают делать, например, пиксельную графику, чтобы не связываться со сложностями физики взаимодействия, рэгдоллами и прочими сложными сущностями. Тем не менее опытный художник в состоянии справиться со всеми этими задачами даже в одиночку.
ПОСТПРОЦЕСС, ИЛИ ПОСТОБРАБОТКА, – это метод обработки изображения, когда на уже готовую картинку с моделями накладывают определенные эффекты. Их очень много, и применяют их для разных целей: например, мы хотим, чтобы готовые модели были стилизованы под рисунок от руки; если игрок едет на танке, можно создать ощущение, что он смотрит сквозь танковую оптику – с потертостями, определенным искажением картинки и так далее. Если игрока пугает монстр и экран в это время дрожит, это тоже постобработка, добавленная для атмосферы страха и напряжения. Или при тяжелом ранении экран игрока окрашивается красным, символизируя, что персонаж на грани смерти. Обычно наложение таких эффектов – задача технического художника, то есть специалиста, который является связующим звеном между 3D-художниками и программистами. Такой человек способен реализовать художественное видение в рамках технических возможностей движка.
ОСВЕЩЕНИЕ – одна из самых глобальных задач для настройки. Мы задаем источники света, а материалы моделей уже определяют, как падают тени, отражается свет и пр. Для большинства игр тени задаются процедурно, вручную никто не прорисовывает бесконечное количество вариантов. Освещение – очень ресурсозатратный процесс, особенно для маленьких объектов. Поэтому во многих играх тени можно отключать в настройках графики, чтобы иметь возможность играть на менее мощных компьютерах. В этом случае свет просто заменяется на проектор.
Иногда левел-дизайнеры точно знают, что некоторые предметы (деревья, памятники и т. д.) не будут двигаться. Тогда их обозначают как статические и просчитывают, как падает свет, только один раз.
Но свет может быть динамическим, а не статичным, и в этом случае нельзя просто зафиксировать тени за предметами. Если объект двигается или разрушается, значит, надо суметь просчитать эти изменения в динамике, и это одна из самых тяжелых для сцены задач. Добавить в сцену десять монстров может быть намного проще, чем одну дополнительную лампочку. Оценить стоимость объектов в кадре с точки зрения производительности вам могут помочь различные гайды на эту тему, а также профилирование: в движке игры вы можете получить информацию, сколько в процентном соотношении стоит в данном кадре рендеринг моделей или освещения или расчет игровой физики.
Для мультяшной анимации не так критично, если тени падают как-то не так, а вот фотореалистичный объект с «кривыми» тенями сразу добавит вам комментариев про «игру из девяностых».
Нельзя не упомянуть об ИГРОВЫХ ВИДЕОРОЛИКАХ. В большинстве игр есть хотя бы начальная катсцена. Созданием таких роликов обычно занимаются отдельные специалисты.
Как правило, маленькие студии выбирают постановочные ролики, основанные на готовых решениях, предлагаемых игровым движком. Очень немногие студии делают качественные CGI-ролики[74] самостоятельно, так как это очень трудоемкий и дорогой процесс. CGI-ролики генерируются не в реальном времени, поэтому можно выделить куда больше ресурсов на обработку каждого кадра, и картинка получается по качеству выше, чем при реалтайм-рендеринге в игровом движке. Для них требуются отдельные модели и ассеты, а стоят такие ролики сотни тысяч долларов.
Ролики, созданные с помощью движка, или CGI-ролики, у более богатых товарищей могут быть использованы для продвижения, например, в сторах. Для клиентских игр стало стандартом делать красивые тизеры и трейлеры, так как людям скучно смотреть только скриншоты, видео вызывает куда больше эмоций и интереса. Для их создания покадрово составляется сценарий ролика. Важно при этом не забыть подогнать происходящее на экране под тайминг озвучки.
Отдельная большая тема – это работа над созданием арта посредством АУТСОРСА. Внештатным сотрудникам труднее отследить изменения в проекте, поэтому важно быть особо внимательным при составлении ТЗ. Хорошим правилом все же считается хотя бы один раз сделать арт своими силами и только потом отдавать на аутсорс, уже имея примеры, образцы и четкое понимание того, как создается качественная графика, сколько времени это занимает, и прочих нюансов.
В штате может вообще не быть художников, но вам все равно необходим опытный человек, знающий, что такое хороший арт-стиль, как построить процесс работы, и разбирающийся в технической стороне создания графики. В идеале он должен еще и уметь работать с гейм-дизайнерами: правильно понимать их идеи, при этом отстаивая при необходимости свое видение, что подойдет проекту, а что нет. В противном случае возникает распространенная ситуация, когда хороший художник просто не знает технической стороны вопроса; тогда предпочтительнее, чтобы человек, лучше всех разбирающийся в движке, взял на себя обязанность интегрировать получившийся арт в игру (в идеале это отдельный человек – технический художник).