Почти все, что вы хотели знать о разработке VR игры на UE4

Всем привет! Меня зовут Артем Северин и я — один из разработчиков Witching Tower VR, action-adventure для VR.

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

Мы — небольшая компания Daily Magic Productions. В свое время наладили процесс производства Hidden Objects Puzzle Adventure игр, поставили на поток, и стабильно, в установленные сроки, выпустили более 20 успешных проектов за 9 лет. Также в нашем портфолио — несколько мобильных проектов. Успешных и не очень.

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

В современном мире разработки игр есть вещи, за которые нужно цепляться, чтобы не отстать и продолжать идти в ногу со временем. А мы уже почти отстали: художники работали в одном стиле, занимаясь одной и той же рутиной изо дня в день, программисты писали в Visual Studio 2008 (это в 2015 году-то), скриптеры и дизайнеры уровней работали с изданным в 2009 году движком на основе Playground. Тем не менее, вся эта машина работала практически идеально. Это как старый сервер, который великолепно выполняет свои функции, но не позволяет ничего изменить в процессе, так как технологически устарел. А время требовало изменений: бюджет, портирование, оптимизация, локализация, сроки.

А что делать-то будем?

Вопрос выбора ниши для нашего эксперимента практически не стоял. Мы просто хотели сделать VR игру. А еще VR соответствовал трем пунктам:

Перспективы. Так или иначе, VR — это будущее. Этого хочет Oculus, этого хочет HTC. Мы уверены, что в 20ХХ настанет момент, когда VR будет в каждом доме и торговом центре, а у нас уже наберется достаточная экспертиза, чтобы удовлетворить потребности игроков.

Низкая конкуренция. В общем разделе Steam выходят десятки игр ежедневно. В VR разделе — 1-2 игры. Есть отличные игры, есть не очень. Сейчас у каждого появился шанс отхватить свой кусок пирога, который уже довольно крупный.

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

Технологичность и современность. VR — это тренд, который пока не собирается отступать. Что касается выбора технологии разработки, имея за плечами опыт работы с различными движками, мы без раздумий остановились на Unreal Engine: обучающие ролики, низкий порог вхождения (для базовых задач, естественно), куча контента и отличный маркетплейс — это всего лишь маленький пласт бонусов, который дарит тебе Epic Games.

С места в карьер

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

Теперь, оглядываясь на проделанную работу и имея небольшой багаж знаний, я хочу поделиться советами по оптимизации и построению процесса, которые помогут в разработке VR игры (в принципе, эти знания полезны при создании любых проектов на Unreal Engine). Возможно, это будут советы Капитана Очевидность, но я уверен, что мы — не последняя компания, которая прыгнула с места в карьер, освоив немаленький пласт знаний за несколько месяцев.

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

Это значит — забудьте о красивом насыщенном открытом мире, где будут лежать сотни мелких объектов, для которых работает физика и возможность взаимодействия. Ваша цель — 90 fps (в случае PS4 — 60 fps) или 11 миллисекунд.

Сливайте объекты (Actor Merge). Это очень тонкий момент, который сильно зависит от конкретной ситуации. Идеальный вариант вы сможете получить, только протестировав и сравнив результаты. Очень грубо: если видите просадку по draw call — сливайте. Если видите проблемы по рендеру, слитие только усугубит ситуацию, будет отрисовываться больше полигонов. Нет смысла сливать 5 объектов, если вы постоянно видите 1 из них, так как вместо одного будет рисоваться 5. Если же эти 5 объектов видны только вместе, их лучше слить.

Вы можете включить VR Instanced Stereo (Stereo Rendering), если это еще не сделано. Без него у вас будут вызовы отрисовки для каждого глаза вместо одного. Stereo Rendering улучшит использование процессора, но ухудшит GPU. Вы выиграете по draw calls, но ценой добавления какого-то числа инструкций в материалы.

Проверьте разрешение. Есть вероятность, что у вас завышенное разрешение, как было у нас (2700x1600). Мы уменьшили его до 2160x1200 (фактическое разрешение Oculus Rift в пикселях). Это снизило нагрузку с GPU, а игра продолжила выглядеть великолепно.

LOD. Скорее всего, вы об этом знаете, но лучше я повторюсь. Это мощнейший инструмент, без которого никак не обойтись. В некоторых местах, придется вручную создавать специальные облегченные материалы, меняя translucent на masked, а masked — на opaque и тд. Но это того стоит.

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

Translucent. Старайтесь использовать полупрозрачность и прозрачность по минимуму, а если используете, избегайте наложений. В основном, проблемой переизбытка прозрачности грешат эффекты, но кроме этого, наложение может встречаться еще много где: god rays, трава, кусты, стекла, корни и тд. Проблемные места прекрасно видны в Shader Complexity. Да, он не всегда работает верно, но в целом общую картину показывает. Также не особо верьте Shader Complexity в Cascade. Вытаскивайте эффект на рабочую сцену и смотрите там.

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

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

Оптимизируйте VFX — продумывайте LOD и отображение эмиттеров в зависимости от качества графики сразу, чтобы в будущем к этому не возвращаться. Во-первых, вы сможете это сделать максимально качественно с первого раза, так как у вас есть вижн и "вы в задаче", во-вторых, это сэкономит кучу времени в будущем, тем более, если заниматься этим придется не вам. Если мастер по эффектам этого не делает — обяжите его. Это одна из основных его задач.

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

Хинт: если вам необходимо, чтобы количество рождаемых эмиттеров происходило независимо от качества графики, вам поможет снятие галки с параметра Apply Global Spawn Rate Scale в параметре Spawn. Это бывает необходимо, когда при низких настройках графики UE сокращает количество рождаемых частиц, и эффект отображается некорректно (дергаясь, с большими задержками).

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

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

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

Проверяйте Bounding box. Очень часто бывало — бродишь по уровню и чувствуешь, что что-то не отсекается. Почти 100% вероятность, что в такие моменты ваши Bounding box слетели. Это нередко происходит с эффектами, особенно, когда автоматически генерируешь Bounding box в GPU частицах и удаляешь их. Такая проблема заставила нас пройтись по всем эффектам и искоренить ошибки.

Используйте RenderDoc. Это небольшая тулза, которая анализирует каждый кадр в игре, помогая определить, что убивает fps. Я крайне рекомендую использовать ее при оптимизации игры.
 

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

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

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

Пара слов о нашем релизе

Мы не имели опыта релиза игры в Steam, тем более — с Oculus или VIVEPORT. Конечно, мы наступили на внушительное количество садового инвентаря.

• Нам пришлось несколько раз перенести релиз, и мы вышли в не самый удачный день (возможно, лучший из худших), поэтому собрали прицеп проблем.
• Мы вышли перед Halloween Sale, в итоге пропустив эту распродажу.
• А еще это произошло за день до релиза Red Dead Redemption.
• Игра попала только на вторую половину Autumn Sale, которая генерирует хорошие продажи. (К слову, все Steam распродажи увеличивают количество купленных игр x2-x4. У кого-то больше. В этот момент, кстати, активируются ваши Wishlist-покупатели)
• Мы разослали прессе проблемную версию билда и получили несколько негативных реакций блогеров о просадках fps и оптимизации в целом.
• Нашу игру обделили вниманием практически все крупные издания и стримеры из-за снятия эмбарго на Red Dead Redemption и приближающихся скидок. Обычно, перед такими событиями выпускают рекомендации/анонсы/восстания из пепла, и много подобного информационного шума.
• Мы моментально схватили негативные отзывы из-за небольшого бага, который стабильно и полностью убивал fps в игре.

Поговорим о магазинах

Steam

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

Все происходит в 3 этапа:

Заполнение страницы в магазине. Рекомендую выходить на этот этап уже с крутыми скриншотами и интересным описанием игры.

Апрув игры. В течение 5 рабочих дней вам придет апрув (или нет), после чего вы можете спокойно и в реалтайме обновлять билд, без необходимости очередного апрува. Вам не придется каждый раз заливать все ваши 30 гигабайт игры (как происходит в некоторых других админках) — Steam обновит только то, что вы изменили или добавили. Также в Steam существует система App branches, которая позволяет делать ветки для прессы, ютуберов, тестеров. Очень удобно.

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

Вы можете выпустить апдейт, который позволит провести еще несколько раундов промоушена. Вы можете сделать 5 таких раундов. Это немного поможет увеличить видимость игры, но не обольщайтесь — наплыва покупателей не увидите. Это прям настолько незначительно, что об этом можно даже не говорить. Мы получили плюсом ~3% вовлеченности от стандартного значения. Но это наш опыт первого раунда, у вас, возможно, будет лучше.

Что нужно учесть?

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

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

Никогда не вносите правки в билд перед релизом! Просто знайте. Это табу.

А мы что сделали? "Просто" добавили 1 декоративный элемент в туториал, и он просадил весь fps в игре. Это было настолько плохо, что человек с видеокартой GeForce RTX 2080 писал о проблемах с fps. Это смешно и грустно. Если вам кажется, что ничего плохого не случится — это скорее всего случится.

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

Дата релиза. Отнеситесь к этому очень серьезно. Проанализируйте близлежащие скидки и релизы конкурентов, или выход крупных проектов, расписание мероприятий. Вы должны сделать так, чтобы весь фокус прессы и стримеров был на вас, а не на GDC, CES, Oculus Connect или Red Dead Redemption. "Причем тут Red Dead Redemption, когда это консоль, а я VR и выхожу в Steam?" При том, что ни один популярный стример не выберет вас, если в этот же день вышла игра, интересная миллионам людей.

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

Также правильно продумайте релиз с учетом скидок. Знайте, что вы не сможете участвовать в скидках и промоакциях, если со дня вашего релиза не прошел месяц. Например, если вы вышли 5 декабря, уже не сможете участвовать в Winter Sale.

НТС

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

Также в HTC идет активная социальная поддержка. Они репостят ваши записи, показывают ваши игры на своих каналах и в своих группах. Не забывайте прописывать хештеги VIVEPORT и указывать их группы в своих постах.

В целом, в админ панели все понятно. Единственное, при отправке на ревью не забудьте нажать кнопку “Create production release”, а не “Create a Beta version” в разделе Submit. Один раз, в момент важной отправки, мы не нажали кнопку, и HTC не увидели наш билд. Дело в том, что когда билд отправляется в Beta, сотрудники HTC не видят его. В Beta вы можете проверить производительность своей игры, ресурсы витрины и тд.

Апрув проходит немного дольше, чем в Steam. Чуть больше недели. Билд нужно загружать каждый раз полностью. Причем утверждается каждая версия. Учитывайте это. Небольшой хинт: если у вас есть критический баг или действительно весомая причина для быстрого апдейта билда в магазине, вы можете попросить провести ускоренную проверку.

Oculus

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

Чтобы получить такой результат, нужно смириться с тем, что вам придется заниматься биздевом и работать со своими контактами в Oculus постоянно, а не просто углубится в тонкости разработки.

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

Что касается админки, в ней все просто, очевидно, и она великолепна.Там вы найдете много вещей, которые помогут в разработке, начиная от рекомендуемых системных требований и отчетов по ним, до чек-листов, описания специальных приложений и гайдов. Обязательно изучите раздел Develop/Doc/Unreal. Они постарались. Билды из консоли, как и в VIVEPORT Developer Console, придется обновлять полностью. Но вы можете скачать специальную тулзу от Oculus (сейчас это обязательно для игр весом более 1 гигабайта), с помощью которой можно заливать билд. Скорость заливки выше (по крайней мере, у нас), обещают, что заливаться будут только изменения.

В Oculus Developer Console существует три ветки: ALPHA, BETA, RC и STORE. Oculus начнет смотреть ваш билд только тогда, когда вы зальете его в STORE. До этого момента они даже могут не знать о вашем существовании.

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

***

В заключение хочу сказать, что наш эксперимент можно считать состоявшимся. Команда Daily Magic прокачалась, совершив огромный рывок над пропастью. Мы научились работать в Unreal Engine, поняли принцип создания 3D миров и окружения в нем. Осознали, что важно, что не важно и научились грамотно расставлять приоритеты. Компания получила отличный проект в портфолио, который уже приносит свои плоды. Теперь перед нами открыты горизонты, которые ранее казались недосягаемыми. Верьте в себя и своих коллег, и вы сможете добиться крутых результатов.