An implementation of bevy_tileset for
the bevy_ecs_tilemap crate.
All features from bevy_tileset, including:
As well as features specific to this crate:
This crate is still not publicly released yet as I might want to make a PR to try and integrate it directly
with bevy_ecs_tilemap, but for now you can use it with git:
```toml [dependencies] bevytilesetmap = "0.4"
bevy_ecs_tilemap to your project!bevyecstilemap = "0.5" ```
For info on how to define and use tilesets, check out the README
for bevy_tileset. This crate re-exports the entire crate under the tileset submodule.
To use this crate, make sure you add the following to your app:
```rust use bevy::prelude::*; use bevytilesetmap::prelude::{TilesetPlugin, TilesetMapPlugin}; use bevyecstilemap::prelude::TilemapPlugin;
fn main() { App::new() // ... // bevyecstilemap .addplugin(TilemapPlugin) // bevytileset .addplugin(TilesetPlugin::default()) // bevytilesetmap .addplugin(TilesetMapPlugin) // ... .run(); } ```
With the
serializationfeature enabled
With this crate, serialization is very simple (as long as your tiles are generated using tilesets).
Simply add the TilemapSerializer to your system:
```rust /// Assumes bevyecstilemap has already been properly setup to have tiles read from it fn savemaps(serializer: TilemapSerializer) { // This saves all currently generated maps let maps = serializer.savemaps();
// Write to disk using something like serde_json...
} ```
And deserializing is just as simple:
```rust
/// Assumes bevyecstilemap has already been properly setup to have tiles placed into it
fn loadmaps(mut serializer: TilemapSerializer) {
let path = FileAssetIo::getrootpath().join("assets/map.json");
let data = std::fs::readtostring(path).unwrap();
let maps = serdejson::from_str::
serializer.load_maps(&maps);
} ```
Check out the serialization example to see how we turn some JSON into a full tilemap. Again, as long as you set everything up using tilesets, it should work pretty much as expected.
Note: This feature is very barebones and partially experimental. If things aren't working like you want, feel free to submit an issue or PR about it!
One of the nice features about this crate is that it provides some built-in tile placement/removal logic so you don't have to! This can easily be accessed using the TilePlacer system param.
rust
fn place_tile(mut placer: Tileplacer, /* ... */) {
// ...
placer.place(
tile_id,
tile_pos,
map_id,
layer_id
);
}
Easy!
Plus it comes with other variants the place method (with all the same properties). So give them a try!
While bevy_tileset adds the ability to define Auto Tiles, this crate actually puts it to use.
Using the aforementioned TilePlacer system parameter makes handling auto tiles a breeze! Besides simply handling the placement code, internally this handles multiple things related to auto tiles:
AutoTile componentIf you decide you want to do this manually, make sure you properly handle the placement/removal process. When placing you must add the AutoTile component (so the AutoTiler knows it exists). And when you remove an auto tile, make sure you send a RemoveAutoTileEvent event (otherwise surrounding auto tiles won't know to update).
Just remember that auto tiles can be slow, so thousands of them may result in lag when first placed (this can be mitigated by avoiding very large batch placements). However, once placed, they don't need to be updated anymore, so it shouldn't affect performance after that.
Check out the examples for bevy_tileset for tileset-specific
examples.
bevy_ecs_tilemap
and bevy_tileset_map| bevy | bevytilesetmap | | ---- | ------------------------ | | 0.6 | 0.4 | | 0.5 | 0.2 |
The main reason for this is that those crates are meant to be generally used, whereas this one is meant to be more specific in usage: it's for those who want to use both crates together.