Remove editor specific code in favor of including them as basic examples.

[StarArawn]

I've had a lot of people ask me very similar questions along the lines of:

How can I access tiled/ldtk data on load.

I don't mind answering those questions, but I don't think bevy_ecs_tilemap should support things like:

• Collisions
• Tiled map editor objects
• Backgrounds
• Non tile map stuff.

Which makes me think that the ldtk/tiled features should be removed in favor of using clearly defined examples.

Why examples?

1. Less complexity. Tiled/LDTK are level editors and as such they provide a lot more data specific to the game you are making. As such its almost impossible to support all the different ways people will use loaded data.
2. The code for the tiled/ltdk loaders are very small. Moving them into well documented example files allows users to learn how that data is loaded in and how to create the tile maps using bevy_ecs_tilemap.
3. If I support collisions for example it locks bevy_ecs_tilemap into a collision library. I would like to avoid that at all costs.

I want to reach out to the community first before I go ahead and make this change. Anyone who wants to voice any concerns/comments feel free!

Reference issues:
#82
#80
#21

[alice-i-cecile]

I'm in favor of this: I think it's much clearer and more obviously extensible. Your arguments for keeping the scope of bevy_ecs_tilemap small are good, and this will better communicate your goals.

[IceSentry]

I support that too. Keeping the scope small is a good idea.

Also, this would open up the possibility of making a crate for tiled or ldtk that supports other features of those libraries and simply use bevy_ecs_tilemap as a kind of rendering target.

[joshuataylor]

Hi!

Sorry, I'm pretty new to the game development paradigm, so excuse my ignorance.

With regards to collisions, would having layers be a thing (ground as a layer, then another layer), then you could use something like rapier/heron for hooking into entities on a layer that need this?

From my research into Unity, their tilemaps can have colliders on them, which I guess would be a "layer"?

[alice-i-cecile]

With regards to collisions, would having layers be a thing (ground as a layer, then another layer), then you could use something like rapier/heron for hooking into entities on a layer that need this?

Yep, the general pattern to follow here will be to give the tiles that you want to collide with some sort of Collision component, and then use a third-party physics library that consumes those.