Досвід портування Five Nights at Freddy’s: Security Breach з ПК на Nintendo Switch

Вітаю, мене звати Влад, я Project Lead Developer of Unreal Engine Department у Pingle Game Studio. Портування ігор — один з основних наших напрямків, і ми вже торкалися цієї теми, детально розповівши про наш досвід роботи над The Eternal Cylinder.

В наступній статті мова піде також про портування, але на цей раз — про зворотнє, так званий даунгрейд. Нещодавно ми успішно перенесли останню гру з відомої серії хорорів — Five Nights at Freddy’s: Security Breach з ПК-версії на Nintendo Switch.

Робота з платформою минулого покоління

Nintendo Switch — це ігрова система 8-го покоління, яка поступила у продаж в не такому далекому 2017 му році, на даний час їй вже йде 6-ий рік. Для тих, хто знайомий з даним девайсом, не секрет, що навіть на старті виходу консоль вже була доволі слабка і ніяк не могла конкурувати за потужністю з іншими платформами. Але як виявилось, їй це і не потрібно, бо вона зайняла царське місце у портативному геймінгу, де є єдиною і незмінною платформою без конкурентів, завоювавши серця і гаманці мільйонів користувачів. Але для тих, хто не в курсі, простими словами — це дуже застарілий девайс.

Сам проект був розроблений на Unreal Engine 4. Рушій від Epic взагалі не стоїть на місці і постійно покращує свої показники — як якості, так і прожерливості заліза, на якому потрібно працювати.

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

Першим складним моментом було те, що 95% всієї гри було зроблено на системі візуального скриптингу Blueprint. Нас часто запитують, чи ігри на рушії Unreal Engine пишуться повністю на С++, чи використовуються Blueprint’и. Ця гра — яскравий приклад того, що навіть тайтли з великою аудиторією можуть писатися на Blueprints цілком і повністю.

Чому це проблема? Тому що таку гру в подальшому важко налаштовувати більш детально. Можливості С++ майже безмежні, можливості Blueprint — більш підходять для прототипування і загалом масштабувати, розвивати чи підтримувати на них проект доволі незручно.

Коротко про проблеми з легасі версії. На PC гра працює на 120 fps з просадками аж до 60 fps. Через низький темп гри цього цього майже не помітно. Також гра використовує пам’ять у обсязі близькому до Google Chrome, бо має на борту дуже оверсайзові текстури і анімації, карти світла і тіні тощо. Оптимізації практично не було — в жодному з аспектів гри.

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

Перейдемо до кейсів.

Коли в сцені залишився пустий простір — в пам’яті все одно було зайнято 2,5 Гб. Як подолали брак оперативної памʼяті на Nintendo Switch

У нас була релізна контрольна версія для PC, але логічно, що на портатив вона має йти у сильно спрощеному вигляді. Ми не знали, до якої якості можна даунгрейднути гру, щоб запустити на Nintendo Switch, і до якої якості підняти, аби вона пристойно виглядала і задовільно працювала.

Для вирішення цього питання ми придумали унікальний, на наш погляд, варіант, який назвали Beautiful Corner.

Оскільки гра має відносно відкритий торговий центр (такий собі опенворлд як в іграх жанру metroidvania), наша команда QA підготувала звіт по всіх локаціях, серед яких ми взяли шматок однієї найбільш навантаженої та скинули графіку на абсолютний мінімум, перевірили, як вона працює. І далі поступово піднімали її якість: це було розширення текстур, прорахування ШІ НПС і ворогів, запікання світла тощо. Коли картинка задовільняла команду і замовника, ми вже розуміли, приблизний рівень якості картинки, до якого треба прагнути, і як працювати далі.

А далі виявили, що грі катастрофічно не вистачає пам’яті при переході між частинами локацій світу. Це логічно, бо Nintendo Switch має всього 4 Гб пам’яті, серед яких насправді в доступі є 3.2 Гб. Згадаємо, коли смартфони мали 4 Гб? Здається, у часи 6-го айфону. Це дуже і дуже мало, особливо для гри, що прийшла з PC.

Був період, коли гра не запускалась взагалі. Тоді ми запустили сцену в грі і поступово крок за кроком прибрали з неї все, що тільки можна. Виявилось, що коли на сцені залишився пустий простір — в пам’яті все одно було зайнято 2,5 Гб. Цими «щось» виявились Hard references.

Hard references — це концепція рушія UE з посиланням на об’єкти між собою. На жаль, UE не вміє розумно розпоряджатися відвантаженням об’єктів у гру, і тому цей процес потрібно контролювати зі сторони розробників. Наприклад, маємо інстанс гри, який певним чином зачіпає головного персонажа через 5 класів посилань — і в результаті, коли завантажується гра, і всі зв’язки налаштовані як Hard references, до пам’яті потрапляє абсолютно все.

Як ми позбувалися зайвого? За допомогою інструменту UE Asset Viewer визначали, де саме ці хард референси знаходяться. Таким чином побачили зв’язки між компонентами гри. У результаті ми понизили розмір головного класу інстансу — з 2,5 Гб до 5 Мб. Hard references були успішно оптимізовані у цьому проекті.

Зламалися анімації та освітлення

Подолали попередню проблему — і потрапили у чудовий світ нових помилок. Зламалися анімації, ШІ, ефекти і інші моменти. Це був наслідок наших дій з Hard references, але інакше вчинити ми не могли. Тож довелося все лагодити. Наша команда грала в оригінальну гру на ПК і шукала створені вже нами баги. З цікавого, ми також передивлялися YouTube-проходження гри. Як виявилося, є фанати, які грають у FNAF спеціально для того, аби зламати гру для цікавого контенту, а для нас це було гарне джерело легасі багів, які вже існували.

Наступною проблемою було світло. Що з ним не так? А все доволі просто, його в цій грі дуже багато. Маємо хорор, відкритий світ, великі локації і з неймовірною кількістю неону — це все багато важить, і Switch просто захлинався.

Середній розмір Light Map-ів по локаціях важив 1,5-2 Гб. Нагадаю, що 3.2 Гб — це максимум, який може витягнути Switch для цілої гри з асетами, звуками і всім іншим.

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

Як ми вирішили цей кейс? Я повністю перезібрав Light Manager. Першочергова ідея розробників була зробити систему зміни світла, яке залежить від того, наскільки ти далеко пройшов гру. Торговий центр, що ним бігає герой, з кожним етапом мав ставати все темніше і поглиблювати атмосферу хорору. На жаль, цю ідею їм не вдалося втілити в життя, а от сама система залишилась. Ну що ж. Було прийнято рішення прибрати з гри цю ідею асинхронності і залишити стандартні «улюблені» loading screens. Гравці їх ненавидять. Це й зрозуміло, дуже приємно, коли гра безшовна. Але у нас знову не було іншого виходу.

На цьому етапі у нас вже з’явилося достатньо пам’яті, щоб почати покращувати гру і якісь красиві і необхідні речі підвищити у якості. Ми розтиснули деякі текстури, обробили модельки.

Робота з «полегшенням» важкої сцени

Один з цікавих кейсів стосувався рівня гри, в якому було дуже багато ігрових автоматів і телевізорів. В кожному з цих автоматів програвався окремий «мультик», що також потребувало багато потужностей девайсу. Тож команда техартів зробила величезну роботу щодо мерехтіння і відігравання цих «мультиків», аби полегшити гру. Але і це було не все: кожен автомат також був окремим джерелом звуку, тож наш Switch просто починав вішатись.

Звук з автоматів ми прибрали, а техарти вчинили достатньо хитро: зменшили кількість кадрів саме на цих об’єктах і одночасно з цим — пропорційно збільшили якість цих картинок. Замість 20 кадрів у нас програвалось 5, але в добрій якості. Вийшло стилізовано і гарно.

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

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини