Доработка From Inferno после джема

Как мы дорабатывали игру с джема и через сколько боли прошли.

#лонгрид

Доброго времени, DTF! Эта статья является логическим продолжением предыдущей, где мы рассказывали в подробностях об участии в хакатоне (джеме). Если вы её не читали - ничего страшного, в начале будет краткая сводка, но всё-таки рекомендую глянуть :)

Напоминаем, что вы можете поиграть в версию игры, которую мы сдавали на хакатоне. Она доступна тут и о ней как раз сейчас пойдет речь.

From Inferno ранней версии представляла собой экшен-головоломку с элементами жанра Tower-Defence. Игроку необходимо взять под контроль армию демонов и уничтожить базу противника, минуя выстроенную оборону. Можно расставлять разных юнитов в реальном времени, тратя на это свой ограниченный бюджет. Так как каждые корабли имеют свои характеристики (скорость движения, урон, скорострельность, количество здоровья, радиус обзора и др.) - имеет значение, в каком порядке, в каком месте и в каком соотношении их устанавливать. Также есть дополнительные задачи, вроде: успеть за определённое время, потерять не более определённого количества юнитов, оставить какое-то количество денег в запасе или обойтись малыми силами и поставить поменьше кораблей.

Конечно, тут уже можно отметить ряд проблем в геймдизайне (и не только), особенно если глянуть на получившийся результат.

Если говорить об оптимизации, то проще сразу привести конкретный пример, который отразит всю суть:

RTX 2070 Super + AMD Ryzen 2700 + 16 GB DDR3 RAM - выдавало 150 +- 15 на “неактивной” сцене. При установке 17-и простейших AI - падало до ~60 FPS.

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

Не долго думая, мы с командой быстро приняли решение продолжить этот проект, забросив старый в архив (Который был довольно продуманным и существовал в “бумажном виде” на ~60 страниц, но идеи, описанные там - были слишком амбициозны).

Кроме того, наша команда пополнилась двумя талантливыми людьми - художником и музыкантом. С их помощью появились возможности реализовать проект в таком виде, в котором он будет выглядеть не стыдно и не являться сборником ассетов (на данный момент мы используем только библиотеку Megascan и то, в очень в редких случаях). Можете, кстати, оценить их уровень!

Виктор "Ragielof" - наш музыкант, можете глянуть его профиль в SoundCloud. Пишет крутую музыку, показывает страшные скриншоты с кучей аудио-дорожек.

Катерина "Koshakk" - художник и по совместительству дизайнер, вот один из артов на тему From Inferno. Делает красиво даже там, где это кажется невозможным.

Даниил "TwilightHunter" - 3D-моделлер, сценарист и нарративный ГД. А еще источник крутых идей, реализовать которые мы чаще всего не имеем возможности :)

Никита “theonrd” - Геймдизайнер, но в целом занимаюсь всем: от рисования концептов и планирования, до разработки и всяческим связям, а самое любимое — environment-дизайн!

Никита “niki119” - Техническая часть в самых глубинных смыслах и разработчик искусственного интеллекта. Единственный в команде, кто действительно хорошо дружит с этим и не готов убегать в панике от вида сложных систем :)

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

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

Стоит сказать, что многие идеи (в том числе центральные) сразу отвалились. Например, пропал космос и действие перешло лишь на одну планету. Конечно-же, она будет включать в себя разные локации в разных биомах: от жарких пустынь до холодных зим; от токсичных, убивших всю природу, заводов, до нетронутых воздушных островов, где собралась “элита” этого мира. Таким образом, мы смогли лучше прописать лор, построить более понятную сюжетную линию и, в целом, лучше продумать всю сценарную часть.

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

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

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

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

Полностью переписали все геймплейные скрипты, так как они не позволяли внести изменения выше.

С проходом нашего художника и дизайнера - решили отказаться от текущего интерфейса, так как он ужасен эстетически и не очень подходит под изменившийся геймплей логически :) Но нового пока еще нет, так что, увы, пока показать не можем. Зато можем показать старый.

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

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

Вообще, в Unreal Engine 4, “тупой” порт сделать довольно легко: нам достаточно было просто изменить платформу в настройках проекта и отключить туман (Т.к. он не поддерживается. Хотя не исключаю, что его можно как-то включить). Для более сложных игр потребуется немного повозиться с шейдерами, так как не все функции поддерживаются на всех платформах, а еще есть немного других ограничений (по освещению, количеству вершин на моделях и более мелкие), но в целом - тоже не должно доставить проблем.

Вот такой вот порт без особой обработки "порадовал" нас следующими результатами:

В целом, если не учитывать размер, то результат оказался даже не плох, учитывая что оптимизацией мы еще даже не занимались. И так как смартфонов у нас подходящих для тестов не было (Мой samsung S4 безнадежно устарел, а у команды, как назло, либо телефон сломался, либо еще более устарел), то мы решили начать с веса, всё-таки 1.5GB - это уж слишком. Для статистики выше, если что, тестировали у друзей (а на своём новом А51 - просто протестировал уже позже).

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

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

Когда текстурам понизили разрешение до более адекватных значений, обратили внимание, что игра генерирует под 1-1.5 тысячи запросов на отрисовку (DrawCall’ов) и их количество линейно растёт после начала активной фазы (когда спавнишь юнитов и они начинают атаку). Это слишком много и явно не соответствует сцене, даже будь это ПК игрой.

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

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

Если вы занимаетесь разработкой игр на Unreal Engine 4 и также имеете мало опыта, то обратите на это внимание. Команда для профайлинга со скриншота - stat SceneRendering. В итоге удалось прийти к следующим значениям (Хотя тут еще есть куда расти):

На эту тему существует больше информации, её легче гуглить, да и комментарии у параметров обычно вполне информативные.

В первую очередь можно посетить официальную документацию, там всё хорошо расписано. А если нет возможности воспринимать английский - переводчик отлично справляется :)

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

Кроме того, “по советам с форумов” включил Blueprint Nativization, что должно было увеличить FPS, но заметной разницы не заметил. Так как я не с++ программист и были задачи куда более важные - до более глубокого изучения руки еще не доходили, но когда-нибудь, быть может…

Ну и еще один… Совет? Не совсем так. В общем, у нас был забавный баг с тем, что мы забывали уничтожать пули и они могли бесконечно лететь, тратя ресурсы на просчёт движения. Конечно, мы не использовали для них полноценный movement-компонент, не использовали даже прожектайл-компонент - лишь простой векторный сдвиг с правильной привязкой к времени кадра.. Но всё-равно это кушало немало FPS. Так что, если делаете игру, проверьте, всё ли вы уничтожаете? Простая невнимательность может аукнуться тут довольно серьезно :)

На данный момент мы готовимся к началу ЗБТ (среди друзей и активных пользователей среди аудитории), а потом к ОБТ (если хотите поучаствовать - заходите в наш дискорд или группу в VK, мы обязательно всех пригласим, когда придёт время!).

В ОБТ мы планируем показать первую локацию, получить новые идеи, критику, обнаружить баги и, в целом, хотим сделать игру совместно с аудиторией, ведь играть-то будут люди, а не мы (хотя и мы тоже, но всё-таки!). Хотим подойти к этому со всей ответственностью, так что будут различные опросы, конкурсы и прочие активности!

Но для этого нужно выполнить несколько задач:

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

https://t.me/f1cont

Спасибо за прочтение, надеюсь, что было хоть немного интересно :)