Разработка системы освещения мобильной игры от идеи до оптимизации

Освещение мобильной игры: где ломается кадр и почему

Освещение мобильной игры почти никогда не ломается «в моменте» — оно деградирует постепенно, и первый сигнал обычно приходит из отзывов: «греется», «тормозит на среднем телефоне», «в подземелье всё белое». К этому моменту в проекте уже накопился набор источников света, которые никто не сводил в единую политику: динамические фонари, тени от героя, эффекты способностей, эмиссия материалов. Каждый по отдельности выглядит безобидно, вместе они дают просадку производительности освещения именно на слабом железе — том самом, где сидит основная аудитория.

Разберём, где обычно рвётся. Провалы кадров на массовых устройствах почти всегда связаны не с числом источников, а с их пересчётом на каждый пиксель: десяток динамических фонарей в сцене умножается на перекрытия и затенение, и бюджет кадра уходит за отведённое время. Артефакты теней проявляются иначе — рваные края на границах карты теней, мерцание при движении камеры, «ступеньки» на дальних объектах. Это не косметика: игрок читает такие дефекты как небрежность и уходит раньше, чем доходит до платного контента.

Отдельная история — пересветы и энергопотребление. Сцена, залитая светом без тонкой настройки экспозиции, съедает читаемость силуэтов и делает бой нечитаемым, а неверно выставленные диапазоны яркости заставляют устройство держать высокую нагрузку на графический блок дольше необходимого. Нагрев и быстрый разряд батареи — прямое следствие, и в сторах это бьёт по удержанию сильнее, чем любой визуальный дефект.

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

Что даёт выстроенная система освещения

Выстроенная система освещения — это не «красивая картинка», а предсказуемая производительность сцены. Когда источники света заданы правилами, а не расставлены вручную, кадровый ритм перестаёт зависеть от того, сколько объектов попало в поле зрения: просадки уходят, а поведение приложения становится одинаковым на слабых и сильных устройствах. Именно стабильный кадровый ритм заказчик ощущает как «приложение не тормозит» — и это первое, что замечают игроки.

Оптимизация источников света даёт второй измеримый эффект — сокращение их числа без потери выразительности. Часть света заменяется запечёнными картами, часть — эмуляцией через материалы, динамическими остаются только те, что реально влияют на восприятие сцены. На практике это снижает нагрузку на отрисовку в разы, а сцена перестаёт «сыпаться» при добавлении новых объектов.

Третий эффект — предсказуемое время сборки сцены. Когда правила освещения описаны и воспроизводимы, новый уровень или локация собирается по готовому шаблону, а не с нуля: художник и разработчик не тратят дни на подгонку, а результат совпадает с ожиданием с первого прохода. Это напрямую влияет на сроки релиза обновлений.

И главное для эксплуатации — управляемый класс отказов. Вместо «где-то темно, где-то пересвет, а на части устройств всё пропало» команда получает понятный набор состояний: если освещение выстроено, сбой локализуется в конкретном правиле, а не размазывается по всей сцене. Это сокращает время диагностики и делает поддержку приложения предсказуемой.

Режимы освещения и когда какой подходит

Освещение в мобильной игре — это в первую очередь бюджет производительности. Каждый динамический источник света добавляет расчёт на кадр, а на слабых устройствах это прямо превращается в просадку частоты и нагрев. Поэтому выбор режима — не вопрос вкуса, а компромисс между качеством картинки и стабильностью на целевых устройствах.

Запечённые карты освещения считаются заранее и на устройстве не стоят ничего: свет и тени «вшиты» в текстуры. Динамика в них появляется только через дополнительные слои, иначе сцена остаётся статичной. Гибридная схема берёт лучшее из двух: статичная геометрия и общий свет — запечены, а движущиеся объекты, вспышки, выстрелы и герой получают динамические источники. Именно этот вариант чаще всего даёт стабильный результат на широком парке устройств.

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

Как мы строим систему освещения: этапы работы

Работу начинаем с аудита сцены: собираем референсы от художников и геймдизайна, фиксируем целевое настроение локаций, разбираем текущие материалы и то, как они реагируют на свет. На этом этапе видно, где проблема в самих текстурах, а где — в неудачно расставленных источниках, и куда уходит производительность на слабых устройствах.

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

1. Аудит сцены: инвентаризация локаций, материалов и текущих источников света, замер нагрузки на эталонных устройствах.
2. Схема освещения: распределение статического и динамического света по локациям, план запекания карт и бюджет на источники.
3. Настройка источников: параметры теней, интенсивность, цвет, поведение света в движении и в статике.
4. Сборка материалов: настройка реакции поверхностей на свет, устранение артефактов и «плоских» зон.
5. Проверка на устройствах: прогон на слабых, средних и флагманских моделях, замер частоты кадров и нагрева.
6. Оптимизация: снижение числа динамических источников, упрощение теней, перевод части света в запечённые карты без потери картинки.
7. Передача документации: описание схемы, регламенты добавления новых локаций и правила, по которым команда поддержки вносит изменения.

Каждый этап заканчивается сборкой, которую можно запустить и посмотреть на реальном устройстве, — так правки не копятся к финалу. На выходе заказчик получает не только настроенную сцену, но и понятные регламенты: как добавить локацию, не сломав общую картину, и какие параметры трогать нельзя.

Что заказчик получает на руки

Освещение в мобильной игре — это не «картинка красивее», а набор артефактов, по которым сцену можно воспроизвести, расширить и не сломать при следующем обновлении. Поэтому сдаём не «настроенный редактор», а комплект, который ваша команда или мы ведём дальше без археологии по чужой сцене.

• Конфигурации освещения — пресеты для дня, ночи, интерьера и погодных состояний: источники, их вклад, тени, туман. Каждый пресет — отдельный файл, а не набор правок, размазанных по сцене.
• Схемы сцены — карта источников, зон запекания и статической геометрии: видно, где свет считается заранее, а где в реальном времени, и почему выбрана такая граница.
• Политики доступа — кто из команды меняет пресеты, кто только применяет, как правки проходят проверку. Это защищает визуал от случайной перезаписи в общей ветке.
• Регламенты поддержки — как добавить новый уровень или время суток, не пересобирая всю сцену: пошаговый порядок, точки расширения, типовые ошибки.
• Документация по производительности — замеры до и после оптимизации: сколько источников тянет целевое устройство, где узкое место, какие настройки безопасно поднимать.
• Библиотека готовых пресетов — стартовые наборы под жанры, чтобы новые сцены собирались за часы, а не с нуля.
• Инструкция по откату — как вернуть предыдущую версию освещения, если обновление ухудшило вид или просадку кадров.

Всё это передаём в вашем репозитории, с историей изменений и понятными именами — чтобы через полгода новый инженер разобрался в сцене без автора. Опишите задачу — вернёмся с оценкой и планом по вашему проекту.

Кейс: как мы убрали провалы кадров в мобильной игре

Проект — мобильная игра с открытыми локациями и динамическим временем суток. На старте сцена собиралась с десятками источников света на видимую область: каждый фонарь, костёр и витрина светили по-настоящему. На средних устройствах это давало просадки до 20–25 кадров в секунду у костровых зон и заметные провалы при повороте камеры — игроки уходили на первом же уровне.

Мы начали с профилирования: сняли замеры на реальных устройствах целевого парка, а не на флагмане разработчика. Оказалось, что большая часть источников не влияла на картинку — их вклад перекрывался соседними и затухал за пределами видимой геометрии.

Что изменили

Перевели статичное освещение в запечённые карты — свет от фонарей и архитектуры перестал считаться в реальном времени. Динамику оставили только там, где она читается игроком: костёр, вспышки способностей, движущиеся объекты. Ввели бюджет источников на кадр и правило, по которому дальние гасят яркость, а не отключаются рывком, — переходы перестали «мигать».

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

Результат

Провалы кадров ушли, а вместе с ними — жалобы на «тормозит на телефоне» в отзывах. Методику замера и бюджет источников мы зафиксировали в документе для команды: новые локации собираются уже по этим правилам, без повторного разбора.

Чем отличается запечённое освещение от динамического?

Запечённое освещение — это предрасчёт. Свет и тени считаются заранее и сохраняются в текстуры, которые движок просто накладывает на геометрию. В момент игры вычислений почти нет: отсюда стабильный кадр даже на слабом железе и предсказуемый расход батареи. Плата — статичность: сцена и источники света фиксируются на этапе сборки, а изменение положения светильника или разрушаемого объекта требует повторного запекания уровня.

Динамическое освещение считается на устройстве каждый кадр. Оно даёт то, чего запекание не умеет в принципе: движущиеся источники, реакцию на разрушения, смену времени суток, тени от персонажей и транспорта. Цена — нагрузка на графический ускоритель и тепло, а на слабых моделях телефонов это прямой путь к просадкам частоты кадров и троттлингу. Сравнение подходов поэтому упирается не в «что красивее», а в то, что в сцене меняется, а что стоит на месте.

На практике почти всегда выигрывает гибрид. Статичная геометрия — стены, пол, крупные декорации — уходит в запекание и даёт базовую картинку почти без стоимости. Динамика остаётся там, где она видна игроку: оружие, персонаж, взрывы, движущиеся лампы. Такой расклад держит кадр ровным на среднем сегменте устройств, а на флагманах позволяет поднять качество теней без переделки уровней.

Решение принимается по трём признакам: двигается ли источник света, меняется ли геометрия сцены и насколько широк целевой парк телефонов. Если хотя бы один ответ «да» — участок уходит в динамику, остальное запекается. Мы размечаем уровень по этим признакам до начала работы над светом, чтобы не переделывать освещение после каждой правки планировки.

Частые технические сомнения по освещению

Освещение — та часть графики, где решения принимаются один раз, а переделывать приходится всю сцену. Поэтому сомнения здесь не абстрактные: они про то, как новая система уживётся с уже собранными уровнями, не раздуется ли сборка и потянут ли её слабые устройства. Разбираем самые частые вопросы.

Насколько освещение утяжеляет сборку и время загрузки?

Основной вес даёт не сама система, а запечённые карты освещения и теней. Мы держим их в разумном разрешении, переиспользуем общие карты для однотипных помещений и выносим статику в общий атлас — прирост размера сборки остаётся в пределах нескольких процентов. Динамические источники включаем только там, где они действительно видны игроку.

Заработает ли это на слабых устройствах?

Да, за счёт уровней качества. На слабом железе отключаются динамические тени и часть источников, остаётся запечённая статика — картинка сохраняет читаемость, а частота кадров не проседает. Мы заранее задаём бюджет по числу активных источников на сцену и проверяем его на реальных устройствах, а не только в редакторе.

Что будет, если позже понадобится сменить время суток или погоду?

Систему закладываем с запасом: параметры освещения выносим в отдельные пресеты, поэтому смена времени суток или погоды — это переключение набора настроек, а не переделка сцен. Если такой задачи в планах нет, пресеты всё равно упрощают правки и не мешают сборке.

Если остались сомнения по конкретной сцене или устройству — опишите задачу, вернёмся с оценкой и планом.

Обсудим вашу задачу по освещению

Чтобы вернуться с оценкой и планом, а не с общими словами, нам нужны исходные данные по вашей сцене. Освещение мобильной игры — это не «поставить пару источников»: на результат влияют целевые платформы, бюджет кадра, художественный референс и то, как сцена ведёт себя в динамике. Чем точнее вводные, тем меньше итераций заложим в план.

Что помогает уточнить задачу на старте:

• Референсы освещения: скриншоты, видео, арт-постановки — что именно нравится и почему.
• Целевые устройства и минимальный класс, под который оптимизируем сцену.
• Тип сцены: открытая локация, интерьер, подземелье, смешанные переходы.
• Текущее состояние: сцена с нуля или переработка существующего освещения.
• Ограничения бюджета кадра: сколько источников и теней сцена держит без просадок.
• Материалы и шейдеры: как поверхности реагируют на свет, есть ли готовые ассеты.
• Сроки и этапность: нужен ли вертикальный срез или сразу полная сцена.

Опишите задачу в свободной форме — приложите референсы и вводные по устройствам. Мы вернёмся с оценкой и планом: разложим работу по этапам, обозначим, где узкие места по производительности, и предложим, что можно упростить без потери картинки. Если часть данных пока не готова, это не блокер — уточним в переписке и зафиксируем допущения прямо в плане.