{"id":3843,"url":"\/distributions\/3843\/click?bit=1&hash=d0b9071c1d51ff8dd5fb0c35f42f4694a7ad9533adc9c6fcd790aa99ecda7c05","title":"\u0414\u043e\u0440\u043e\u0433\u0438\u0435 \u0433\u043e\u043b\u043e\u0441\u043e\u0432\u044b\u0435 \u0440\u043e\u0431\u043e\u0442\u044b vs. \u043d\u0435\u0434\u043e\u0440\u043e\u0433\u0438\u0435 \u0433\u043e\u043b\u043e\u0441\u043e\u0432\u044b\u0435 \u0440\u043e\u0431\u043e\u0442\u044b","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
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, «из коробки». Оно даже получится, будет запускаться и хорошо выглядеть. Но чтобы сделать проект, который будет работать быстро даже на слабых устройствах, так или иначе придётся покопаться в каждом шейдере руками. И если кто-то из вас сейчас ещё в начале разработки, озаботьтесь тем, чтобы найти рендер-программиста, который будет понимать в шейдерах.

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

0
36 комментариев
Написать комментарий...
Андрей Тузов

А не проще ли, было бы взять UE4?

Ответить
Развернуть ветку
Кирилл Рыбин

UE4 из коробки не решит все перечисленные проблемы. Также придется все оптимизировать.

Ответить
Развернуть ветку
Андрей Тузов

Как я понял из статьи, оптимизировали вообще всё. С исходным кодом, ИМХО проще такие вещи проделывать. Чем с чёрным ящиком

Ответить
Развернуть ветку
Gennadii Potapov

У Unity не так много проблем с самим движком, дело в том как ты его используешь. Оптимизация ресурсов, хорошая работа с паматью и правильная структура важнее ковыряняя в кишках Unity.

И доступ к исходникам Unreal не гарантирует что ты сможешь в нем разобраться, чтобы оптимизировать на низком уровне.

Ответить
Развернуть ветку
Андрей Тузов

"У Unity не так много проблем с самим движком, дело в том как ты его используешь."

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

". Оптимизация ресурсов, хорошая работа с паматью"
В статье авторы пишут как они с этим "хорошим" боролись, чтоб было лучше.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Алексей Егоров

У Unity очень много проблем с движком. Причем детских. И никто не собирается их решать.

Ответить
Развернуть ветку
Gennadii Potapov

Какие именно?

Ответить
Развернуть ветку
Алексей Егоров

А если вспомнить историю про скелетную анимацию, то это просто курам на смех. Unity - это сильный движок с точки зрения продвижения, низкого порога вхождения, простоты использования. Но не с точки зрения технологий. Технологически, Unity - просто кусок хлама, красиво замазанный C# api, мелодично воспетый евангелистами, с хорошо раскрученным маховиком community. Unity - это про удачный бизнес, а не про хорошие технологии.

Ответить
Развернуть ветку
Кирилл Рыбин

Ваш комментарий хочется одновременно и плюсануьть и заминусовать ))

Ответить
Развернуть ветку
Алексей Егоров

В чем же я не прав? Или может быть, вам хотелось бы, чтобы я был не прав?

Ответить
Развернуть ветку
Алексей Егоров

Огласить весь список? Мне кажется, хватает только отсутствия nested ассетов. Этого могло не быть первые 3 года существования Unity, но учитывая то, сколько времени существует этот движок, можно сказать, что уже поздно. Хотя они вроде планируют это сделать.

Ответить
Развернуть ветку
Gennadii Potapov

Nested ассеты? Я слышал про проблему с nested prefabs, а в чем дело с nested assets?

Ответить
Развернуть ветку
Алексей Егоров

Префабы конечно же.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Андрей Тузов

"Тоесть вы поняли из статьи, а не из своих 100500 выпущенных проектов?"
Зачем столько сил тратить, пилить 100500 проектов? Из одной простенькой демки стало понятно: Гуй+ Сеть+ Пасфайндинг + генерация уровня + шейдер = оптимизация, костыли, велосипеды

Ответить
Развернуть ветку
Andrey Yunoshev

Доступ к сорацам Юнити тоже есть - это не помогает. Плюс мало кто готов форкаться, и каждый апдейт каждый раз мержить изменений свои.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Андрей Тузов

https://play.google.com/store/apps/details?id=com.nexon.hit.global&hl=ru

Ознакомьтесь. Китайцы и корейцы неплохо стреляют из пушки по воробьям. Игра на UE4 сделана. Учитесь!

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Андрей Тузов

Хороший тверк!

Ответить
Развернуть ветку
Denis Kuandykov

По моему опыту в Unity оптимизировать проще.
И вообще логика Unity в том что из коробки он "пустой" - хочешь фич и оптимизаций то накатываешь их сам.
UE4 же весь испичкан крутыми фишками, которые порой наоборот мешают и выползают подводные камни.
Т.е в UE4 приходится из кода вырезать, и компилить свою версию движка.
По мобильной физике на одном из проектов так и поступали, и запускать редактор приходилось прямо из VSstudio.

В итоге оптимизировать UE4 можно, но требует больше времени/знаний/ресурсов.

(ИМХО)

Ответить
Развернуть ветку
Антон Мусин

Спасибо за копию TF2

Ответить
Развернуть ветку
Max Donskikh

разве не Овервоч?

Ответить
Развернуть ветку
Антон Мусин

Найди 0 отличий с первой пикчей в посте

Ответить
Развернуть ветку
Ilya Eremeyev

Хэвик с пулеметом это уже просто популярный архетип.

Ответить
Развернуть ветку
Max Donskikh

мы тоже любим ТФ2

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Max Donskikh

так и в ТФ классы. в ГОБе нет.
просто с чем уже только ни сравнивали игру.

Ответить
Развернуть ветку
Eugen Dubovik

Супер, давно ждал чего то подобного, спасибо

Ответить
Развернуть ветку
Valentin Kirillov

Кто-нить объясните зачем нужно было динамический батчинг вырубать? Про статик-батчинг дело понятное, на мобилах от него часто больше вреда, чем пользы. А динамический-то за что? Он же в основном для уменьшения количества dc всяких частиц, эффектов, да прочей мелочи. И вполне стоит своего присутствия.

Ответить
Развернуть ветку
Denis Kuandykov

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

Это в принципе быстро, но еще быстрее полностью контролировать сшитую геометрию и сразу ее грузить.

Ответить
Развернуть ветку
Алексей Егоров

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

Ответить
Развернуть ветку
Dmytry Gladilin

Давний инсайт команды... Совсем давний: "И на Unity можно делать круто!"

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

По UE4:
- Сравните сколько весит пустой мобильный проект собранный из под UE4 и Unity.

По батчингу:
- В коментах уже отписали, но все же: А что им батчить в GOB?

Про частицы:
- Алексей Егоров все правильно понял)

Про исходники:
- Нам помогает иногда найти ответ на вопрос: "Почему?!!!", также иногда помогает найти недокументированные функции. В последнее время почти перестали смотреть в исходники, наверное накопилось достаточно опыта.

Ответить
Развернуть ветку
Danny Lamb

Это такая беспалевная реклама для такой слабой игры? Сначала на TJournal (вместе с отвратительной Last Day on Earth), теперь и тут?

Хотя бы не так сильно палились вдохновляясь/воруя у других видеоигр.

Ах да, будет ли ещё статья от этих авторов в духе "Мы планируем зарабатывать 2 миллиона долларов в месяц»: интервью с создателями "вставить имя игры""?

Ответить
Развернуть ветку
Ilya Eremeyev

Всмысле, отвратительной? Last Day on Earth - отличная, я уже 2 недели залипаю, почти чоппер собрал!

Ответить
Развернуть ветку
Ilya Eremeyev

хотя, чего я с анонимом спорю)

Ответить
Развернуть ветку
Алексей Егоров

Никаких тебе PVS, секторов, порталов и т. д. Просто сшили все в одну кучу и ограничили художников в полигонаже. Чистая победа.

Ответить
Развернуть ветку
Кирилл Рыбин

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

Ответить
Развернуть ветку
Sergey Kopov

Отличная статья, спасибо! Было бы круто. если бы рассказали еще подробнее о проблемах и решениях. И вообще супер, если пошарите упомянутую программу, которая тестирует возможности телефонов!

Ответить
Развернуть ветку
Читать все 36 комментариев
null