Оптимізація аудіо для мобільних ігор. Виклики та рішення

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

Мене звати Ілля Гоголєв, я Audio Producer у Plarium. Уже понад 10 років я займаюся звуковим супроводом мобільних ігор, синематиків, телевізійної та інтернет-реклами. Серед найвідоміших проєктів Plarium, які ми разом з аудіокомандою розробляємо й підтримуємо, — RAID: Shadow Legends і Mech Arena. У цьому матеріалі я хочу розказати про те, як оптимізувати аудіоконтент для мобільної гри так, щоб не нашкодити ні проєкту, ні гравцям. Матеріал буде корисним як саунд-дизайнерам, що працюють у командах або на аутсорсі, так і інді-розробникам, які опікуються звуком власноруч.

Чому варто оптимізувати звук для мобільних ігор

Телефон не ігрова консоль. Він не створений безпосередньо для ігор як Sony PlayStation чи Xbox. І, як розробники, ми змушені підлаштовуватися не просто під конкретний мобільний пристрій, а під величезний «зоопарк» девайсів. Неоптимізовані під телефон ігри стають причиною негативного ігрового досвіду і, як наслідок, втрати користувачів.

Чому гравці отримують негативний досвід і йдуть?

• Довгий час очікування завантаження гри.
• Гра забагато важить.
• Гра гальмує або вилітає.
• Візуальна складова та звук не синхронізовані.
• Звук у грі занадто тихий чи голосний (дратує і не допомагає грати).

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

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

Джерело: стаття дизайнера Зандера Халме Unity Audio Import Optimisation

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

Виклик: обмеження розміру білда

Ліміт на розмір стартового білда від App Store і Google Play дуже вплинув на модель просування та розроблення мобільних ігор. Зараз в обох магазинів він становить 200 МБ. У статті про розміри мобільних застосунків і стратегію оптимізації для App Store маркетолог Джонатан Фішман наводить такі результати дослідження:

«Від 15 до 25 % юзерів відмовляються від наміру завантажити застосунок, коли бачать попередження магазину про розмір білда понад 200 МБ».

Додам, що, коли йдеться про десятки й сотні тисяч гравців, навіть значно менший відсоток відмови може стати для компанії-розробника приводом оптимізувати гру й підігнати білд під 200 МБ.

Рішення

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

Ієрархія всіх об’єктів, що звучать у грі в конкретний момент, у профайлері Audiokinetic Wwise. Тут ми слідкуємо за тим, як обсяг і вага ресурсів впливають на спроможності пристрою, що відтворює гру. Джерело: audiokinetic.com

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

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

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

Виклик: стиснення ресурсів

Оптимізувати розмір ресурсів можна за:

• частотою дискретизації (Sample Rate);
• форматом та якістю (Quality).

Не буду занадто занурюватися в історію, вам важливо лише зрозуміти, як телефон працює із Sample Rate. Два найпопулярніші стандарти частоти дискретизації в медіа — 44 100 Гц і 48 000 Гц — давно існують паралельно, але походять із різних джерел:

Формат 44 100 Гц пов’язаний із компакт-дисками, 48 000 Гц — з кіно й кабельним телебаченням. Обидва формати мали колосальний вплив на подальший розвиток девайсів і сервісів. Смартфон — як спадкоємець MP3-плеєрів — довгий час працював саме на частоті 44 100 Гц. За часів випуску iPhone 6S з’явився Netflix, YouTube, інші стримінгові сервіси й великі ігри, які остаточно захопили телефони своїм контентом у 48 000 Гц.

Коли телефон працює на нативній частоті, а певні застосунки змушують його програвати файли іншої, девайс має «на льоту» конвертувати частоту файлів, хоча цього й не помітиш на слух. Цей процес, залежно від того, знижено частоту до робочої чи підвищено, має назву «даунсемплінг» або «апсемплінг». Навіть якщо вдалося зекономити місце на девайсі, знизивши частоту асетів, ви навантажили процесор. Саме тому телефони масово перевели на частоту 48 000 Гц: це дає змогу напряму працювати в нативній частоті.

Рішення

Бажано лишати весь контент на частоті 48 000 Гц — так радить ресурс Google Developers, — бо саме на ній працює абсолютна більшість телефонів. Але це можливо лише в ідеальному світі, адже, найімовірніше, без стискання не обійтися.

Якщо ви хочете зекономити місце й стиснути асети за якістю через частоту дискретизації, почніть із 24 000 Гц або 16 000 Гц. Бо помножити частоту на 2 чи на 3 — найпростіша математична операція для телефона, який виконуватиме апсемплінг ресурсів. Перші кандидати на екстремальне стискання — войсовери, ембіент та інші звуки, де шумова складова превалює над тональною. Але уважно слухайте результат, щоб виявити артефакти.

Чи можна оминути ці поради?

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

Формати для стискання аудіоасетів, які ми найчастіше використовуємо

• ADPCM — стискає асети лінійно. Ваш файл зменшується в три рази. Процес розпакування дуже швидкий, під час нього не використовуються ресурси процесора. Цей формат чудово підійде для UI, коли вам, наприклад, потрібна висока швидкість реакції на натискання кнопки.
• Vorbis — дає змогу дуже сильно стискати файли, але натомість використовує більше ресурсів процесора на розпакування. Треба уважно слухати, чи відповідає результат, який ви чуєте, завданню, тобто чи встигає ваш звук розпакуватися. У цьому інструменті доступна шкала якості (Quality), але важливо розуміти нюанс: параметр Quality factor визначає не якість самого файлу, який ви отримаєте після стискання, а якість інструменту стиснення. Наприклад, Unity визначає це як шкалу від 1 до 100, а Wwise — як логарифмічну формулу. Саме тому якість може бути як у значенні 0, так і в значенні —1.

Послухайте приклад VO з нещодавнього релізу в RAID: Shadow Legends:

У прикладі:

• похідний файл: 48 кГц PCM WAV — 1 МБ;
• стиснутий за Sample Rate файл: 24 кГц PCM WAV — 500 кБ;
• стиснутий за Quality файл із додаванням музики (так, як це почують): OGG Vorbis (~q. 0,4) — 100 кБ.

Звісно, якщо знехтувати згаданими раніше порадами Google Developers, то можна було б стиснути файл ще більше. Можна стиснути й до 20 кГц або зробити меншу якість у Vorbis. Але, по-перше, ви можете робити це, поки не почуєте артефакти. По-друге, зважайте на пріоритет аудіконтенту й те, наскільки він для вас важливий.

Виклик: система пріоритетів RAM

У телефона є система пріоритетів для всіх операцій. Багато пам’яті зарезервовано під процеси, які телефон вважає умовно важливішими за вашу гру. Наприклад, екстрені сповіщення, дзвінки, застосунки, що стежать за здоров’ям, тощо. До того ж користувачі майже постійно використовують декілька застосунків паралельно й можуть одночасно дивитися Netflix, завантажувати файли та користуватися месенджерами.

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

Отже, ви маєте вписуватися в якісь ліміти. Інакше телефон просто намагатиметься крашнути все, що менше за пріоритетом.

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

• використання більшого обсягу пам’яті, ніж потрібно = погіршення FPS і перетворення гри на «слайд-шоу»;
• використання завеликої кількості ресурсів у пам’яті (наприклад, якщо не контролювати завантаження та вивантаження саундбанків) = краш за лімітами, через що гравці дратуються, втрачають прогрес і йдуть.

Рішення

Визначте цільовий девайс і тестуйте саме на ньому.

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

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

Будуйте гнучку систему тригерів саундбанків. Контролюйте умови, за яких саундбанки завантажуються та зникають. Це бажано робити саме вручну. Гарна практика — використовувати middleware, як-от Audiokinetic Wwise. На відміну від Unity Audio, де все трохи «під капотом», у Wwise ви контролюєте завантаження буквально кожного звуку і його життєвий цикл протягом гри.

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

Виклик: обмежена кількість фізичних голосів

Мобільний телефон обмежений в одночасних потоках відтворення звуків. Це має назву «фізичні голоси», і вони досить жорстко лімітовані. У статті How to get a hold on your voices наводиться обмеження в 50–100 голосів. За досвідом нашої команди, це дуже оптимістична оцінка.

Ми вважаємо, що зона ризику з’являється вже в діапазоні 20–30 одночасних голосів. І це найпростіший спосіб зловити краш зі звуку як на Android, так і на iOS.

Уявіть, що ви робите гру match-3 з кількома об’єктами в сцені. Наприклад, це ананас, що вибухає. Ви «навішуєте» один звук на один асет, проте в наступному рівні маєте вже 15 ананасів. Вам потрібно лімітувати гучність і кількість об’єктів. Крім того, що 15 ананасів — це занадто голосно, це ще й навантаження на процесор.

Рішення

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

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

Ієрархія звуків у профайлері Audiokinetic Wwise має вигляд своєрідної черги із живих подій, які «пробивають собі шлях» до слухача

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

Установлення лімітів за платформами та на асет

Тестуйте все на цільових девайсах.

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

Виклик: обмеженість за динамічним діапазоном

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

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

Рішення

Дотримуйтеся рекомендації Sony (—18 LUFS) і Google Developers (—16 LUFS) щодо рівня міксу. Проте це просто загальна порада. На відміну від PlayStation або Xbox ні App Store, ні Google Play не мають сертифікації за гучністю. Якщо ви не впишетеся в запропоновані стандарти, вас за це не завернуть на валідації.

Робіть два мікси, під навушники й під динамік, з динамічною зміною стану. Навіть Unity має штатні засоби для цього — Mixer Snapshots. У Wwise можна зробити окремий State. Зробіть темплейт з окремими налаштуваннями для стану, коли гравець використовує динамік, і додайте тригер на зміну стану, коли він під’єднує або вимикає навушники.

Вимірюйте мікси ігрових сесій, щоб сформувати хоча б приблизне уявлення про те, наскільки далеко від запропонованих стандартів ви перебуваєте. Записуйте відео реальних ігрових сесій, бажано від 30–40 хвилин, і робіть заміри безкоштовним плагіном, як-от Youlean Loudness Meter. Це дасть вам змогу зрозуміти, наскільки об’єктивно гучна чи тиха ваша гра.

Висновок

Усі технічні перепони, які я описав вище, не мають загубити вашу гру з креативного погляду. Якщо ви на 100 % впевнені, що результат відповідає креативному задуму, то відхилення від стандартів допустиме. А ще пам’ятайте про кола однодумців, де вам завжди можуть допомогти порадою. Професійні спільноти й потрібні для обміну досвідом, навчання та нетворкінгу. Однією з таких спільнот є Noise Shelter — українське ком’юніті аудіодизайнерів у Discord, що наразі об’єднує понад 100 фахівців.

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

Буду радий почути ваші думки й питання в коментарях. Дякую за увагу!

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