Создание графики в мобильной RPG Age of Magic

Опыт разработчиков из студии Playkot.

24 мая на iOS вышла RPG Age Of Magic о сражениях героев в умирающем фэнтезийном мире. Разработчики игры из компании Playkot написали для DTF колонку, в которой рассказали о том, как создавалась графика и анимация.

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

Как и в любом проекте, работа над локациями, моделями, персонажами и эффектами начинается с текстового описания концепта, референсов и скетча.

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

Отдельную боль вызывает «ровность» земли. У каждого персонажа чётко заданное место на арене и 90% времени персонаж его не покидает. Много внимания мы уделяем тому, чтобы именно на своих заданных местах персонажи не проваливались и не летали. К этим позициям также привязываются эффекты, и тут порой случаются неприятности.

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

Для минимизации количества технических багов во время работы для всего арта существует суперполезный документ под названием Art Bible. Он содержит в себе требования ко всей графике: силуэты персонажей, общий вид элементов, топология 3D-моделей, текстуры и многое другое.

Процесс создания 3D-ассетов персонажей и арен состоит из нескольких этапов.

Концепт-арт от художников, описание от геймдизайнера. Всех персонажей и арены мы придумываем и рисуем исключительно внутри офиса, на стадии 2D-скетчей, не отдавая на аутсорс. Идеи для героев рождаются внутри команды. А некоторые персонажи имеют реальные прототипы внутри компании.

3D-скетч, сделанный в Zbrush, Maya или Max. Обычно мы делаем его для персонажей, которых отдаём на аутсорс. Такой подход помогает сократить количество правок, а особенно полезен для арен, так как позволяет сразу настроить положение геометрии под игровую камеру и подобрать общую композицию.

Финальный скульпт в Zbrush. Здесь мы смотрим на попадание в образ 2D-скетча, а именно: форму, пластику, проработку.

LowPoly. изначально мы ориентировались на 5 тысяч tris (±тысяча) на персонажа (целевым устройством был iPhone 5S), но сейчас мы повышаем лимит до 7 тысяч.

Запечённый заранее Vertex Occlusion учитывается шейдером и улучшает финальную картинку.

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

Запекание, текстуринг. Эта часть сильно изменились с момента запуска проекта. Изначально мы «пекли» в XNormal, а текстуринг был сделан в Zbrush (Polypaint), Photoshop, Bodypaint или 3DCoat. Основным требованием было попадание в стиль, и мы не ограничивали художников в инструментарии.

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

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

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

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

Каждая сцена освещена четырьмя источниками света.

Для KeyLight рендерится две карты теней. Первая, со статичными объектами, рендерится один раз при старте арены, а вторая, включающая в себя движущиеся объекты (персонажей), рендерится каждый кадр перед основным проходом.

Шейдинг. Большинство материалов в игре использует один из двух универсальных шейдеров: шейдер для персонажей и более простой шейдер для арен. Каждый шейдер содержит несколько вариантов для устройств разной производительности.

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

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

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

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

Разумеется, только двумя шейдерами (для персонажей и арен) дело не обходится. Например, во всех приведённых ниже аренах используются уникальные шейдеры.

Мы активно работаем над уменьшением размера билда. Для этой цели созданы скрипты, которые проходят по всем материалам и объединяют текстуры по каналам. Так Specular Map и Emission будут упакованы в альфа-каналы NormalMap и ColorMap.

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

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

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

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

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

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

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

К примеру, Арехонский Жрец своей способностью «Плач Пустоты» высасывает энергию у всех противников на поле боя. Чтобы показать, как лучи энергии от каждого врага тянутся к Жрецу, необходимо было запустить снаряды с трейлами в обратном порядке. Для этого использовалась механика луча, в котором цель и источник поменялись местами, а внутри луча уже летел снаряд от цели к источнику, оставляя за собой след.

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

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

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

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

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

В результате из 3D-редактора были взяты два меша вороны: с опущенными крыльями и с поднятыми. Вектор смещения для каждой вершины из одного кадра в другой был записан как цвет для этой вершины.

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

Другое применение эффекта — можно надуть персонажа и взорвать его. Такой изощренный способ смерти был реализован у Библиотекаря.

Некоторые локации поставили ещё одну интересную задачу: показать глубину и толщину воды и льда. Лёд — это непростой для рендеринга материал, он полупрозрачный, имеет объём и неоднородную внутреннюю структуру (трещины).

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

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

Всё начиналось с кастомных ригов. То есть с ригов, которые собирались полностью руками. С нуля. Да, возможно работало не совсем так, как надо, но зато мы пришли к пониманию того, каких моментов стоит придерживаться, где можно сократить количество костей, а где, наоборот, добавить. В данный момент, большая часть ригов персонажей основана на авториге advanced skeleton. Многие его недолюбливают — и напрасно. В основном ругают за то, что он тяжелый, много лишнего, но на самом деле, всё ненужное можно отключить при сборке рига.

Хотелось бы сказать о его плюсах:

Если вам доводилось работать с мобильными играми, то вы наверняка сталкивались с ограничением в 50 (иногда 48) костей на персонажа. Это требование, конечно, справедливо, если у вас на экране находится действительно много персонажей, но у нас их не более 11, а значит им можно и пренебречь И всё же, надо держать в голове, что «чем меньше, тем лучше». В среднем у нас 50-60 костей на персонажа, только если это не эпичный босс с кучей деталей. В таких случаях их количество может перевалить за сотню.

Все персонажи экспортируются в Unity с одинаковой (насколько это возможно) иерархией и неймингом костей.

Сам же пайплайн анимации не отличается от большинства проектов.

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

В отличии от игр от третьего лица или платформеров, где персонаж постоянно бежит или ходит, в Age of Magic главное внимание следует уделить idle-анимации персонажа, так как в этом состоянии мы его видим большую часть времени. Через анимацию мы стараемся передать характер персонажа, который нам описали. Здесь опираемся на текст и на силуэты и позы, которые пришли от художников.

Есть ещё одна очень важная для каждого из героев анимация — анимация смерти. В неё также можно внести частичку характера, и, кстати, у неё не очень жёсткие ограничения по продолжительности, а значит можно разгуляться по полной.

Все собранные анимационные файлы собираются в префаб персонажа с довольно простым контроллером.

Уникальной составляющей нашей игры являются катсцены между актами.

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

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

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

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

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