Mobile Game Lighting System Development from Idea to Optimization

Mobile game lighting: where the frame breaks and why

Mobile game lighting almost never breaks "in the moment" — it degrades gradually, and the first signal usually comes from reviews: "it heats up," "it lags on a mid-range phone," "everything is white in the dungeon." By that point, the project has already accumulated a set of light sources that no one has consolidated into a single policy: dynamic point lights, shadows from the hero, ability effects, material emission.

Each one on its own looks harmless; together they cause a drop in lighting performance specifically on weak hardware — the very hardware where the core audience lives.

Let's break down where it usually snaps.

Frame drops on mass-market devices are almost always related not to the number of light sources, but to their per-pixel recalculation: a dozen dynamic point lights in a scene get multiplied by overlaps and shadowing, and the frame budget exceeds the allotted time.

Shadow artifacts manifest differently — jagged edges at shadow map boundaries, flickering when the camera moves, "stair-stepping" on distant objects. This isn't cosmetic: players read such defects as sloppiness and leave before they ever reach paid content.

Overexposure and power consumption are a separate story.

A scene flooded with light without fine-tuned exposure control destroys silhouette readability and makes combat unreadable, while incorrectly set brightness ranges force the device to keep a high load on the graphics unit longer than necessary.

Heating and fast battery drain are the direct consequence, and in the stores this hurts retention more than any visual defect.

We start with profiling on a real device fleet, not on the developer's flagship, and then build mobile game lighting around the frame budget: where to place baked light, where to keep it dynamic, how to limit overlaps, and what to disable at which quality settings. Below is how this gets closed out step by step.

What a well-structured lighting system delivers

A well-structured lighting system is not a "pretty picture" but predictable scene performance.

When light sources are defined by rules rather than placed by hand, frame pacing stops depending on how many objects are in view: drops disappear, and the application behaves the same on weak and strong devices.

It is stable frame pacing that the client perceives as "the app doesn't lag" — and this is the first thing players notice.

Optimizing light sources delivers a second measurable effect — reducing their number without losing expressiveness. Some lights are replaced by baked maps, some by emulation through materials, and only those that genuinely affect how the scene is perceived remain dynamic.

In practice, this reduces the rendering load severalfold, and the scene stops "falling apart" when new objects are added.

The third effect is predictable scene assembly time.

When lighting rules are described and reproducible, a new level or location is assembled from a ready-made template rather than from scratch: the artist and the developer don't spend days tweaking, and the result matches expectations on the first pass. This directly affects the release timeline for updates.

And the most important thing for operations is a manageable failure class.

Instead of "it's dark somewhere, overexposed somewhere else, and on some devices everything is gone," the team gets a clear set of states: if lighting is well-structured, a failure is localized to a specific rule rather than smeared across the entire scene. This shortens diagnosis time and makes application support predictable.

Lighting modes and when each one fits

Lighting in a mobile game is first and foremost a performance budget. Every dynamic light source adds a per-frame calculation, and on low-end devices this translates directly into frame rate drops and heating.

That is why choosing a mode is not a matter of taste, but a trade-off between image quality and stability on target devices.

Baked lighting maps are calculated in advance and cost nothing on the device: light and shadows are "baked" into the textures. Dynamics in them appear only through additional layers, otherwise the scene remains static.

The hybrid approach takes the best of both: static geometry and ambient light are baked, while moving objects, flashes, shots, and the hero get dynamic sources. It is this option that most often delivers a stable result across a wide range of devices.

In practice, the mode is chosen not "by eye," but based on target devices and the game's scenario. We set a budget for sources per scene, verify it on a real device range, and only then lock in the scheme — that way lighting does not become a bottleneck at release.

How we build a lighting system: stages of work

We start with an audit of the scene: we collect references from artists and game design, pin down the target mood of the locations, and analyze the current materials and how they react to light.

At this stage it becomes clear where the problem lies in the textures themselves and where it lies in poorly placed light sources, and where performance is being drained on low-end devices.

Next we build the lighting scheme: how many sources per location, which of them are dynamic, which can be baked into maps, and how shadows and reflections are distributed.

Only after that do we move on to configuring the sources and materials — we adjust shadow parameters, intensity, color temperature, and tune the reaction of surfaces so that the light reads the same on different screens.

1. Scene audit: inventory of locations, materials, and current light sources, measuring the load on reference devices.
2. Lighting scheme: distribution of static and dynamic light across locations, a map baking plan, and a budget for light sources.
3. Source configuration: shadow parameters, intensity, color, and the behavior of light in motion and in static scenes.
4. Material assembly: tuning how surfaces react to light, eliminating artifacts and "flat" zones.
5. Device testing: running on low-end, mid-range, and flagship models, measuring frame rate and heat.
6. Optimization: reducing the number of dynamic sources, simplifying shadows, and converting part of the light into baked maps without losing the visuals.
7. Documentation handover: a description of the scheme, regulations for adding new locations, and the rules by which the support team makes changes.

Each stage ends with a build that can be launched and viewed on a real device — so that edits don't pile up until the finale.

At the end, the client receives not only a configured scene but also clear regulations: how to add a location without breaking the overall picture, and which parameters must not be touched.

What the client receives

Lighting in a mobile game is not about "a prettier picture" but a set of artifacts by which the scene can be reproduced, extended, and not broken in the next update.

That is why we deliver not a "configured editor" but a package that your team or we can carry forward without archaeology on someone else's scene.

• Lighting configurations — presets for day, night, interior, and weather states: light sources, their contribution, shadows, fog. Each preset is a separate file, not a set of edits smeared across the scene.
• Scene schematics — a map of light sources, baking zones, and static geometry: it shows where lighting is computed in advance and where it is real-time, and why that boundary was chosen.
• Access policies — who on the team changes presets, who only applies them, how edits are reviewed. This protects the visuals from accidental overwriting in a shared branch.
• Support regulations — how to add a new level or time of day without rebuilding the entire scene: a step-by-step procedure, extension points, common mistakes.
• Performance documentation — measurements before and after optimization: how many light sources the target device can handle, where the bottleneck is, which settings are safe to raise.
• A library of ready-made presets — starter sets for genres, so that new scenes can be assembled in hours rather than from scratch.
• A rollback guide — how to revert to the previous lighting version if an update worsened the look or caused frame drops.

We hand all of this over in your repository, with a change history and clear names — so that six months later a new engineer can understand the scene without the author. Describe your task — we will get back to you with an estimate and a plan for your project.

Case study: how we eliminated frame drops in a mobile game

The project is a mobile game with open locations and dynamic time of day. At the start, the scene was assembled with dozens of light sources per visible area: every streetlamp, campfire, and shop window cast real light.

On mid-range devices, this caused drops to 20–25 frames per second around campfire zones and noticeable stutters when rotating the camera — players quit on the very first level.

We started with profiling: we took measurements on real devices from the target install base, not on the developer's flagship.

It turned out that most of the sources didn't affect the picture — their contribution was overlapped by neighboring ones and faded beyond the visible geometry.

What we changed

We moved static lighting into baked maps — light from streetlamps and architecture stopped being calculated in real time. We kept dynamic lighting only where it's readable by the player: campfires, ability flashes, moving objects.

We introduced a per-frame source budget and a rule whereby distant sources dim their brightness rather than switching off abruptly — transitions stopped "flickering."

We also reworked the scene assembly pipeline separately: previously, editing a single streetlamp triggered a full recalculation of lighting for the entire location.

Now maps are recalculated per chunk, and scene assembly time dropped from hours to tens of minutes — artists no longer wait for a rebuild before every check.

Result

The frame drops are gone, and along with them — complaints about "lagging on my phone" in reviews. We documented the measurement methodology and source budget in a team document: new locations are now assembled according to these rules, without a repeat analysis.

How does baked lighting differ from dynamic lighting?

Baked lighting is a precomputation. Light and shadows are calculated in advance and stored in textures that the engine simply applies to the geometry. At runtime there is almost no computation: hence a stable frame rate even on weak hardware and predictable battery consumption.

The price is staticness: the scene and light sources are fixed at the build stage, and changing the position of a light fixture or a destructible object requires re-baking the level.

Dynamic lighting is computed on the device every frame. It provides what baking fundamentally cannot: moving sources, reaction to destruction, time-of-day changes, shadows from characters and vehicles.

The cost is the load on the graphics accelerator and heat, and on weak phone models this is a direct path to frame rate drops and throttling.

The comparison of approaches therefore comes down not to "which is prettier," but to what changes in the scene and what stays in place.

In practice, a hybrid almost always wins. Static geometry — walls, floor, large decorations — goes into baking and provides the base picture at almost no cost. Dynamics remain where the player can see them: weapons, the character, explosions, moving lamps.

This arrangement keeps the frame rate steady on the mid-range segment of devices, while on flagships it allows raising shadow quality without reworking the levels.

The decision is made based on three criteria: whether the light source moves, whether the scene geometry changes, and how broad the target fleet of phones is. If at least one answer is "yes" — that section goes into dynamics, the rest is baked.

We mark up the level according to these criteria before starting work on the lighting, so as not to redo the lighting after every layout change.

Common technical concerns about lighting

Lighting is the part of graphics where decisions are made once, but the entire scene has to be redone.

That is why the concerns here are not abstract: they are about how the new system will coexist with already assembled levels, whether the build will balloon, and whether weak devices will handle it. Let's go through the most common questions.

How much does lighting weigh down the build and load time?

The main weight comes not from the system itself, but from baked lighting and shadow maps. We keep them at a reasonable resolution, reuse shared maps for similar rooms, and move static elements into a common atlas — the increase in build size stays within a few percent. We enable dynamic sources only where they are actually visible to the player.

Will this work on weak devices?

Yes, thanks to quality levels. On weak hardware, dynamic shadows and some sources are disabled, leaving baked static lighting — the image remains readable, and the frame rate does not drop.

We set a budget in advance for the number of active sources per scene and test it on real devices, not just in the editor.

What if later we need to change the time of day or weather?

We design the system with headroom: lighting parameters are moved into separate presets, so changing the time of day or weather is switching a set of settings, not redoing scenes.

If such a task is not in the plans, presets still simplify edits and do not interfere with the build.

If you still have concerns about a specific scene or device — describe the task, and we will get back to you with an estimate and a plan.

Let's discuss your lighting task

To come back with an estimate and a plan rather than generalities, we need source data about your scene.

Mobile game lighting is not "placing a couple of light sources": the result is influenced by target platforms, frame budget, the art reference, and how the scene behaves in motion. The more precise the inputs, the fewer iterations we will build into the plan.

What helps clarify the task at the start:

• Lighting references: screenshots, videos, art setups — what exactly you like and why.
• Target devices and the minimum class we are optimizing the scene for.
• Scene type: open location, interior, dungeon, mixed transitions.
• Current state: a scene from scratch or a rework of existing lighting.
• Frame budget constraints: how many light sources and shadows the scene can handle without drops.
• Materials and shaders: how surfaces react to light, whether ready-made assets exist.
• Timeline and phasing: whether a vertical slice is needed or the full scene right away.

Describe the task in free form — attach references and inputs about devices. We will come back with an estimate and a plan: we will break the work down into stages, identify where the performance bottlenecks are, and suggest what can be simplified without losing the look.

If some of the data is not ready yet, that is not a blocker — we will clarify it in correspondence and record the assumptions directly in the plan.