Tilemap Optimization for Large Mobile Worlds

A large tilemap world on mobile runs into three limits: draw calls from too many visible tiles, memory from loading the entire map, and collision overhead from too many physics shapes. Chunking the map into loadable sections, culling what is off-screen, and managing the tile atlas properly solve all three. The techniques are straightforward, and most of them can be added to an existing tilemap without restructuring the game.

Why tilemaps hit mobile limits

A tilemap that runs fine in the editor on a desktop machine can crawl on a phone. Three reasons.

1. Draw call count. Each unique material or texture on screen is a draw call. A tilemap with multiple atlas pages or mixed sprite sources can produce dozens of draw calls for what looks like a simple background.
2. Memory. Loading a 200x200 tilemap with all its tile data and collision shapes can use tens of megabytes. On a phone with 2GB total, that is a significant share of available memory.
3. Collision. If the tilemap generates a physics collider per tile, a large map creates thousands of physics shapes. The physics engine checks all of them every frame, and the cost scales with count.

A small map (under 50x50 tiles) rarely triggers these problems. A large one (100x100 and up) will hit at least one of them on a low-end device.

Chunking: loading the world in pieces

Instead of one large tilemap, divide the world into chunks, typically 16x16 or 32x32 tiles each.

The chunk system works in three parts.

1. The chunk grid. The world is divided into a grid. Each cell is a chunk with its own tile data. Only chunks near the camera are loaded into memory.

2. Load and unload triggers. When the camera moves, the system checks which chunks should be visible. Chunks entering the visible range are loaded. Chunks leaving it are unloaded. Add a buffer of one chunk in each direction so loading happens before the chunk is visible, preventing pop-in.

3. Chunk data storage. Store each chunk as a separate asset or as a section of a larger data file. Loading a chunk should be a single read operation, not a per-tile iteration.

The buffer zone is important. Without it, chunks load as they enter the screen edge, and on a slow device the load spike causes a visible hitch. One extra chunk in each direction gives the system a frame or two of advance notice.

The profiler will show whether chunking is necessary. If tilemap rendering is not in your top three costs, this optimisation is premature.

Culling: not drawing what is off-screen

Even within loaded chunks, not every tile needs to be rendered.

Two levels of culling.

Camera culling. Only render tiles that are within the camera's viewport plus a small margin. In Unity, the Tilemap renderer handles this automatically if the tilemap is set up correctly. In custom rendering systems, compute the visible tile range from the camera bounds and only draw those.

Layer culling. If the tilemap has multiple layers (ground, decoration, objects), consider hiding layers that are fully occluded. A decoration layer behind a solid building layer is invisible and does not need to be drawn.

Camera culling is usually automatic. Layer culling is a manual decision that depends on your game's visual structure. Measure before adding it, because the overhead of checking occlusion can exceed the savings if the layers are small.

Atlas management: one texture, one draw call

The single biggest performance gain for tilemaps comes from fitting all visible tiles into one texture atlas.

When all tiles share a single atlas, the entire visible tilemap can render in one draw call regardless of how many different tile types are on screen. When tiles span multiple atlases, each additional texture is an additional draw call.

Three rules for atlas packing.

1. Pack tiles into a single atlas. Use the sprite packer to combine all tilemap sprites into one texture. If the tiles fit, which they usually do for pixel art or clean 2D styles, this alone can cut draw calls from double digits to one.
2. Keep the atlas under the device texture size limit. Most mobile GPUs support 2048x2048 or 4096x4096. Stay within 2048 for the widest compatibility.
3. Separate tilemap sprites from UI and character sprites. Different render layers benefit from separate atlases so that loading one does not force loading all.

If your tile set exceeds one atlas page, prioritise fitting the most common tiles into the first page. Ground tiles that appear hundreds of times matter more for batching than rare decorative tiles.

Collision reduction

Tilemap collision is the least visible performance cost and often the most expensive.

Composite colliders. Instead of one box collider per solid tile, use a composite collider that merges adjacent solid tiles into larger shapes. In Unity, the TilemapCollider2D with CompositeCollider2D reduces hundreds of individual colliders to a handful of polygons.

Collision layers for tile types. Only tiles that the player or projectiles interact with need colliders. Ground tiles under the player need them. Background decorations do not. Separate the tilemap into physics layers and only add colliders to the layers that need them.

Chunk-scoped collision. If you are using chunks, generate collision shapes per chunk. Unloaded chunks have no collision shapes, which reduces the total physics shape count to only the area near the player.

Composite colliders also improve collision accuracy, because fewer shapes means fewer edge cases where the player clips through a seam between adjacent tiles.

LOD for tilemaps

Level of detail is not just for 3D. A tilemap can use a simplified version at distance.

Distant chunks at reduced detail. Chunks far from the camera render as a single pre-baked sprite instead of individual tiles. This replaces hundreds of tile draw calls with one sprite render.

Reduced animation. Animated tiles (water, lava, flickering lights) far from the camera can freeze on a single frame or animate at half the rate. Animation updates per tile add up quickly on large maps.

Simplified collision. Distant chunks can use a single bounding box instead of detailed tile collision, since the player is not interacting with them.

These are refinements for very large worlds (1000x1000 and up). For most mobile games with maps under 200x200, chunking and atlas management are sufficient.

Profiler checks that matter

Four specific things to measure.

1. Draw call count with the map fully loaded versus chunked. The reduction should be visible and significant.
2. Memory usage with the full map versus with chunking and unloading. On a low-end device, this determines whether the game runs at all.
3. Physics shape count before and after composite colliders. The reduction should be an order of magnitude.
4. Frame time contribution of the tilemap renderer. If it is under ten percent of frame time, further optimisation here has diminishing returns and you should look elsewhere.

Profile on the floor device, not on your development machine. The performance characteristics of the floor device are covered in Android Device Fragmentation Guide.

What we would do

Start with the atlas. Pack all tiles into one texture and measure the draw call count before and after. This is the cheapest change and often the largest improvement.

Add composite colliders next. The setup in Unity is a few clicks and the performance gain on large maps is immediate.

Add chunking only when the map is large enough to cause memory pressure or when loading it produces a visible stall. Chunking is the most complex of these techniques, and it is unnecessary for maps that fit comfortably in memory.

Profile after each change, on the floor device. Tilemap optimisation is the kind of work where measuring prevents you from building complexity you do not need.

The short version

• Large tilemaps hit three mobile limits: draw calls, memory, and collision shape count.
• Pack all tiles into one atlas for a single draw call.
• Use composite colliders to merge individual tile colliders into larger shapes.
• Chunk the map into 16x16 or 32x32 sections and load only the chunks near the camera.
• Add a one-chunk buffer to prevent visible pop-in during loading.
• Profile on the floor device after each change to confirm the improvement.

Pack your tile atlas this week and measure the draw call reduction. If you need a performance pass on a large tilemap game, send us the build.

Related reading: Unity Mobile Performance on Low-End Android, Unity Object Pooling for Mobile Stutter, and Shader Basics for Devs.