Мобильный шутер Guns of Boom: оптимизация графики

Советы от арт-директора московской студии Game Insight.

Арт-директор московского отделения Game Insight Дмитрий Гладилин рассказал на DevGAMM 2017 о графических решениях мобильного шутера Guns of Boom.

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

Приятная стилизованная графика, кастомизация, куча оружия. Персонажи, отличные карты, чумовое PvP. Но что скрывается за описаниями и скриншотами в сторе?

Движок — Unity, около 80 вызовов отрисовки (draw calls), в пике до 250 тысяч вершин в кадре (vertex count). Размер карт — 50 на 50 метров (это, кстати, вынужденная мера). До восьми игроков в бою. Используем 250 мегабайт памяти — почти предел для слабых девайсов.

В начале разработки подобного проекта возникает множество вопросов. Приходят художники: сколько полигонов, сколько вершин должно быть у персонажа? Сколько полигонов в кадре? А какого размера текстуры мы можем использовать? Чтобы перечислить все детали, обсуждающиеся до начала разработки — никакого доклада не хватит. И ответы на них нужно получить, дабы потом ничего не переделывать.

В общем-то все они сводятся к техническим требованиям к графике проекта. В нашем понимании процесс поиска этих требований цикличен. Перед нашей командой стояли точно такие же вопросы — несмотря на то, что до этого шла разработка Guns of Boom под ПК, нам это вообще никак не помогло.

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

Дизайн-документ — основа бытия, основа разработки. В нём должны содержаться ответы на все вопросы, причём не качественные, а количественные. Недостаточно просто написать в дизайн-документе «у нас будут настраиваемые персонажи». Нужно совместно с командой, вашими геймдизайнерами, программистами, художниками, описать и продумать, из скольки слотов будет состоять персонаж. Сколько шмоток или пушек вы планируете сделать. Потому что дальше вам придётся точно понять, сколько и чего «вешать в граммах».

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

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

На этом этапе самое важное — выбор минимального девайса (смартфона, планшета, а лучше и того и другого). Сделать его можно на основе статистики. Вы смотрите в отчёты, лезете в какие-то статьи, возможно, используете какие-то данные, которые вы получили на своих предыдущих проектах. Какой девайс самый старый? Самый хилый?

В нашем случае это был Samsung Galaxy S III. Мы пошли в отдел тестирования и начали смотреть разные девайсы, оказалось, что в этот примерно «влезает» наше будущее приложение. Мы проверили статистику — он довольно старенький, но распространён, на нём играют.

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

Важно экспериментировать с разными комбинациями параметров. Образно, тысяча или 10 тысяч вершин, выведенные за один draw call — это не то же самое, что за 100 draw calls.

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

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

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

Обычно он выдаёт 0 FPS. Всё тормозит, лагает, ничего не работает. Вы применяете кучу идей, разные технологии оптимизации, но всё равно не получается. Ищите «узкие» места. На каком-то моменте в нашем проекте была проблема — мы прямо упёрлись в draw call, и ничего не работало.

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

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

А возможно вы увидите, что всё отлично запускается — и графика даже не очень сильно «ужимается» для устройства: значит, вы на верном пути и всё возможно.

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

Мы брали Android-приложение, запускали под эмулятором на Windows, захватывали кадр и смотрели внутрь: сколько полигонов, сколько draw calls, как сцена организована, как объекты объединены. В каких-то приложениях мы видели, что уровни вообще сделаны из «конструктора», но в момент загрузки сцены объединяются. Даже названия ассетов иногда наводят на интересные мысли.

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

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

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

Мы пошли от обратного и сказали: клиентская логика будет занимать не меньше половины. Для того, чтобы на Samsung Galaxy S III — нужно тратить на кадр не больше 30 миллисекунд CPU. Мы взяли, «отрезали» половину — и установили, что на всю графику осталось 15 миллисекунд. Это был лёгкий шок. Мы потратили довольно много времени для того, чтобы спланировать, как уместить всё в 15 миллисекунд. Левая схема — как планировали, правая — как получилось.

Чтобы просто нарисовать эту схему, нам пришлось искать ответы на новые вопросы, которые росли, как грибы.

С планированием памяти была такая же история. Вроде бы довольно просто посчитать — у нас восемь персонажей, мы подобрали текстуры с нормальным разрешением, перемножили, рассчитывая на Android-платформу со сжатием ETC1. Но на самом деле с памятью даже сложнее, и по таблице видно, что мы промазали вообще везде.

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

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

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

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

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

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

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

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

Хорошо оптимизированная «руками» сцена не даст серьёзного прироста, даже если вы включите галочку «Metal».

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

Все сцены у нас объединены с помощью замечательного плагина из ассет-стора Mesh Baker, который пришлось нехило допилить. Сцены объединены в минимальное количество больших кусков геометрии, Mesh Baker «запекает» нам текстуры.

Это существенно снизило количество draw calls и производительность подскочила. Сама сцена это 200 тысяч полигонов, и ещё 50 тысяч — это всё остальное: интерфейс, персонажи, оружие и так далее. Про размеры я уже сказал. Текстуры в сцене занимают всего 16 мегабайт, Mesh Baker сделал два «атласа» по 2048, два атласа лайтмаппинга и ещё где-то 12 маленьких сервисных текстур.

На определённом этапе маленькие устройства начали «падать» по памяти. Стали разбираться. Обнаружили, что мы использовали для Android сжатие ETC2. Слабые, старенькие девайсы, получая файлы в этом формате, не могут его распознать и «пережимают» их в incompress. А ETC1, в свою очередь, не поддерживает прозрачность. Что делать?

Пришлось доработать шейдеры всего проекта, чтобы все прозрачные объекты визуализировать с помощью двух текстур. ETC1 — сама RGB-текстура, и вторая текстура с альфой. Конечно, потребовалось немного больше текстурной памяти, но мы получили ещё два канала, в которые сейчас запихиваем маски для прикольных шейдеров.

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

Полезные ссылки: