Освітлення мобільної гри: де ламається кадр і чому
Освітлення мобільної гри майже ніколи не ламається «в моменті» — воно деградує поступово, і перший сигнал зазвичай надходить із відгуків: «гріється», «гальмує на середньому телефоні», «в підземеллі все біле».
На цей момент у проєкті вже накопичився набір джерел світла, які ніхто не звів у єдину політику: динамічні ліхтарі, тіні від героя, ефекти здібностей, емісія матеріалів.
Кожен окремо виглядає нешкідливо, разом вони дають просідання продуктивності освітлення саме на слабкому залізі — тому самому, де сидить основна аудиторія.
Розберімо, де зазвичай рветься. Провали кадрів на масових пристроях майже завжди пов'язані не з кількістю джерел, а з їхнім перерахунком на кожен піксель: десяток динамічних ліхтарів у сцені множиться на перекриття й затінення, і бюджет кадру виходить за відведений час.
Артефакти тіней проявляються інакше — рвані краї на межах карти тіней, мерехтіння під час руху камери, «сходинки» на дальніх об'єктах. Це не косметика: гравець читає такі дефекти як недбалість і йде раніше, ніж доходить до платного контенту.
Окрема історія — пересвіти та енергоспоживання.
Сцена, залита світлом без тонкого налаштування експозиції, з'їдає читабельність силуетів і робить бій нечитабельним, а неправильно виставлені діапазони яскравості змушують пристрій тримати високе навантаження на графічний блок довше, ніж потрібно.
Нагрівання й швидкий розряд батареї — прямий наслідок, і в сторах це б'є по утриманню сильніше, ніж будь-який візуальний дефект.
Ми починаємо з профілювання на реальному парку пристроїв, а не на флагмані розробника, і далі вибудовуємо освітлення мобільної гри під бюджет кадру: де ставити запечене світло, де залишити динамічне, як обмежити перекриття і на яких налаштуваннях якості що вимикати. Нижче — як це закривається крок за кроком.
Що дає вибудувана система освітлення
Вибудувана система освітлення — це не «гарна картинка», а передбачувана продуктивність сцени.
Коли джерела світла задані правилами, а не розставлені вручну, кадровий ритм перестає залежати від того, скільки об'єктів потрапило в поле зору: просідання зникають, а поведінка застосунку стає однаковою на слабких і потужних пристроях.
Саме стабільний кадровий ритм замовник відчуває як «застосунок не гальмує» — і це перше, що помічають гравці.
Оптимізація джерел світла дає другий вимірюваний ефект — скорочення їхньої кількості без втрати виразності. Частина світла замінюється запеченими картами, частина — емуляцією через матеріали, динамічними залишаються лише ті, що реально впливають на сприйняття сцени.
На практиці це знижує навантаження на відрисовку в рази, а сцена перестає «сипатися» при додаванні нових об'єктів.
Третій ефект — передбачуваний час збирання сцени. Коли правила освітлення описані й відтворювані, новий рівень або локація збирається за готовим шаблоном, а не з нуля: художник і розробник не витрачають дні на підгонку, а результат збігається з очікуванням з першого проходу. Це напряму впливає на терміни релізу оновлень.
І головне для експлуатації — керований клас відмов. Замість «десь темно, десь пересвіт, а на частині пристроїв усе зникло» команда отримує зрозумілий набір станів: якщо освітлення вибудуване, збій локалізується в конкретному правилі, а не розмазується по всій сцені. Це скорочує час діагностики й робить підтримку застосунку передбачуваною.
Режими освітлення та коли який підходить
Освітлення в мобільній грі — це насамперед бюджет продуктивності. Кожне динамічне джерело світла додає розрахунок на кадр, а на слабких пристроях це прямо перетворюється на просідання частоти та нагрівання.
Тому вибір режиму — не питання смаку, а компроміс між якістю картинки та стабільністю на цільових пристроях.
Запечені карти освітлення розраховуються заздалегідь і на пристрої не коштують нічого: світло й тіні «вшиті» в текстури. Динаміка в них з'являється лише через додаткові шари, інакше сцена залишається статичною.
Гібридна схема бере найкраще з двох: статична геометрія та загальне світло — запечені, а рухомі об'єкти, спалахи, постріли та герой отримують динамічні джерела. Саме цей варіант найчастіше дає стабільний результат на широкому парку пристроїв.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Запечені карти | Статичні сцени, арени, інтер'єри, фонові локації | Немає реакції на рух, зміна часу доби потребує перезапечення |
| Динамічне освітлення | Невеликі сцени, мало джерел, акцент на ефектах | Зростає навантаження на кадр, швидко впирається в бюджет слабких пристроїв |
| Гібридне освітлення | Основний випадок для мобільної гри: статика + рухомі об'єкти | Потребує акуратного налаштування меж і контролю кількості джерел |
На практиці режим обирають не «на око», а за цільовими пристроями та сценарієм гри. Ми закладаємо бюджет джерел на сцену, перевіряємо його на реальному парку і лише потім фіксуємо схему — так освітлення не стає вузьким місцем на релізі.
Як ми будуємо систему освітлення: етапи роботи
Роботу починаємо з аудиту сцени: збираємо референси від художників і геймдизайну, фіксуємо цільовий настрій локацій, розбираємо поточні матеріали та те, як вони реагують на світло.
На цьому етапі видно, де проблема в самих текстурах, а де — у невдало розставлених джерелах, і куди йде продуктивність на слабких пристроях.
Далі вибудовуємо схему освітлення: скільки джерел на локацію, які з них динамічні, які можна запечти в карти, як розподіляються тіні та відбиття.
Тільки після цього переходимо до налаштування джерел і матеріалів — правимо параметри тіней, інтенсивність, колірну температуру, налаштовуємо реакцію поверхонь, щоб світло читалося однаково на різних екранах.
- Аудит сцени: інвентаризація локацій, матеріалів і поточних джерел світла, замір навантаження на еталонних пристроях.
- Схема освітлення: розподіл статичного та динамічного світла за локаціями, план запечіння карт і бюджет на джерела.
- Налаштування джерел: параметри тіней, інтенсивність, колір, поведінка світла в русі та в статиці.
- Складання матеріалів: налаштування реакції поверхонь на світло, усунення артефактів і «плоских» зон.
- Перевірка на пристроях: прогін на слабких, середніх і флагманських моделях, замір частоти кадрів і нагріву.
- Оптимізація: зниження кількості динамічних джерел, спрощення тіней, переведення частини світла в запечені карти без втрати картинки.
- Передача документації: опис схеми, регламенти додавання нових локацій і правила, за якими команда підтримки вносить зміни.
Кожен етап закінчується складанням, яке можна запустити й подивитися на реальному пристрої, — так правки не накопичуються до фіналу.
На виході замовник отримує не лише налаштовану сцену, а й зрозумілі регламенти: як додати локацію, не зламавши загальну картину, і які параметри чіпати не можна.
Що замовник отримує на руки
Освітлення в мобільній грі — це не «картинка красивіша», а набір артефактів, за якими сцену можна відтворити, розширити й не зламати під час наступного оновлення.
Тому здаємо не «налаштований редактор», а комплект, який ваша команда або ми ведемо далі без археології по чужій сцені.
- Конфігурації освітлення — пресети для дня, ночі, інтер'єру та погодних станів: джерела, їхній внесок, тіні, туман. Кожен пресет — окремий файл, а не набір правок, розмазаних по сцені.
- Схеми сцени — карта джерел, зон запечення та статичної геометрії: видно, де світло рахується заздалегідь, а де в реальному часі, і чому обрано таку межу.
- Політики доступу — хто з команди змінює пресети, хто лише застосовує, як правки проходять перевірку. Це захищає візуал від випадкового перезапису в спільній гілці.
- Регламенти підтримки — як додати новий рівень або час доби, не перезбираючи всю сцену: покроковий порядок, точки розширення, типові помилки.
- Документація з продуктивності — заміри до і після оптимізації: скільки джерел тягне цільовий пристрій, де вузьке місце, які налаштування безпечно піднімати.
- Бібліотека готових пресетів — стартові набори під жанри, щоб нові сцени збиралися за години, а не з нуля.
- Інструкція з відкату — як повернути попередню версію освітлення, якщо оновлення погіршило вигляд або просідання кадрів.
Усе це передаємо у вашому репозиторії, з історією змін і зрозумілими іменами — щоб через півроку новий інженер розібрався в сцені без автора. Опишіть задачу — повернемося з оцінкою та планом по вашому проєкту.
Кейс: як ми прибрали провали кадрів у мобільній грі
Проєкт — мобільна гра з відкритими локаціями та динамічним часом доби. На старті сцена збиралася з десятками джерел світла на видиму область: кожен ліхтар, багаття та вітрина світили по-справжньому.
На середніх пристроях це давало просідання до 20–25 кадрів за секунду біля багаттєвих зон і помітні провали при повороті камери — гравці йшли вже на першому рівні.
Ми почали з профілювання: зняли заміри на реальних пристроях цільового парку, а не на флагмані розробника. Виявилося, що більша частина джерел не впливала на картинку — їхній внесок перекривався сусідніми й затухав за межами видимої геометрії.
Що змінили
Перевели статичне освітлення в запечені карти — світло від ліхтарів та архітектури перестало рахуватися в реальному часі. Динаміку залишили тільки там, де вона читається гравцем: багаття, спалахи здібностей, рухомі об'єкти.
Ввели бюджет джерел на кадр і правило, за яким дальні гасять яскравість, а не вимикаються ривком, — переходи перестали «блимати».
Окремо переробили пайплайн збірки сцени: раніше правка одного ліхтаря запускала повний перерахунок освітлення всієї локації.
Тепер карти перераховуються по чанках, і час збірки сцени скоротився з годин до десятків хвилин — художники перестали чекати на перезбірку перед кожною перевіркою.
Результат
| Метрика | До | Після |
|---|---|---|
| Кадри за секунду в багаттєвих зонах | 20–25 | стабільні 55–60 |
| Джерел світла на видиму область | 40+ | 6–8 активних |
| Час збірки сцени після правки | години | десятки хвилин |
Провали кадрів зникли, а разом із ними — скарги на «гальмує на телефоні» у відгуках. Методику заміру та бюджет джерел ми зафіксували в документі для команди: нові локації збираються вже за цими правилами, без повторного розбору.
Чим відрізняється запечене освітлення від динамічного?
Запечене освітлення — це передрозрахунок. Світло й тіні обчислюються заздалегідь і зберігаються в текстури, які рушій просто накладає на геометрію. У момент гри обчислень майже немає: звідси стабільний кадр навіть на слабкому залізі та передбачувана витрата батареї.
Плата — статичність: сцена й джерела світла фіксуються на етапі складання, а зміна положення світильника або зруйнованого об'єкта вимагає повторного запечення рівня.
Динамічне освітлення обчислюється на пристрої кожен кадр. Воно дає те, чого запечення не вміє в принципі: рухомі джерела, реакцію на руйнування, зміну часу доби, тіні від персонажів і транспорту.
Ціна — навантаження на графічний прискорювач і тепло, а на слабких моделях телефонів це прямий шлях до просідань частоти кадрів і тротлінгу. Порівняння підходів тому впирається не в «що красивіше», а в те, що в сцені змінюється, а що стоїть на місці.
На практиці майже завжди виграє гібрид. Статична геометрія — стіни, підлога, великі декорації — іде в запечення й дає базову картинку майже без вартості. Динаміка залишається там, де вона видна гравцеві: зброя, персонаж, вибухи, рухомі лампи.
Такий розклад тримає кадр рівним на середньому сегменті пристроїв, а на флагманах дозволяє підняти якість тіней без переробки рівнів.
Рішення ухвалюється за трьома ознаками: чи рухається джерело світла, чи змінюється геометрія сцени і наскільки широкий цільовий парк телефонів. Якщо хоча б одна відповідь «так» — ділянка йде в динаміку, решта запечатується.
Ми розмічаємо рівень за цими ознаками до початку роботи над світлом, щоб не переробляти освітлення після кожної правки планування.
Часті технічні сумніви щодо освітлення
Освітлення — це та частина графіки, де рішення ухвалюються один раз, а переробляти доводиться всю сцену. Тому сумніви тут не абстрактні: вони про те, як нова система уживеться з уже зібраними рівнями, чи не роздується збірка і чи потягнуть її слабкі пристрої. Розбираємо найчастіші питання.
Чи сумісне нове освітлення з уже готовими сценами?
Так, якщо впроваджувати його поетапно. Ми не перезбираємо рівні заново: спочатку переносимо поточні матеріали на нову модель освітлення, звіряємо еталонні кадри до і після, потім точково правимо лише ті сцени, де розбіжність помітна оку. Старі й нові рівні якийсь час живуть паралельно — це дозволяє не зупиняти роботу над контентом.
Наскільки освітлення обтяжує збірку та час завантаження?
Основну вагу дає не сама система, а запечені карти освітлення й тіней. Ми тримаємо їх у розумній роздільній здатності, перевикористовуємо спільні карти для однотипних приміщень і виносимо статику в спільний атлас — приріст розміру збірки залишається в межах кількох відсотків. Динамічні джерела вмикаємо лише там, де вони справді видимі гравцеві.
Чи працюватиме це на слабких пристроях?
Так, завдяки рівням якості. На слабкому залізі вимикаються динамічні тіні та частина джерел, залишається запечена статика — картинка зберігає читабельність, а частота кадрів не просідає.
Ми заздалегідь задаємо бюджет за кількістю активних джерел на сцену і перевіряємо його на реальних пристроях, а не лише в редакторі.
Що буде, якщо пізніше знадобиться змінити час доби чи погоду?
Систему закладаємо із запасом: параметри освітлення виносимо в окремі пресети, тому зміна часу доби чи погоди — це перемикання набору налаштувань, а не переробка сцен. Якщо такого завдання в планах немає, пресети все одно спрощують правки й не заважають збірці.
Якщо залишилися сумніви щодо конкретної сцени чи пристрою — опишіть завдання, повернемося з оцінкою та планом.
Обговоримо ваше завдання з освітлення
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібні вихідні дані щодо вашої сцени. Освітлення мобільної гри — це не «поставити пару джерел»: на результат впливають цільові платформи, бюджет кадру, художній референс і те, як сцена поводиться в динаміці. Чим точніші вхідні дані, тим менше ітерацій закладемо в план.
Що допомагає уточнити завдання на старті:
- Референси освітлення: скриншоти, відео, артпостановки — що саме подобається і чому.
- Цільові пристрої та мінімальний клас, під який оптимізуємо сцену.
- Тип сцени: відкрита локація, інтер'єр, підземелля, змішані переходи.
- Поточний стан: сцена з нуля чи переробка наявного освітлення.
- Обмеження бюджету кадру: скільки джерел і тіней сцена тримає без просідань.
- Матеріали та шейдери: як поверхні реагують на світло, чи є готові асети.
- Терміни та етапність: чи потрібен вертикальний зріз або одразу повна сцена.
Опишіть завдання у вільній формі — додайте референси та вхідні дані щодо пристроїв. Ми повернемося з оцінкою та планом: розкладемо роботу за етапами, позначимо, де вузькі місця за продуктивністю, і запропонуємо, що можна спростити без втрати картинки.
Якщо частина даних поки не готова, це не блокер — уточнимо в листуванні та зафіксуємо припущення прямо в плані.
