Quick and simple update to Bevy 0.9. Depends on the bevy_tile_atlas 0.5 PR I opened in your other repo. (I tested it using a git tag in cargo.toml) Adds Resource derives, uses spawn instead of spawn_bundle and uses handle.id() instead of accessing the field directly.

The main reason for this is to allow IDs be declared as constants without having to write out the full struct:

const MY_ID: TileId = TileId {
  group_id: 1,
  tileset_id: 5,
  auto_index: None,
  variant_index: None,
};

Which can be dangerous since auto_index and variant_index only exist with certain features enabled. It's also overkill if you just need to define the tile group and tileset. In which case, this new method is much simpler:

const MY_ID: TileId = TileId::new(1, 5);

Preparation for a standalone release of the current sub-crate bevy_tileset_map (formerly bevy_ecs_tilemap_tileset).

Includes major changes to the subcrate, such as the TilePlacer system param.

Adds serialization and deserialization support to bevy_ecs_tilemap_tileset. This is done through the new TilemapSerializer system parameter.

Saving

/// Assumes bevy_ecs_tilemap has already been properly setup to have tiles read from it
fn save_maps(serializer: TilemapSerializer) {
  // This saves all currently generated maps
  let maps = serializer.save_maps();
  
  // Write to disk using something like serde_json...
}

Loading

/// Assumes bevy_ecs_tilemap has already been properly setup to have tiles placed into it
fn load_maps(mut serializer: TilemapSerializer) {
  let path = FileAssetIo::get_root_path().join("assets/map.json");
  let data = std::fs::read_to_string(path).unwrap();
  let maps = serde_json::from_str::<SerializableTilemap>(&data).unwrap();

  serializer.load_maps(&maps);
}

This PR is built atop #2 and updates bevy_ecs_tilemap_tileset to support the Bevy 0.6 release.

Auto Tiling

Additionally, it abstracts the auto tiling functionality into bevy_tileset_core so that it may be implemented in a more generic way.

This is done through the AutoTiler. This struct takes in data related to auto tiles and generates a list of requests that the implementor should process.

The only thing an implementor needs to do to enable this default auto tiling is implement these three traits:

• TileCoords - Represents a tile's coordinates
• AutoTile - Represents the actual auto tile
• AutoTilemap - Represents the tilemap (but only in regards to auto-tiles)

With these traits implemented, the AutoTiler can be used alongside a Tileset to produce the auto tile output.

Update bevy_tileset_tiles, bevy_tileset_core, and bevy_tileset to support the Bevy 0.6 release.

Updates to bevy_ecs_tilemap_tileset will come in a separate PR as I also want to extract Auto Tiling and put most of the logic in the core crate.

✨ What's New ✨

TL;DR

• 📝 Tilesets can now be defined in RON files
  • Tilesets are now considered Assets, and can be loaded via the AssetServer
• 🧹 Cleaned up API
  • Removed the awkward event loading system
  • Exposed more internal code for finer control
  • Split the code into separate crates
• 🔐 Added the variants and auto-tile feature

Project Structure

Additionally, this project has now been split into multiple crates. All things related to tiles have been moved to bevy_tileset_tiles, the actual tileset logic has been put in bevy_tileset_core, and the integration with bevy_ecs_tilemap has been moved to bevy_ecs_tilemap_tileset.

This was done to split the code into contained boundaries so they would be easier to maintain and generalize. bevy_tileset_tiles was best suited for its own crate. It can now be used on its own apart from the rest of this project if anyone ever wanted to.

API Changes

Some more details on some of the major API changes (though most if has changed one way or another).

For loading tilesets, we've gone from this:

fn load_tiles(mut writer: EventWriter<TilesetLoadEvent>) {
  writer.send(
    TilesetLoadRequest::named(
      "My Tileset",
      vec![TilesetDirs::from_dir("tiles")]
    ).into()
  );
}

to this:

struct MyTileset(Handle<Tileset>);

fn load_tileset(mut my_tileset: ResMut<MyTileset>, asset_server: Res<AssetServer>) {
  my_tileset.0 = asset_server.load("my_tileset.ron");
}

In the first snippet, besides being slightly more verbose, we had to provide a set of folders to load tiles from. This forces us to keep all of our tile definition files in the same folders. It also means we can't have any other RON files in those folders so they're not accidentally loaded (I think it actually just fails and moves to the next file, but still not ideal).

In the second snippet, we move all of that logic and configuration to the actual tileset file, which looks like this:

(
  name: Some("My Tileset"),
  id: 0,
  tiles: {
    0: "../tiles/dirt.ron",
    1: "../tiles/grass.ron",
    2: "../tiles/wall.ron",
  }
)

Here, we give the tileset an optional name (a UUID string is generated otherwise), a unique ID, and a collection of tiles. Tiles are mapped by an associated ID key, allowing tiles to be added or removed without drastically affecting possible serialization.

Note: Serialization will probably be up to the implementation, but doing this ensures we make it easier to save and load tilemaps.

And while this is good, we're still sort of forced to use whatever the config file gives us, right? Well, this is why some of the previously private internals have been exposed as part of the public API.

This namely includes the TileHandle struct and its ilk. This means you can craft your own tiles at runtime:

let tile = TileHandle::new_standard("My Tile", texture_handle);

which can then be used to create a RawTileset via the existing TilesetBuilder. This RawTileset has nearly all the same methods as a regular Tileset but is not an Asset and has direct access to its TextureAtlas rather than just a handle.

Exposing this and making it easier to use, should allow users to more readily add, remove, and create tiles based on their own runtime logic.

Features

To help clean things up even more and to provide users with more control over what they actually need, a couple of features have been introduced.

The variants feature unlocks all the code related to Variant tiles.

The auto-tile feature unlocks all the code related to Auto tiles and also enables the variants feature.

If either feature is disabled, everything else will work as normal. Even loading tilesets that include tiles of disabled features will continue to load just fine— those tiles will simply be missing from the loaded Tileset.

🔮 Next Steps

Overall, I'm much happier with this code and will likely publish it. However, I will probably hold off on publishing the bevy_ecs_tilemap integration as I need to polish it up a bit more and I might also try to make a PR for it in its actual project.

Additionally, with Bevy 0.6 around the corner, a lot needs to be updated. So that will eventually need to be taken care of as well.