Grid based rendering

[kybarg]

Developing a grid-based road-building game.
Please suggest the best way to render the road system.
The closest example is Mini Motorways.
Consider the worst-case scenario: a 128×128 grid filled with tiles that have 8 possible directions.
The game is aimed at mobile devices.

[Natookie]

A 128x128 grid with 8 directional variants is about 16,384 tiles, each potentially unique. Using the naive approach of spawning 16,384 SpriteBundle is definitely not viable for mobile

I would suggest using a chunk based mesh rendering. As you may already know, chunk collapses the entire grid into a small number of meshes, only one rebuild per changed region, which means only one draw call per visible chunk. Conceptually, this is the same strategy used in voxel engine like Minecraft, just applied to a 2D grid

Think of your 128x128 grid as 64 independent regions, each responsible for rendering its own piece of the road network. When a player places a road tile, only the region containing that tile needs to know about it, the other just ignores it. O(changed tiles) update cost instead of O(grid size)

---

1. Divide Grid into Chunks

Divide the 128x128 grid into 16x16 tiles. Dividing it gives you an 8x8 grid of chunks. The mapping from a tile coordinate to its owning chunk is just an integer division:

fn tile_to_chunk(tile_x: i32, tile_y: i32) -> (i32, i32){
    (tile_x / 16, tile_y / 16)
}

At startup, spawn all 64 chunk entities. Each chunk gets a Mesh2d component(initially empty), a shared MeshMaterial2d, and a Dirty marker so they all rebuild on the first frame

2. Store Tile State in Central Resource

Your tile data should live in a single Resource, not scattered across ECS entities. Each tiles stores a connetion bitmask, one bit per cardinal and diagonal direction. This is an EXAMPLE of the bitmask pattern which describes which neighbors this tile connects to:

• bit 0 = North
• bit 2 = East
• bit 4 = South
• bit 6 = West

When a tile is placed or removed, update this resource first, then recalculate the bitmask for that tile, and its immediate neighbors. Then fire a TileChanged event

3. Mark Chunks Dirty on Tile Changes

Never rebuild chunk immediately when a tile changes. Instead, mark it as dirty, and let a dedicated system handle all rebuilds at the end of the frame. Meaning if a player somehow, say triggers 10 til changes in one frame, affected chunk only rebuilt once

fn on_tile_changed(
    mut events: EventReader<TileChanged>,
    mut commands: Commands,
    chunks: Query<(Entity, &RoadChunk)>,
){
    for ev in events.read(){
        let (cx, cy) = tile_to_chunk(ev.tile_x, ev.tile_y);

        for dx in -1..=1{
            for dy in -1..=1{
                if let Some((entity, _)) = chunks.iter().find(|(_, c)| c.chunk_x == cx + dx && c.chunk_y == cy + dy){
                    commands.entity(entity).insert(Dirty);
                }
            }
        }
    }
}

The reason you mark neighbors dirty yoo (the dx/dy loop) is for edge blending, a road tile sitting on chunk boundary needs adjacent chunk to also redraw

4. Rebuild Dirty Chunk Meshes

At the end of each frame, a dedicated system queries all chunks marked Dirty, rebuild their meshes, and removes the marker. The geometry should be:

• A center quad for every occupied tile (always present)
• An arm quad extending to each connected neighbor direction (one per active bitmask bit)
• A rounded cap quad for dead ends
  All of this gets pushed into a single flat Vec of positions, UVs, and indices, then handed to Bevy as one Mesh.

Run on_tile_changed and rebuild_dirty_chunks in .chain() so dirty marking always completes before the rebuild pass in the same frame

---

📱 Mobile Improvement:

1. Use frustum cull chunks, toggle Visibility::Hidden on chunks outside the camera's view rect
   
2. Use RenderAssetUsages::RENDER_WORLD, this tells Bevy not to keep a CPU copy of the mesh after upload
   
3. Use one shared ColorMaterial, all chunks share the same material handle, so Bevy can batch them into fewer draw calls

[kybarg]

Wow! Thank you for such a deep dive into my question! Really appreciate it! Need some time to think on this one though.