I just developed a Tiled JSON parser for Rust, and it is working (save for a few trailing commas in JSON format) but I noticed the JSON format is a lot more verbose. Forgive me in advance, I’m very new to this:
Map stores Layers, but so does objectgroup in Tile, but objectgroup requires no id? Will Tile.objectgroup match a layer in Map.layers?
It seems also that the XML and JSON versions don’t really match up 1 to 1–each class has substantially more fields in JSON. Why is that?
Finally, does JSON receive first-class support along with the XML version or should I focus on an XML version?
That’s great! What’s up with those trailing commas?
No, the objectgroup stored on a tile is a stand-alone object layer used to store the collision shapes associated with a tile. It doesn’t have a layer ID and is not part of the map.
Their version is manually incremented when there are significant changes and generally to match the corresponding Tiled release. I would advice not to rely much on the version though, and if necessary rely on checking whether a certain property exists. Only the JSON format changed in a backwards-incompatible way so far with version 1.2.
The JSON format may seem to include more properties because it includes many of them even if they have their default value, whereas the TMX format is more consistent in leaving out these attributes. In the end they both store the same data.
JSON and TMX are both considered first-class formats that store everything. Additions in new versions are always added to both of them.
Thank you so much!
I wish I had started asking questions sooner with your first-class responses.
It is good to know that the layer in Tiled.objectgroup doesn’t require ids. I am probably going to load it with different rules to enforce id on map.layers at least.
The trailing commas occur in some of the Tiled JSON maps I have found over the internet. I am resolved to run through the file at once and remove trailing commas for ergonomics.
I am able to serialize data as well. I have been using it for testing the deserializer (imagine all the wasted time), but I have not implemented wang sets and will ultimately remove it from the library based on the response to this question: are wang sets generally considered useful during runtime of the games?
For games that load full maps designed within Tiled, wang tile data is not useful. However, it is useful for games that procedurally generate maps on the fly. Such games may load only the tileset and use its data, or they may load maps and the tileset, using the map as a template or guide within which procedural generation happens.
The latter is definitely a much less common scenario, and even among procgen games, many won’t use wang sets. So, whether you parse that data depends on how thorough you want your support to be. Do you want to target ALL use cases, or just the majority of them? If you do decide to parse wang tile data, make sure it’s optional. Since most games won’t need it, it would be a waste of resources to parse and store it.
I was under the impression that much of the data would be unnecessary for different games and in order to reduce memory consumption when it matters people would then translate the useful information to more compact structures.
Much of the challenge is coming up with useful ergonomics while my understanding is so limited: I just started with Tiled days ago and haven’t even opened the editor yet. Just curious as to how I want specifically Layer to reside in memory because Rust has really powerful enum types.
I will load wang sets, but making it optional might prove to lack ergonomics compared with C-- conditional compilation is achieved only through command-line arguments or, I believe, cargo.toml.
Indeed, the layer IDs are not required at all. The reason they have been added is for external tools to be able to associate external data with a layer and to keep that data connected even when the layer is renamed, moved or grouped: