Фейковий вибух у Fallout 3, текстури в Minecraft і відсутній фінал The Sinking City. Незвичайні проблеми в геймдеві та їх рішення
Це — третій і завершальний випуск рубрики, в якій ми розповідаємо про незвичайні проблеми, які виникають під час розробки відеоігор, і такі ж дивовижні рішення складних ситуацій. Перша частина традиційно присвячена п’ятьом історіям від західних розробників. Вони стосуються Fallout 3, Minecraft, The New Tetris та інших ігор.
А в другій половині ми поспілкувалися з українськими розробниками. Вони розповіли про цікаві випадки з власного досвіду в геймдеві. Зокрема, про проблеми з реалізацією фіналу у The Sinking City, якого спочатку взагалі не існувало.
Додання коду, щоб зламати систему на власну користь
В одній з ігор студії Cyanogen був доволі звичний для мобільного сегменту елемент монетизації. Користувачі отримували внутрішню валюту за перегляд реклами й, відповідно, збільшували дохід від продукту. Проте вже після релізу проєкту розробники знайшли прикрий баг. Запити на відтворення маркетингових відео не надходили належним чином. Фактично показувався лише один ролик за сеанс.
Cyanogen втрачала потенційний дохід, тому почала швидко шукати рішення. Як розповів тодішній CEO Ліор Таль, гра компанії використовувала серверну інфраструктуру для індивідуальних дій, які стосуються різних сценаріїв. Це потрібно було для подальшого розширення та підтримки проєкту. Система працювала на основі оцінки правил, виконуючи заздалегідь визначені дії, якщо вони є істинними (true).
Оцінювання відбувалося на основі логіки відбиття. Наприклад, якщо правило визначене як VideoAds.IsVideoAvailable = true, то воно викличе аналогічну властивість за допомогою відбиття і виконає дію. Проте остання теж повинна бути true, тобто істинною.
Розробники знайшли спосіб зламати власну ж систему, щоб отримати необхідний результат і нічого не зруйнувати. Вони додали правило VideoAds.RefreshVideos = true, яке ніколи не оцінювалося як істинне. В результаті його дія теж не виконувалася. Однак правило викликало код, який оновлював ролики в рекламі. По суті, систему звели до механізму віддаленого виконання коду. І це спрацювало.
Обман з вибухом у Fallout 3
Розробка Fallout 3 та доповнень до гри була переповнена проблемами та нестандартними рішеннями. Напевне, всі знають історію про вагон потяга з DLC Broken Steel, який виявився шоломом. Розробники не могли додати повноцінний транспорт в рушій Gamebryo, тому створили імітацію за допомогою величезного головного вбрання, насадженого на модель персонажа. Проте колишній розробник з Bethesda Game Studios Нейт Пуркіпайл поділився менш відомою, але такою ж цікавою історією.
В доповнені Point Lookout був фрагмент з вибухом маєтку. Щоб реалізувати його, розробникам потрібно було виконати дію на великій дистанції від гравця. Але на заваді знову стала специфіка Gamebryo. Рушій не підтримував таку можливість і відображав все оточення вдалині як статичні об’єкти. Проте фахівці Bethesda все ж знайшли хитре рішення. Вони перепрофілювали систему, яка використовувалася для підриву Мегатони в основній грі.
Як пояснив Пуркіпайл, маєтку в Point Lookout потрібно було присвоїти інший тип об’єктів «віддаленого вибуху» у порівнянні з містом, знищеним у Fallout 3. Інакше будинок завжди б стояв на своєму місці, коли гравець знаходився на дистанції. Розробники придумали обхідний шлях для розв’язання проблеми. Вони створили механізм вимкнення звичайної версії маєтку та підміни його на модель з декораціями вибуху. Тобто в грі активувалася фальшива варіація маєтку з потрібними ефектами.
За словами Пуркіпайла, у 2009 році Bethesda була відносно невеликою студією. Основна частина розробників тоді працювала над Skyrim, а творцям Point Lookout не вистачало ресурсів. Саме тому доводилося застосувати незвичайні методи для таких же нестандартних проблем.
Герой осліп через програміста
Користувач під псевдонімом DTrejo поділився історією з університетських часів. В його навчальному закладі декілька студентів об’єдналися в команду, щоб створити шутер від першої особи на базі Flash. Та через брак досвіду вони стикнулися з дивною проблемою.
Програміст з колективу чомусь вирішив не додавати перевірку на зіткнення персонажа зі стіною, щоб таким чином дозволяти йому рухатися в певному напрямку. Молодий розробник пішов зворотним шляхом і додав перевірку на наявність стіни. Якщо вона є на шляху, то протагоністу дозволялося пересуватися паралельно перешкоді.
Через такий хитромудрий код в шутері виникла нетипова помилка. На перехрестях головний герой не міг перетинати дорогу й рухатися прямо. Він повертав або наліво, або направо. Команда не знала, як виправити баг, а дедлайн тим часом добігав кінця.
Ситуацію врятував сценарист. Він попросив художника створити анімацію рук, які торкаються стін. А в сюжеті автор прописав, що протагоніст — сліпий, і тому орієнтується за взаємодією з оточенням.
Порятунок від шістнадцяткового редактора
Студія Other Ocean Interactive працювала над версією Minecraft для сімейства консолей 3DS. Команда швидко стикнулася з браком пам’яті й вирішила вдатися до експериментів з текстурами. Їхній внутрішній формат на портативній приставці Nintendo виявився доволі нестандартним. Він заснований на тайлах, організованих у зигзагоподібному вигляді, які на найвищому рівні трансформуються в лінійну структуру.
Ніхто з Other Ocean не мав достатніх знань, щоб написати утиліту для перетворення формату. Nintendo надала власну програму для цієї цілі, та у неї була окрема проблема. Інструмент експортував зображення лише у «пакункових» файлах. Останні потрібно було обробляти та завантажувати під час виконання, використовуючи бібліотеки Nintendo. Для розробників такий підхід виявився надто трудомістким.
Проте лише цей шлях дозволяв отримати стиснуті зображення у форматі, який вимагала 3DS. Тоді програміст Other Ocean Кіт Кайзершот взявся за шістнадцятковий редактор. Він завантажував в утиліту Nintendo зображення різних розмірів та форматів, спостерігаючи за змінами в тайтлах файлів. Таким чином фахівець знайшов достатньо полів, щоб витягнути потрібні дані.
На основі отриманої інформації Кайзершот написав окрему утиліту. Вона вилучала необроблені дані з «пакункових» файлів Nintendo. А далі за допомогою пакетного скрипта розробник застосував цей процес до потрібних текстур. Таким чином вдалося їх стиснути без прямого застосування стандартного методу Nintendo.
Як жарт допоміг розв’язати проблему у The New Tetris
Анонімний розробник розповів про те, як був тестувальником The New Tetris для Nintendo 64. У кожній з версій він знаходив надокучливий баг, який творцям з H2O Entertainment та Blue Planet Software ніяк не вдавалося виправити. Вони постійно присилали свіжі збірки й запевняли, що впоралися з помилкою. Однак тестувальник щоразу її відтворював.
Баг полягав у виведенні на екран скидання регістрів перед завершенням сесії. Позбавитися від нього можна було лише за допомогою перезавантаження консолі. Навіть кнопка Reset не діяла.
Коли почав наближатися дедлайн, проблема стала надзвичайно актуальною. H2O Entertainment та Blue Planet Software потрібно було відправити гру Nintendo, яка тестувала та схвалювала всі проєкти сторонніх розробників для своєї консолі. З вильотами через критичні баги розробники впоралися, проте помилка з регістрами лишилися.
У The New Tetris також було декілька секретних кодів. Вони застосовувалися для відкриття різноманітних предметів. Якось тестувальник пожартував, що розробникам потрібно просто замінити екран зі скиданням регістрів на надпис: «Вітаємо! Ви знайшли секретний код! Вимкніть і знову увімкніть консоль, а потім введіть ім’я користувача HALUCI». Саме так студії й зробили. Невимушений жарт перетворився на рішення, під яким приховали серйозний баг.
У наступній частині статті присутні розповіді українських розробників. Троє спікерів описали цікаві проблеми, з якими стикалися у своїй кар’єри, та шляхи їх вирішення. Зокрема, можна дізнатися про незвичайне створення фіналу у The Sinking City.
«Ми мали за два тижні створити повноцінний фінал The Sinking City в надскладних умовах». Святослав Демченко, Senior Quest Designer у Rebel Wolves
Розповім про часи, коли я працював у Frogwares. Тоді у нас трапилася цікава історія зі створенням фіналу The Sinking City. З погляду дизайну квестів, виробництво було доволі прямолінійним. Наративні дизайнери готували загальний сюжет і разом з дизайнерами квестів працювали над втіленням цієї історії в грі.
Оповідь у The Sinking City містить певну кількість основних завдань та обʼємний перелік додаткових доручень. Сценарій кожного сюжетного квесту було чітко прописано, а самі місії розділено між дизайнерами за нумерацією — вступна, перша, друга тощо. В цілому завдання створювалася за традиціями серії про Шерлока Голмса. Всі квести були самодостатніми, щоб за потреби їх вдалося перетасувати в загальному переліку.
В певний момент це зіграло з нами злий жарт, адже через подібну структуру сильно губилася центральна сюжетна лінія. Гра перетворювалася на концепцію «послуга за послугу», як ми її охрестили всередині команди.
Ближче до кінця розробки ми зібралися командою наративників та дизайнерів і вже остаточно розставили квести на місця. Ми також додали моменти більш «елегантної» склейки між завданнями, щоб історія відчувалася ціліснішою. На той час вже не було змоги вносити багато правок, тому сильно вплинути на сюжет не вдалося б. І хоча ця робота не пройшла дарма, трішки пізніше виплила справжня проблема, пов’язана з підходом до створення квестів.
Тоді лишався місяць до дедлайну завершення основного кістяка розробки. Команда вже фактично переходила до виправлення багів, а я якраз закінчив ітерацію останнього зі своїх квестів. Він зовсім недавно перейшов під мою опіку від іншого дизайнера й був фінальним у новій структурі. Постійно проходячи його, я відчував, що мені щось не дає спокою. І через певний час зрозумів причину цього.
Останній квест, як і будь-яка інша справа в The Sinking City, закінчувався логічним розв’язанням основного питання/проблеми. І це був фінал квесту, та аж ніяк не всієї гри. Побігши спілкуватись з менеджментом та іншими дизайнерами, я доволі швидко з’ясував, що завершення гри навіть не стояло в наших задачах.
Тобто ми мали загальний план і бачення кінцівки, та фактично воно ніколи не було інтегровано в якийсь із квестів та заплановано до виробництва. Всі настільки звикли до «модульної» системи місій і були так завантажені під кінець розробки, що навіть не подумали про це.
Отож, ми мали за два тижні створити повноцінний фінал The Sinking City в надскладних умовах. Нам не можна було додавати жодного нового слова тексту, бо тоді все вже написали, вичитали, озвучили й місцями навіть переклали. Те ж стосується реалізації якихось фіч чи босів.
Я взяв цю задачу на себе, і ми разом з наративницею, яка була моїм партнером в роботі над фінальним квестом, пішли аналізувати тисячі озвучених реплік в сценарії. Нам потрібно було знайти фрази, які ми могли б вирізати та повторно використати для фіналу. Таким методом народився останній рівень The Sinking City — фантасмагоричний ланцюжок зі сцен, де герой переживає усі рішення та події з попередніх квестів, а також робить фінальний вибір щодо долі міста.
Якщо ретельно прислухатися до фраз, то можна помітити, що всі вони взяті з попередніх квестів. А оточення створено з вирізаних частин інших локацій. Це був не найкращий фінал, який могла б мати ця гра. Але він найкращий з тих, які ми могли тоді собі дозволити в умовах обмеженого бюджету та часу.
«Більшість моїх ігор будувалися і будуються на системах, які доволі тонко налаштовуються». Андрій Бичковський, український інді-розробник, творець Farlanders та Undervault
Доволі довгий час моя команда працювала за принципом, коли художник завантажує оновлення графіки у Dropbox, а я потім інтегрую його в гру. Це дуже сповільнювало процес розробки й відривало мене від важливіших задач. Тому в результаті ми вирішили, що художник буде завантажувати графіку напряму до репозиторію.
Цей принцип я використовую і з 3D-моделями, і зі звуками. Кожен з команди має максимум автономності й самостійно вносить зміни до проєкту в межах своєї зони відповідальності.
Більшість моїх ігор будувалися і будуються на системах, які доволі тонко налаштовуються і мають багато параметрів. До прикладу, у Farlanders одних лише видів будівель реалізовано 55 одиниць, і кожна з них має близько 15 налаштувань. Раніше я компонував усі ці дані в спеціальних файлах Unity. У Farlanders при такому підході кожна споруда мала б свій файл.
Це призвело до того, що я сформував окрему таблицю, де рахував баланс. А потім руками переносив все це в файли Unity. Процес був дуже повільним і до того ж ненадійним через ризик помилки.
Рішенням стало перенесення всіх даних щодо налаштувань гри у Google-таблицю і їхня синхронізація з індивідуальними файлами Unity. Для цього вже існувало готове рішення Google Sheets на Unity Asset Store, яке гарно працювало після невеликої кількості доопрацювань. Зараз воно вже недоступне, хоча, ймовірно, є аналоги.
«Гра стала настільки вимогливою до ресурсів, що Unity зависав та падав». Команда студії Triomatica Games
Boxville була нашою першою грою, тому під час виробництва ми припустилися усіх можливих помилок, які роблять творці-дебютанти. За своєю суттю проєкт став поєднанням гри та мультфільму. Вся концепція побудована на ручній графіці та покадрових анімаціях. Гра містить більше як 23 тисячі кадрів анімації — це понад пів години мультиплікаційної стрічки.
Спочатку через брак досвіду ми вирішили виконувати всю графіку в 4К, а анімації — в кадровій частоті 30 кадрів/сек. Коли було завершено приблизно третину гри, з’ясувалося, що далі ми не можемо рухатися цим шляхом. Гра стала настільки вимогливою до ресурсів, що Unity зависав та падав. Тому було вирішено перейти на формат графіки Full HD та анімації з кадровою частотою 12 кадрів/сек. Це покращило ситуацію на ПК, але ми ще не знали, що нас очікує у версіях для мобільних пристроїв.
Далі йде розповідь програміста Triomatica Games
На початку створення своєї першої гри буває важко уявити її реальний масштаб. Саме з цією проблемою ми стикнулися при роботі над Boxville. Коли минула половина виробництва, з’ясувалося, що гра потребує набагато більше пам’яті, ніж дозволено на мобільних платформах.
Для розв’язання цієї проблеми ми скористалися прикладом старіших ігор, в яких необхідно було керувати пам’яттю через значний брак ресурсів. В результаті я створив систему динамічного завантаження/вивантаження ресурсів на вимогу ігрового процесу за допомогою механізму Addressables. Це дало можливість легко масштабувати асети для мобільних пристроїв і навіть створити ще більше ігрового контенту без шкоди загальній продуктивності.
Система ручного управління пам’яттю дозволила працювати з ігровими ресурсами за принципом черги. На проєкті встановлюється необхідний ліміт ресурсів. При його досягненні вивантажуються асети, які були завантажені раніше і наразі не використовуються, щоб звільнити місце для нових. Розв’язання проблеми з браком пам’яті допомогло нам створити систему планування для майбутніх ігор. На старті ми визначаємо масштаби проєкту та розподіляємо усі ресурси на окремі блоки аcетів.
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів