tiled
tiled copied to clipboard
mapeditor
Defold export Z value from layer order
After exporting to a defold tilemap the user must open the tilemap in defold and assign z values to each layer to have it match the order that was defined in the Tiled project to ensure the tilemap renders correctly.
The z value that a user would use here is somewhat specific to their project but generally Defold defaults to -1 to 1 for z range with -1 being far and 1 being near.
What would be the best approach to allow for the user to export directly from Tiled without the need to reset the z values of each layer on each export?
Considerations that come to mind are:
- Any sprite objects that need to render between tiled layers could effect the desired z value of each layer
- Defining a range for each layer... ie.e 0.1, 0.2 0.3 vs 0.0001 0.0002 0.0003
Would CustomProperties be a good solution here to override a z value and just have each layer default to some sane export z value based on it's order ad listed in the project layers?
Would CustomProperties be a good solution here to override a z value and just have each layer default to some sane export z value based on it's order ad listed in the project layers?
Ideally this is what we could implement. We just need to know what are sane defaults, as well as what happens to those defaults if one or more of the layers is manually assigned a Z value. It could either have no effect at all, or the ones that are left undefined somehow automatically sit between the others. The latter is what is implemented for the GameMaker export:
https://github.com/mapeditor/tiled/blob/b1450db8b6fd74d34227800d778b7bbc33bbd6a0/src/plugins/yy/yyplugin.cpp#L1253-L1294
Since I don't have much experience with Defold, hopefully you can help determine what would be a good approach to assigning defaults. :-)
Good question! :)
The War Battles Tutorial tutorial for Defold mentions setting your character to 0.1 to render above the tilemap, so leading with that I would recommend a range between [-1.0, 0.1).
Would it be counter-intuitive to start in the negative range counting up toward 0?
If the user can set a custom depth value on their lowest layer then we count up to determine the next value as in the implementation of the GameMaker exporter, it doesn't immediately seem like a bad idea.
Some ideas:
Something like -0.9 + 1000/1000 or x + y/1000 where x = starting custom depth, y = increment by 1 or 10?
If counting by 1 that is 1000 layers between -0.9 and 0.1 and if counting by 10 that is 100 layers.
Open to additional lines of thinking here though, not 100% confident in my suggestion.
Just a note, I noticed the "defoldcollection" plugin does already set some Z value by default. Maybe you could just switch to that plugin? Or is there a reason you need (or needed) to export only a .tilemap asset?
Just a note, I noticed the "defoldcollection" plugin does already set some Z value by default. Maybe you could just switch to that plugin? Or is there a reason you need (or needed) to export only a .tilemap asset?
I will check out the plugin and see if it works for my needs. TBH, I forgot why I was exporting the .tilemap asset directly, and need to revisit the project. Thanks for the heads up!
Ok, I've just added a simple assigning of incrementing z values to the Defold plugin, plus a way to override it with a custom property.
I've also extended both the Defold and the Defold Collection plugin with a way to set the tile_set property of the exported tilemaps. The Defold plugin only supports a single tileset per map, and you can specify it using a custom tile_set property on the map. The Defold Collection plugin supports multiple tilesets, and the tilesource matching each tileset can be set using a custom tilesource property on the tileset.
Hello, @bjorn ! Thanks for the plugin, but there is one issue with Z layers:
As said in docs:
A custom float property named “z” can be added to set the z value for each tile layer. By default, the layers will be exported with incrementing z values, so you only need to set this property in case you need to customize the rendering order.
But this code only in defold plugin, not defoldcollection. On --export-map it uses defoldcollection. And the custom property "z" for layer is not working now
But this code only in defold plugin, not defoldcollection. On --export-map it uses
defoldcollection. And the custom property "z" for layer is not working now
This change didn't affect defoldcollection, because the original author of the defoldcollection plugin had already coded a rather more advanced approach to automatically assigning z values. If needed I can of course add a way to override the z values also for that plugin, though I'm unsure how one overridden z value should affect other automatically assigned ones.
On --export-map it uses
defoldcollection.
Which plugin is used on --export-map depends on the file extension. If you export to a .collection file, it should pick defoldcollection and if you export to .tilemap, it should pick defold. Assuming you have both plugins enabled.
@bjorn Oh, thanks for your explanation! Yea it little bit more clearly now.
Yeah, i'm expected I'm able to override z value of top layer layers in defoldcollection like it's done in defold plugin. My case was: make tilelayer for example on layer 10 to draw this layer over all my game objects (Defold renderer and Z ranges can be adjusted inside Defold, not only [-1..1])
Do I need make another issue for that?
Do I need make another issue for that?
No, I've just added the ability to override the automatically determined z value per-layer (using a custom "z" property). But I didn't test it yet, so it would be great if you could give the resulting builds a try: https://github.com/mapeditor/tiled/actions/runs/3108223130. I'll still need to adjust the documentation before pushing to master.
@bjorn thanks, it works now! ❤️
It's work for tileset layers. But I need correct myself - in Defold for tilesets Z property is available only in [-1..1] There are some cases in Groups in *.defolcollection but it's can be handled by user export script now as I think