A generic Tilemap and a Tile trait

[thorlucas]

I started playing around with potential solutions to both #4 and #143. In my mind, these issues are linked by the following idea: a Tilemap should simply be a generic container that stores arbitrary objects which are able to return a sprite atlas index and an optional tint color. It is up to the user how much data space should be stored across each tile. For example, users might choose to have Boxs for larger / dynamically sized data attached to only some tiles (a TileEntity). It might look something like this:

trait Tile {
    fn get_index(&self, /* ... */);
    fn get_tint(&self, /* ... */);
}

struct TileMap<T> where T: Tile {
    ...
}

And a user might implement it as

enum MyTile {
    Grass,
    Dirt,
    Chest {
        locked: bool
    },
    Frobnicator(Box<FrobnicatorTileEntity>),
}

impl Tile for MyTile {
    fn get_index(&self, /* ... */) {
        match &self {
            // you get the idea
        }
    }
}

There are a couple problems here (in no particular order):

• Perhaps there should be support for having TileEntitys as actual Bevy entities so it's easier to interact with them from systems. This would involve spawning and despawning the appropriate entities with the chunks, which would involve some more complicated way of storing tile entites. Probably just each layer could have a HashMap<Point2, SomeTileEntityHandle>.

• In order to be useful, the get_index must be passed in a reference to the Tilemap or at least a structure containing its neighbors (for autotile support and or more complex use cases). I could see this potentially getting finnicky with the borrow checker which is a good indicator that there might be some more fundamental problems with this sort of architecture.

• There would need to be some way to cache the render parts obtained from each tile and to regenerate each tile individually if it updates. Similarly there would need to be a way to signal that a tile should be updated. Most probably either a TileEntity or a regular old system could issue an Event that a tile should be updated.

• This sort of data layout is less efficient for conversion to its render parts. Although this is not a big deal if the render parts are only initially calculated on spawn then individually updated per tile update.

• We then have the issue with autotiles needing to update if their neighbors change. If we are simply passing in a whole &Tilemap to get_index, then there is no way to know what sort of changes this tile needs to listen for (without some much more complex event listener system). If instead we pass only the neighbors (some sort of Neighbors struct), then it is much easier -- we can just call get_index again for each neighbor tile of an updated tile. But now we're more restricted in what we can do in get_index. I don't think this is an issue though because I think the vast majority of games only have immediate neighbor-based autotiling systems.

• I noticed that removing a tile in some cases simply sets its tint alpha to 0 for efficiency reasons. I don't love this approach as it exposes this sort of implementation detail to user implementors of the Tile trait. Perhaps a fn hide() with a default implementation is in order?

Any thoughts on any of this? Should a different approach be considered? Overall, I like this approach because it makes the tilemap way more flexible for user needs and doesn't assume too much about user use case.

[lee-orr]

I'd actually suggest having the TileMapLayer be generic rather than the full map - that would allow you to, for example, have a standard sprite layer and have a layer with additional data on top of it without needing to manage 2 maps.
I also think this should support both sparse and full data layout forms - for example, a game might have "zones" where all tiles have an associated zone, or you might have a 3D tile map where a layer serves as a height map of some kind, that is then used by a separate visual system.

[thorlucas]

I also think this should support both sparse and full data layout forms

Currently bevy_tilemap already does this!

The suggestion to make the layers generic is good. Do you suggest the user would pass in a Box<impl TilemapLayer> then?

The issue is any of this would require a pretty heavy rewrite since currently everything is coupled together a little too tightly. The systems responsible directly need to access the color and index data from the individual Tiles as of the codebase right now. For example, when a tile is removed, it's alpha channel is actually set to 0 (which I think is a problematic/hacky way to handle it).

[joshuajbouw]

Oh no another heavy rewrite hahaha.

The tiles being set to 0 alpha is fine, actually. In the shaders if its set to 0 it actually tosses the vertex entirely.

[thorlucas]

Oh no another heavy rewrite hahaha.

The tiles being set to 0 alpha is fine, actually. In the shaders if its set to 0 it actually tosses the vertex entirely.

I'm aware of this but I don't like that the layer is directly accessing the Tile data to do so, as it:

1. Might mutate things in an unexpected way for the user.
2. Couples Tile heavily to Layer, making it more difficult to swap out for other Tile formats.

After thinking about it for a couple days I think it may be best to maintain an internal copy actually of the so called "tile attributes". These would be fetched by asking the generic tile what its color is, whether its hidden, and what index to render. This could be stored in a way that would very efficient to pass to the gpu (as I think it is already). In fact this could probably just be identical to what it's already doing with RawTile.

The difference is now we would have a different set of tiles which would actually be the "source of truth". When an update is triggered, we'd need to go through and call .get_tile_index(...), .get_color(...) (optionally implemented), and .is_hidden(...). If .is_hidden(...) is true, then we could set the RawTile data to alpha 0. Or additionally in order to handle tile removal rather than simply hiding it, we could have this "source of truth" tiles be Options.

This might also be an easier option in terms of writing, because we could keep all the code that already exists for rendering, and just put in new code to trigger a refresh of the RawTile map when updated.

[joshuajbouw]

Are you in the bevy chat? Hit me up @joshuajbouw

[thorlucas]

yes I am!