«Ми стали одними з перших у світі, хто отримав девкіти Switch 2». Виклики портування Lynked на консолі Nintendo

Привіт! Мене звати Богдан Степанець, я обіймаю посаду Project Lead of the Technical Art Department у Pingle Studio.

Нещодавно ми завершили портування гри Lynked: Banner of the Spark на Nintendo Switch 1 та Nintendo Switch 2. Для нашої компанії це був перший досвід роботи з новою, довгоочікуваною консоллю, і ми стали одними з перших у світі, хто отримав девкіти Switch 2.

У цій статті я хочу поділитися враженнями від роботи з платформою та розповісти про технічні особливості процесу портування.

Про Lynked: Banner of the Spark

Lynked: Banner of the Spark — це RPG із елементами стратегії, де гравець розвиває власне поселення, досліджує різні біоми та взаємодіє з мешканцями.

Nintendo Switch 2 справляє цікаве враження. Вона має більше пам’яті, більший екран і ширші технічні можливості. Тепер не потрібно думати, що саме відключити для економії ресурсів — навпаки, можна додати більше візуальних ефектів, красивіше освітлення, зробити зображення по-справжньому привабливим.

Порівняно з першою версією, завдяки збільшенню пам’яті, ми фактично забули, що таке краші. FPS від початку був високим.

Ми вже не думали про те, де треба «різати» продуктивність, натомість лише про те, де і що можна покращити, залишаючись у межах нашої цілі в 60 fps. Головна різниця між Switch 1 і Switch 2 полягає в тому, що друга версія відкриває набагато більше можливостей для гри, і для розробників, і для гравців.

Технічні виклики портування на Nintendo Switch 1

Одним із головних викликів портування було те, що гра дуже велика.

Перший місяць ми фактично займалися дослідженням: аналізували, проводили заміри, дивилися, що саме можемо оптимізувати. Шукали найскладніші місця, тестували різні підходи, визначали, де і що можна «підрізати». І не завжди одне рішення підходило для всіх ділянок — десь воно спрацьовувало, а десь потрібно було інше.

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

Додаткову складність внесло й те, що вже посеред проєкту замовник додав третій біом — процедурно згенерований. Нам довелося буквально «на льоту» розібратися, як він працює, і швидко внести необхідні зміни, щоб він стабільно працював на консолі.

До речі, гра спочатку була створена для PC і вже вийшла на цій платформі — її можна було купити й пограти. Проте питання перформансу все одно стояло гостро, тому оптимізація для Nintendo стала окремим викликом.

Проблеми в лісовому біомі

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

Початкові рівні були частиною туторіалу, який знайомив із базовими механіками гри. Там траплялися дрібні технічні проблеми, але вони швидко виправлялися. Ми були впевнені, що складних моментів не буде.

Але далі, коли гра відкрила наступний, лісовий біом, ситуація змінилася. Сцени містили дуже багато дерев, кущів, квітів, і кількість полігонів в окремих моментах була надзвичайно високою, навіть для ПК.

Полікаунт (polycount) — це кількість трикутників, які присутні в сцені. Для Switch ми ставили собі ціль до 500 тисяч трикутників на сцену (разом із персонажами, ворогами та оточенням). Але на практиці в деяких сценах кількість доходила до 3,5 мільйонів трикутників.

Це створювало величезне навантаження і вимагало створення LOD’ів майже для всіх об’єктів у грі. Ми проходилися буквально по кожному, один за одним. І хоча об’єктів було дуже багато, ми поступово все оптимізували.

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

До речі, лише у цьому лісовому біомі понад 110 рівнів. Спочатку ми думали, що вони процедурно генеруються, але з’ясувалося, що всі зібрані вручну. Тож кожен рівень вимагав окремого підходу та ретельного тестування.

Робота над пустельним біомом

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

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

Рівнів у цьому біомі було трохи менше: приблизно 60, але робота все одно залишалася масштабною. Ми створили спільну таблицю, розділили рівні між людьми в команді й оновлювали статуси щодня.

Наприклад: «Сьогодні я пройшов 10 рівнів, знайшов такі-то проблеми — передаю на тестування».

На початку це виглядало майже нереальним: три людини — понад сто рівнів загалом. Ми хвилювалися, що фізично не встигнемо пройти все, навіть маючи готові рішення.

Але зрештою встигли і зберегли якість гри.

Процедурно згенерований біом

Після пустельного біому нам додали ще один — процедурно згенерований.

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

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

Основні проблеми були стандартні:

• надто високий полікаунт у деяких модулях;
• важкі матеріали, які потребували спрощення;
• зайве освітлення, яке не виконувало функції, але забирало ресурси.

Ми поступово проходили по всіх цих частинах, відключали непотрібне, замінювали матеріали на простіші без втрати якості зображення, стискали текстури.

Коли зрозуміли структуру, процес став набагато ефективнішим, вдалося швидко оптимізувати біом і досягти стабільного перформансу навіть при процедурному складанні рівнів.

Робота в одній гілці з замовником

Ще один важливий технічний момент — ми працювали в одній гілці з замовником.

Тобто в нас не було окремої гілки для Nintendo Switch чи для інших платформ, усе велося в єдиній гілці разом із версіями для ПК та консолей.

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

Через це довелося трохи змінити пайплайн роботи, щоб не заважати ні замовнику, ні собі. Ми підлаштовувалися під графік їхньої команди, оскільки більшість працювала в США.

Наприкінці нашого робочого дня ми звільняли рівні, щоб замовники могли працювати далі у своєму часовому поясі.

Але траплялися й складні ситуації: іноді ми завершували зміни, віддавали рівні, а замовник за день вносив свої правки і частина нашої роботи губилася. У результаті доводилося оновлювати проєкт і повторно проходити ті самі завдання.

Візуальний стиль гри

Замовник із самого початку орієнтувався на візуальний стиль студії Ghibli — такий самий теплий, мальований, із великою увагою до деталей.

У них навіть були референси з фільмів, на кшталт «Ходячого замку Гаула» чи інших класичних стрічок Гіблі.

І треба сказати, що візуально в них вийшло дуже гарно: трава, кущі, дерева виглядали майже як намальовані вручну, із цим характерним ефектом «2D-анімації в 3D-просторі».

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

Цікаво, що у замовника був незвичний метод рендерингу фоліаджу.

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

Виглядало це справді круто, візуально дуже виразно, але з технічної точки зору — дуже важко для продуктивності.

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

Кастомні шейдери та робота з візуальним стилем

Попри всі оптимізації, ми прагнули зберегти максимальну схожість із оригінальним виглядом гри. Замовник справді дуже ретельно ставився до візуальної частини, і навіть на Switch гра виглядає надзвичайно симпатично.

Щодо кастомних шейдерів, то наш шейдер для рослинності був не єдиним.

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

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

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

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

Оптимізація для Nintendo Switch 2

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

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

Загалом перехід на Switch 2 став радше приємним етапом, ніж викликом. Після важкої оптимізації для першої версії, працювати над другою було вже майже «прогулянкою». Ми просто поступово додавали те, що раніше довелося вимкнути. Робота зайняла приблизно два місяці, ми займалися лише покращеннями і це була дуже приємна робота.

Але треба було постійно залишатися в ногу з клієнтом, адже він продовжував додавати новий контент: нових ворогів, костюми, скіни та інші елементи.

Кожне таке оновлення потрібно було знову перевіряти й оптимізувати, щоб гра зберігала стабільний перформанс на консолях.

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

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