Missing object fields

[rparrett]

In my tower defense game, I'm using objects in a hidden object layer in a few ways:

• To define PolyLines that enemies will follow
• To define properties for waves of enemies that will spawn
• To define the location and size of the "home base" health bar
• To define the locations on the map where the player may build a tower (and some associated properties)

I am using Tiled's "Object Types" to create templates for the properties of these objects.

Right now, I am using map.map.object_groups to access the tiled::Object because bevy_prototype_tiled::Object doesn't contain data about the object's type or size.

I need "type" so that I can differentiate these objects when iterating over all of them, and seemingly the size in order to properly position the tower slots.

https://github.com/rparrett/bevy_tiled/commit/70786579d54a2f3f8a90e21b803822077e320a62 is a change set that adds what I currently need.

I think this is technically a breaking change, so some discussion might be warranted.

The differences that currently exist between tiled::Object and bevy_prototype_tiled::Object seem sort of arbitrary. Should we add the rest of the missing stuff? Is it correct to use the provided map.map? Should we add object.object?

In the change set above I just added the minimum for my application and attempted to match the style of bevy_prototype_tiled.

[dmtaub]

Really interesting post -- I was literally just thinking about this problem and wondering about why we can't easily impl a trait on the tiled::Object that would provide methods to provide what we want to use.

I don't see how mirroring more properties represents a breaking change? That seems to be in keeping with the current library design, and I'm happy to include that commit if you need it.

I've been racking my brain to figure out how to retain the structure and API for tiled:: objects but add our own methods and extend them. Unfortunately, it seems like that approach isn't very Rusty. The only idea I had for a while is to clone the whole tiled::object, but it seems inefficient. Also, now I need the Tile/Tileset data, too, and that approach would start giving us multiple copies of those objects, which is even worse!

I'm starting to think the the best solution is a set of methods through the toplevel Map object that composes the tiled:: and crate:: objects in a convenient way...

[rparrett]

For anyone else observing or landing here, the previously mentioned change set was merged (#57) as a bandaid while larger api changes are considered.