Pingle Game Studio - про портування FNAF на Meta Quest

Pingle Game Studio вже не вперше працює з іграми франшизи Five Nights at Freddy’s. У цій статті йтиме мова про портінг гри Five Nights at Freddy's: Help Wanted 2 - з PS VR на Oculus девайси.

Oculus - специфічна платформа, має достатньо високі вимоги при своєму достатньо специфічному залізі. Тож портування гри вже обіцяло бути викликом.

При початковій розробці не враховувався той факт, що гра може портуватися на слабкі девайси. Команда оригінальної розробки робила цю гру під PlayStation VR - це потужні девайси, що намагаються по максимуму використовувати всі сучасні технології. Оригінальні розробники концентрувалися на тому, щоб картинка відповідала сьогоднішнім стандартам графіки, які є в індустрії. І це само собою породжує багато роботи по оптимізації та з контентом під час портування.

Тож в статті піде мова про те, як Pingle портували гру, що розроблялася під PS VR, на портативні девайси Oculus Quest .

Початок роботи

Перша складність полягала в тому, що на момент оцінки проекту команда оригінальної розробки була ще в процесі роботи над грою, тож ми не могли працювати на повну.

Для того щоб рухатись вперед, ми випробовували різні підходи і методики, як можна добиватись потрібного нам результату. Це був детальний пошук рішень, які ми зможемо одразу імплементувати, тільки-но оригінальний розробник закінчить роботу, щоб потім не витрачати на це час.

Oculus має ряд своїх особливостей. Це автономний девайс з рівнем потужності мобільного пристрою. При постійних високих навантаженнях пристрій перегрівається. Так само, як в мобільних пристроях, GPU в Oculus не така, як в консолі чи комп'ютері. Це набагато слабший пристрій, з повільнішим доступом до пам’яті, з повільнішою паралельною обробкою. Однак, вимоги досить високі: це стабільні 72 fps одночасно для лівого і правого ока в досить високому розширенні. Для розробників це все одно що малювати за раз два екрани.

Ми в Pingle завжди прагнемо якості. В даному випадку хотіли зберегти стилістику і наповненість кадру - максимально ту якість, яка була зроблена для PS. Звісно, довелося якісь елементи видалити. Однак всі основні речі, з якими гравець постійно взаємодіє і які у нього перед очима, ми старались максимально зберегти.

Наш пріоритет - це емоції і відчуття гравця. Не можна оцінювати ігри суто показниками. Якщо оцінювати лише цифрами, то це вже не гра, а програма. Граючи в гру на Oculus, гравець має отримати ті ж самі емоції, що й граючи в оригінальну версію на PS. Ти маєш вірити в те, в що ти граєш, тим більше якщо це гра у VR-шоломі, де ефект занурення ще більший.

Технічні виклики цього портування

Oculus - це Android device, і в тій версії рушія і конфігурації, з якою ми працювали, Android має обмеження - по рендерингу, по кількості джерел світла, по кількості і якості ефектів. Працювати з такими обмеженнями - великий виклик для всієї команди. Детально про кожен з технічних викликів розповідає Костянтин Олещенко, Project Lead of Unreal Department .

Виклик 1: Forward або deferred рендер, ось у чому питання...(c). Незважаючи на всі посібники, документацію та досвід, команда вирішила докласти певних зусиль, щоб ця гра працювала з deferred рендером в Oculus. Він не працював із коробки, тому спочатку ми виправили візуалізацію (за допомогою величезної допомоги розробників рендерингу)... і відмовилися від цієї ідеї – продуктивність була настільки жахливою. У найлегшій сцені з кількома акторами ми змогли досягти лише 23-25 FPS. Тож єдиним варіантом було forward-рендеринг. Пізніше, під час процесу розробки ми розробили чіткий конвеєр, який дозволяє нам досягти майже такого ж рівня візуальної якості, як і в оригінальній грі.

Виклик 2: лише 4 рухомих джерела світла, в той час як в оригінальній версії їх може бути до 20 на сцені… Це загальне обмеження мобільних Android-платформ (і Oculus тут нажаль не виключення). Ми переробили всі рівні, щоб відповідати цим обмеженням. Декалі були замінені комбінованими площинами та матеріалами (де це було можливо), постобробку було замінено на Tonemappers (і ретельно налаштовано, щоб досягти такої самої або близької до оригінальної візуальної якості). Але найскладнішою частиною було світло. Кожен рівень був ретельно перероблений, щоб використовувати якомога більше статичного світла.

Виклик 3: Обмеження розміру контенту. За замовчуванням UE4 підтримує до 3 файлів OBB (кожний не більше 4 Гб) для контенту. Meta store підтримує необмежену кількість додаткових файлів для ассетів. Оригінальний розмір гри становив близько 10 Гб у стисненому вигляді (24 Гб у нестисненому вигляді). Перша вимога полягала в тому, що потрібно використовувати лише нестиснений вміст. Друга — збільшити підтримку понад 3 OBB, що було успішно реалізовано (тепер ми можемо підтримувати до 5 Obb із загальним розміром контенту до 20 Гб). Останнє: під час роботи з важкими текстурами з’являлось багато коливань продуктивності, тому ми знайшли золоту середину, щоб вмістити близько 10 Гб нестисненого контенту за допомогою ASTC декодинг налаштувань. Це дозволило легко масштабувати будь-який додатковий контент і з легкістю керувати розміром білда.

Виклик 4. Підтримка Android API. На момент старту проекту Мета підняла мінімальний API для своїх аплікацій з 29 левела на 32 - це відповідає UE5. Рушій 4.27 з коробки це не підтримує, тож доводилося вносити модифікації в рушій, щоб можна було збирати білд під Android і Меtа його прийняла на submission.

Крок 5. Буквально за день до відправки на submission нам сказали, що під час будь-якого завантаження гри, обов'язково має крутитись якийсь спінер.

Якщо спінера немає, то Меtа просто не прийме Білд. Це не вплинуло на розробку, але стало для нас сюрпризом і коштувало однієї безсонної ночі.

Виклик 6. Згідно вимог для Oculus, гра не може завантажуватися занадто довго. При завантаженні гри статичний екран не може тривати більше 10 секунд.

На початку ми одразу попали в ці 10 секунд, але коли почали роботу над спайками і почали збирати ПСО кеш, цей час завантаження гри збільшився. Але з цим також команда справилась. Тепер у нас тепер є потрібні заглушки і спінери, і в цілому по оптимізаційній роботі результат було досягнуто - гра досить швидко стартує.

Виклик 7. Найважчий момент всього проекту. В Meta прописані технічні вимоги: 72 FPS, також допустимі короткострокові Performance дропи до 65 FPS. По факту, незрозуміло, що саме є короткостроковий дроп типу - це який? Ми бачили по графіках, що у нас є провисання в один кадр. Для геймдеву це нормальна історія: всі ігри мають короткострокові дропи.

Але у випадку сертифікації Meta, нам довелося боротися з цими дропами.

Проблема була в тому, що хоча ми могли бачити ці дропи на метриках, оком не було видно провисань в грі. Уявіть собі спайку в 30 мілісекунд - це майже неможливо побачити, особливо, якщо такий дроп лише один.

Коли ми власне готували білд до сертифікації, вже отримали певний результат по перфомансу і були впевнені, що оптимізували гру достатньо достатньо добре, добились такої стабільності картинки, що таких місць не було, де ця спайка могла бути помітна оку. Вона була помітно лише на графіку і ми сподівались, що цього буде достатньо. У всіх іграх вони існують, і на PlayStation 5, і на найпотужнічших комп’ютерах все одно є спайки. Так влаштований світ ігор.

Мета має застосунок VR metric tool, яким вони міряють перфоманс і будує графік fps. Будь-який дроп видний падінням графіку. Ти можеш грати і не помітити спайку, а на графіку вона відобразиться.

Наразі ми почистили абсолютно всі спайки, їх не видно не тільки неозброєним оком, а навіть на графіку нічого не відбувається нижче затребуваних 65 FPS.

Чому в нас вийшло це зробити?

Залученість найдосвідченіших експертів Pingle, разом з їхньою експертизою, мала вплив. Вони не боялись випробовувати різні рішення. Гра написана на UE4, і ми використовували ті функції, які вже є в п’ятій версії рушія, але в четвертій ще вважаються експериментальними. Налаштовували, випробовували. Наша експертиза і знання рушія дозволили з цим працювати. Спираючись на детальний аналіз і профайлінг, який виконувала команда, знайти той шлях, що дозволив поборотись з усіма проблемами.