Intended approaches for common tasks

[BrettWitty]

I was interested in the recommended way in bevy_tilemap to attack standard problems that might come up. I've broken it out into a few problems. I'm interested in solutions, or a better understanding of how the library does things.

I assume the straightforward approach to using bevy_tilemap is something like in a Zelda-game: largeish static tile world, objects in a sparse layer on top, and you use the transform method to move the world (or the camera) around.

Tile overlays

If you wanted a targeting overlay like a rectangle or reticle, you would:

• Implement a sparse layer with high Z-order (the "overlays" layer)
• Then place a transparent rectangle tile in the right spot.

You'd use similar techniques for highlighting an area, say for a building game.

Lighting

If you wanted to simulate per-tile lighting, you might tint or use an overlay with a certain level of alpha.

In roguelikes if you can't see a tile because of obstacles or light, it is obscured to you. This might be achieved similarly by tinting or visibility overlays.

Multi-screen worlds

Assume the map is bigger than the screen. I can see two ways of doing this:

1. Create a large tilemap, populate all the tiles and move the camera as needed.
2. Create a tilemap that just covers the screen and when moving, update the content of every tile accordingly.

The first one is more memory-hungry, but in a relatively static world is fairly fast to render. It also easily allows the camera to move smoothly whereas that would be harder in the second approach.

The second one I assume has performance issues in that you're not really using chunks and you invalidate every cached texture every time you update.

Animated world tiles

Imagine you have an ocean where the ocean tiles animate between a few frames. Each frame would you update the tiles with the new image from the TextureAtlas? Would this invalidate every chunk with animated tiles? Can you determine which chunks are on-screen and thus only update those tiles?

Infinite worlds

If you had a procedurally-infinite world, your player carves out some portion of that by visiting it. This creates a number of chunks, but not an infinite number of them. This is automated if you have auto_chunk() set on your TilemapBuilder.

As the player explores, you listen for chunk creation events and populate the chunks appropriately.

Portals

Suppose you have two worlds connected by a portal where you can see into one from the other. This might be magic portals, or it might be like in some JRPGS where a shop is bigger on the inside than it is on the outside.

You could achieve this easily with the Option 2 in the Multi-screen worlds approach. You'd just stitch the data together correctly, update the tiles and away you go.

I am unsure how you'd achieve that otherwise. Multiple tilemaps? Use z-levels with sparse data?