Підступна бджола в Skyrim, рятівні білки та українська локалізація Cyberpunk 2077. Незвичайні проблеми, які виникали при розробці ігор

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

В рамках нової рубрики ми вирішили збирати найцікавіші та найнезвичайніші проблеми, які можуть виникати на шляху до релізу проєкту. Для цього наша редакція опитала українських розробників, а також відшукала приклади з популярних хітів — Dragon Age: Inquisition, The Elder Scrolls V: Skyrim, Titan Quest та інших.

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

Обман з конем

Шведська студія DICE створювала рушій Frostbite для серії Battlefield, тобто технологія заточувалася під розробку шутерів від першої особи. Та як стало відомо з журналістських розслідувань, ще на початку 2010-х Electronic Arts почала підштовхувати внутрішні студії до використання Frostbite.

Очевидно, що таким чином видавництво хотіло зекономити на відрахуваннях стороннім компаніям за використання їхніх рушіїв, зокрема Epic Games. EA не зважала на жанр та специфіку проєкту, тому поступово на Frostbite перейшли всі відомі серії компанії, включаючи Dragon Age. BioWare довелося добряче попрацювати, щоб адаптувати технологію під створення екшен-RPG з просторими локаціями та видом від третьої особи.

Загалом студія впоралася, й третя частина серії з підзаголовком Inquisition вийшла гарною грою. Однак проблем в процесі розробки вистачало. Одна з них була пов’язана з конями. Як розповів креативний директор Dragon Age Dreadwolf та ветеран BioWare Джон Еплер, в Inquisition немає різниці між звичайним бігом на їздовій тварині та спринтом. Розробники лиш зробили видимість прискорення за допомогою декількох візуальних ефектів. Вони віддалили камеру та додали імітацію швидкісних ліній вітру з боків коня.

«Просто, щоб бути супер зрозумілим: їзда на коні швидша, ніж пішки. Але різниці між звичайним кінним бігом і кінним спринтом не існує, за винятком того, що це виглядає швидшим», — розповів Еплер.

За словами директора, на таку хитрість довелося піти якраз через Frostbite. Розробники могли зробити так, щоб кінь по-справжньому прискорювався під час спринту. Однак рушій не міг впоратися з високою швидкістю пересування, тому не встигав підвантажувати оточення. Через це текстури з’являлися прямо на ходу, а розробникам не вдалося це виправити. Зрештою вирішили пожертвувати саме спринтом.

Могутня бджола

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

Знаючи про технічний стан Skyrim на виході, можна тільки уявити, скільки багів виникало під час розробки. І деякі з них заганяли в глухий кут досвідчених фахівців з Bethesda Game Studios. Про одну з таких помилок розповів колишній Lead Artist у компанії Нейт Пуркіпайл.

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

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

«Був ще один баг, через який бджолу в грі не можна було підняти. Через це деякі зілля не можна було зробити. Цю помилку виправили. Однак тип колізії, раніше накладений на бджолу, не просто не дозволяв її підняти. Він також змушував її зіштовхуватися з речами», — повідомив Пуркіпайл.

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

«Саме тому розробка ігор — це важко. Щоразу, коли ви виправляєте щось одне, ви можете зламати щось інше. Особливо це стосується ігор з відкритим світом. Проте саме взаємодія всіх систем робить їх надзвичайно цікавими», — додав Пуркіпайл.

Віртуозне рішення з білками

Titan Quest — один з найвідоміших послідовників Diablo, який переносить користувачів в антураж грецької міфології. Коли розробка проєкту добігала кінця, в Iron Lore Entertainment стикнулися з вагомою проблемою. У технології квестів та випадкових активностей, створеній для гри, не було можливості відкласти дію після її початку.

До прикладу, коли виникала потреба, щоб тригер події спрацював через декілька секунд після прибуття героя в конкретну точку, то реалізувати це не вдавалося. Механізм додавання цієї затримки не передбачили. В результаті всі дії спрацьовували моментально після подання сигналу.

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

«Врешті-решт він використав білок, яких ми розмістили серед оточення, як таймер анімації, і вони стали механізмом синхронізації за замовчуванням. Він створив невидиму версію білки, яку розміщував на рівнях, де вона була йому потрібна, а потім відраховував час, виходячи з тривалості її анімації в режимі очікування. Завдяки своєму творчому підходу до розв’язання проблеми, його підвищили до дизайнера в наступному проєкті», — розповів Артур Бруно, колишній розробник Titan Quest та засновник Crate Entertainment.

Ліміт пам’яті, про який ніхто не здогадався

У 2D-екшені під назвою Super Time Force є механіка перемотування часу. Після загибелі персонажа користувач може або запустити рівень заново, або повернутися до моменту перед смертю. Як аналоги можна згадати сучасніші Convergence: A League of Legends Story та Iron Danger.

Проєкт вийшов у 2014 році на консолях Microsoft восьмого і сьомого покоління, тобто на Xbox One та Xbox 360. І з версією для старішої платформи виникла серйозна проблема. Через механіку управління часом, Super Time Force наближалася до ліміту пам’яті Xbox 360. Розробникам зі студії Capybara Games доводилося зберігати інформацію про кожен активний об’єкт на всьому шляху перемотування. Це стосувалося персонажів, куль, вибухів, уламків оточення, платформ тощо.

Всі елементи вимагали пам’яті, тому процес налаштування механіки став справжнім викликом для команди. Коли розробники збалансували всі рівні та буфери перемотування, довели їх до ідеального стану, відділ тестування знайшов баг. Як виявилося, якщо протягом двадцяти разів швидко натискати кнопки після запуску рівня, а потім переміщатися назад у часі, то Super Time Force досягала ліміту пам’яті.

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

Проте на цьому проблеми не закінчилися. Невдовзі відділ тестування знайшов ще один баг. Якщо на рівні 199×2 створити надто багато вибухів і заповнити простір уламками, а потім повторити процес двадцять разів, Super Time Force знову досягала ліміту пам’яті. В результаті розробникам довелося піти на чергову хитрість.

«Замість того, щоб міняти баланс у файлах рівнів і розмірах буферів у грі, у нас була простіша ідея: коли ви наближалися до ліміту пам’яті для перемотування, ми просто ставили гру на паузу, а на екрані починала миготіти велика жирна піктограма „низький заряд батареї“, яка граціозно переносила вас у меню вибору рівня», — розповіла Кеннет Йонг, Technical Director у Capybara Games.

Тобто розробники створювали ефект, нібито у користувачів розрядився контролер, і через це Super Time Force зупиняла ігровий процес та вмикала меню вибору локацій. Проте насправді причиною був ліміт пам’яті на Xbox 360. Відділ тестування прийняв таке виправлення, а фахівці Microsoft під час сертифікації проєкту не помітили двох хитрих рішень, тому гра відправилася в реліз.

Короткі історії про цікаві проблеми

Розробник під псевдонімом bazyleeshek розповів, що під час створення своєї першої 3D-гри взагалі не розумів, як працює фізика. Він заблокував позицію гравця у просторі, щоб не виникали проблеми. Після цього фахівець додав декілька поверхів та ліфт для пересування. Той рухав весь віртуальний світ вниз або вверх, тому що головний герой не міг рухатися по вертикалі.

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

Антуан Генрі поділився історією, пов’язаною з розробкою Rayman Raving Rabbids 2 для Nintendo Wii. Дизайн проєкту передбачав певну кількість мініігор. Команда не встигала реалізувати все до заданих термінів, тому пішла на хитрощі. Декілька мініігор скопіювали, змінивши візуальну складову. А в одній гравцям щосекунди нараховували випадкову кількість балів. В правилах до неї написали: «Сконцентруйтеся, щоб набрати більше очок». Після цього користувачі пропонували різні методи, як опанувати цю мінігру.

За словами Джона Розато, Senior Level Designer у People Can Fly, в пролозі Outriders демонструється ліс у вогні. На той момент у команди не було процедурної системи пожеж, тому дизайнер написав скрипт, за яким кожне з 600 дерев загорялося окремо.

Цікаві задачі та проблеми, з якими стикалися українські розробники

Нижче ми поговоримо про досвід українських фахівців з відомих студій — CD Projekt RED, GSC Game World, Digital Extreme та 10 Chambers. Вони розповіли, з якими викликами стикалися під час розробки ігор, та як вдавалося знайти вихід з ситуації.

«Існують баги, які навпаки починають збирати багато позитивних реакцій». Валерій Тарумов, QA Analyst у CD Projekt RED

Я б хотів розповісти не про те, як ми шукали розв’язання якихось проблем, а навпаки, як ми свідомо приймали рішення нічого з ними робити. Наше завдання як QA — це завжди пошук шляхів покращення продукту, а іноді також вирішення нестандартних ситуацій. Більшість з них зводяться до не дуже цікавих змін коду гри або пошуку обхідних шляхів в дизайні. Але не менш цікавими є ситуації, коли краще нічого не робити. Це саме той випадок, коли деякі проблеми стають не багом, а фічею, тому що вони веселі.

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

На противагу ним існують баги, які навпаки починають збирати багато позитивних реакцій від спільноти, тому у деяких випадках ми легітимізуємо такий баг та забороняємо його виправляти. З найпопулярніших прикладів — це низькополігональний голуб з версії The Witcher 3 нового покоління. Він спричинив справжній флешмоб та навіть став предметом косплеїв.

З Cyberpunk 2077 можу навести приклад, коли гравці помітили, що іноді на вулиці з’являються роботи, які, ніби після важкого робочого дня, палять цигарки. Мем побудований на тому, що складне життя в Найт-Сіті не шкодує нікого. Хоч це й було спричинено некоректним використанням зовнішності для міського натовпу й виправлялося простим видаленням актору з анімації, це настільки смішило й пасувало до оточення гри, що виправлення цього багу позбавило б гравців можливості поспівчувати тяжкій долі нещасного андроїда, замученого понаднормовими годинами праці на корпорацію.

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

«У вас десять різних голів і зрозуміло, що треба десять різних мешів». Вадим Терновой, Game Designer у GSC Game World

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

Рішення. Щоб мінімізувати час, коли гравці не можуть грати, можна поділити оновлення на клієнтську та серверну частини. Наприклад, якщо це оновлення якихось даних — зміна дизайну кнопки в меню, зміна текстур дерева на рівні тощо, — які зберігає тільки клієнт, то це можна робити без зупинки серверів і оновити тільки клієнт гри в будь-який час. Якщо це дані, як от зміна розташування об’єкта дерева, нові локації, параметри зброї тощо, то це також і серверні дані, тому потрібно оновлювати як клієнт, так і сервер. Доводиться зупиняти гравців і змушувати їх оновлюватися, тобто проводити обслуговування.

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

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

Рішення. Підбирати гравців за певними параметрами, наприклад, ELO. Ці параметри краще розділяти між режимами гри, типами матчів, типами взаємодії тощо. Але можна зробити також окремий режим, наприклад, присвячений певній події, в якому все буде залежати тільки від конкретного гравця, бо режим буде не командний, а однокористувацький. Так ми робили в Survaruim: новорічний івент, де режим і локація були створені схожим чином. Гравці отримували те, що хотіли — переможець тільки один, і все залежить від самого гравця, а не його команди

Проблема № 3. Під час розробки нового ігрового предмета не виходить зробити його універсальним для всіх персонажів.

Вирішення. Зробити один предмет, але об’єкт (меш) повинен трішки міняти форму залежно від персонажа. Наприклад, ви робите захисну маску в грі. У вас десять різних голів і зрозуміло, що треба десять різних мешів — по одному під кожну голову. Замовляєте функціонал, де вказуєте, що під цю голову — ось цей меш, а під цю — інший. Результат виходить такий, що гравець бачить лише один предмет в інвентарі, де модель маски автоматично змінюється під обраного персонажа.

«Як порівняти свій проєкт з іншими проєктами?» Андрій Цілицький, Game Designer у 10 Chambers та автор Telegram-каналу «Конспект геймдизайнера»

Одного разу виникла потреба оцінити розмір різних типів зброї на екрані в шутері від першої особи. Як порівняти між собою зброю одного типу і майже одного розміру? Як порівняти свій проєкт з іншими проєктами? Особливо складно порівнювати між собою стилістично різні FPS-ігри, наприклад, Prey, Redfall та Hunt: Showdown.

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

• Вам потрібен знімок екрана з проєкту, який ви хочете проаналізувати. Це може бути зброя в статиці, або ж навіть різні етапи анімації зброї, як от перезаряджання чи огляд зброї.
• Завантажуєте знімок в програму для візуального редагування. Я використовував Paint, але, думаю, інші програми також можуть підійти.
• Виділяєте зброю за допомогою ласо чи аналогічного інструмента.
• Дивитеся на те, скільки пікселів знаходяться у виділеній зоні.
• Дивитеся на розмір скриншота в пікселях і рахуєте загальну кількість пікселів на картинці.
• Рахуєте скільки у відсотковому співвідношенні ваша виділена зона займає місця на поточній картинці.

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

«Це був доволі монструозний скрипт». Максим Тішаков, Senior Level Designer у Digital Extremes

Думаю не буде таємницею, що деякі трейлери зараз роблять, навіть коли гри ще й немає, особливо для дочасного доступу в Steam. Як правило, це потрібно, щоб перевірити зацікавленість аудиторії концептом на ранніх стадіях.

Коли я вже деякий час працював в індустрії, і тільки з’явився Steam Greenlight, ми намагалися зрозуміти, як за максимально короткий термін на тій базі, що в нас була, зробити щось нове і цікаве, що можна потенційно продати як нову гру. Щоб не витрачати надто багато ресурсів, ми створили новий режим де трохи змінили ігровий процес.

З наявних асетів зібрали нові композиційні блоки, зробили ефекти, накинули контурне тонування та записали зрежисований «ігровий процес». Потім усе доробляли у відеоредакторі: інтерфейс, звук, навіть трохи візуальний стиль. І завдяки правильно записаному ігроладу, який продумали заздалегідь, вдалося створити цю симуляцію нового ігрового продукту. Так і пішли в Greenlight.

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

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

З погляду ігрового процесу, все працювало, як задумувалося. Але з технічного боку — це були кілька продубльованих будинків за межами рівня і виявилося, що ми не можемо таке підтримувати. Ідею довелося викинути, коли встановили всі пайплайни. Тож не вдалося зробити своє метро в стилі Fallout 3 🙂.

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

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

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

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

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

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