Гра крашилась через перевищення ліміту пам’яті навіть на Xbox. Труднощі портування сітібілдера Fabledom на консолі

Вітаю! Я Володимир Мельничук, Unity Developer у Pingle Game Studio. Нещодавно ми завершили роботу над портуванням Fabledom. Портинг city builder-проєктів на консолі є складним завданням, оскільки така гра не має чіткого завершення і може тривати безкінечно, а пам’ять консолей обмежена.

У даному блозі я і мій колега Technical Artist Данило Онуфрієнко хочемо розповісти про виклики, з якими ми зіткнулися під час портування, і як нам вдалося їх подолати.

Ми портували гру, яка ще не була завершена

У геймдеві часто трапляється, що гру створюють тільки під одну платформу, як-от ПК. Наш випадок не став винятком.

Оригінальні розробники Fabledom не передбачали, що гру колись потрібно буде адаптувати для консолей. Для нас це вилилось у наступний виклик.

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

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

Це рішення допомогло спростити управління і зробити інтерфейс зручнішим для використання на консолі.

Ще більше труднощів додавав той факт, що ми портували гру, яка ще не була завершена. Під час роботи з’являлися нові функції, об’єкти та елементи інтерфейсу. Наш UI/UX дизайнер особливо відчув цей виклик, адже йому доводилося розробляти іконки та вікна, враховуючи, що згодом в грі з’явиться новий UI. А, можливо, й не з’явиться.

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

Ця проблема була від самого початку проєкту до його завершення.

Розповідаючи про портинг сітібілдера на консолі, неможливо оминути питання пам’яті

На відміну від ПК, розмір ігрових сейвів на консолях обмежений. Особливо це стосується Switch — обсяг пам’яті для збережень там дуже малий, і записати більше 60 МБ неможливо. Без оптимізації ми б не змогли створити більше одного слота для збереження. А без вирішення цієї проблеми ми б не пройшли сертифікацію.

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

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

Також нам довелося виправити безліч витоків пам’яті (memory leak), які на ПК-версії розробники могли ігнорувати, але на консолях це призводило до сильно неконтрольованого збільшення використання пам’яті, після чого гра просто крашилася.

Портування city builder симуляторів на консолі часто взагалі уникають

Одним із ключових завдань під час портування була оптимізація гри. Оскільки архітектура розроблялася під ПК, використання ресурсів пам’яті та процесора виявилося надмірним для інших платформ. Гра крашилась через перевищення ліміту пам’яті навіть на Xbox, не кажучи вже про Switch.

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

Також ми переписували алгоритми генерації карти, щоб виділення пам’яті було якомога меншим. Нам прийшлося переробити все: від землі, води, трави до туману.

Далі даю слово моєму колезі Данилу Онуфрієнко.

Як нам вдалося зменшити навантаження на графічний процесор з 30-70 мс до потрібних 16-33 мс. Данило Онуфрієнко Technical Artist

Спочатку ми стикнулися з серйозними проблемами перевантаження пам’яті, яку потрібно було негайно скоротити, адже надлишок даних не дозволив би взагалі запустити гру. Ми повністю переписали математичні розрахунки шейдерів, зменшивши їхнє споживання пам’яті приблизно з 800 МБ до 30 МБ. Також ми оптимізували розміри й канали текстур та атласів.

Не обійшли увагою й роботу з мешами: наприклад, туман навколо ігрової області був перероблений на одну невелику частину, яка дублювалася, замість використання великої процедурно згенерованої моделі. Важливим був кожен мегабайт, і ці рішення допомогли зберегти візуальну якість оригіналу та забезпечити запуск гри на пристроях із доступною пам’яттю 2.8 ГБ.

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

Оптимізовані шейдери значно розвантажили GPU. Ми також налаштували нові постобробки, оновили рендер-паси та рендер-фічі, розбили террейн і воду на чанки та застосували інші методи оптимізації.

Попри те, що в грі присутня велика кількість будівель, і при повороті камери гравець може одночасно бачити десятки або навіть сотні будинків, ми вирішили оптимізувати їхню геометрію. Для цього ми створили систему, яка фотографувала кожну будівлю з різних ракурсів та зберігала ці зображення в атласі. Шейдер перемикав потрібні частини атласу залежно від кута камери, створюючи ілюзію об’єму, хоча насправді це було плоске зображення. Ця система використовувалася як останній рівень деталізації (LOD) для моделей.

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

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

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

Завдяки цим оптимізаціям потреба в пам’яті консолі знизилася з 4,7 ГБ до 2,6 ГБ, а навантаження на графічний процесор зменшилося з 30-70 мс до потрібних 16-33 мс залежно від консолі.

Всі наші дії: робота з пам’яттю, розробка нового інтерфейсу, оптимізація ресурсів — були направлені на один результат, вихід Fabledom на PlayStation 5, Nintendo Switch, Xbox One, Xbox Series.

Ми пройшли всі необхідні сертифікації, забезпечили стабільні 60fps 4K на PS5, Xbox Series X та 30fps на Nintendo Switch, швидку реакцію гри для користувачів, покращили керування пам’яттю та розподіл ресурсів — загалом створили оптимізовану гру, що ефективно працює навіть на слабких девайсах.

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