[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } } ] { "gtm": "GTM-NDH47H" }
{ "author_name": "Глеб Диденко", "author_type": "self", "tags": ["unity","\u043e\u043f\u044b\u0442\u0442"], "comments": 40, "likes": 39, "favorites": 10, "is_advertisement": false, "section": "pro" }
3 268
Gamedev

Мобильный шутер 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, «из коробки». Оно даже получится, будет запускаться и хорошо выглядеть. Но чтобы сделать проект, который будет работать быстро даже на слабых устройствах, так или иначе придётся покопаться в каждом шейдере руками. И если кто-то из вас сейчас ещё в начале разработки, озаботьтесь тем, чтобы найти рендер-программиста, который будет понимать в шейдерах.

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

#unity #опытт

Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

Прямой эфир

Узнавайте первым важные новости

Подписаться