feat: Export maps

[benni-tec]

Description

This adds the ability to export maps as well as import them into json and tmx formats

Checklist

• [X] The title of my PR starts with a [Conventional Commit] prefix (fix:, feat:, docs: etc).
• [x] I have read the [Contributor Guide] and followed the process outlined for submitting PRs. --> melos run analyze returns a lot of fatal infos, however they do not orginate in this PR
• [ ] I have updated/added tests for ALL new/updated/fixed functionality. --> Not yet. There are tests for encoding tile layers and some basic checks for maps, I can write more extensive tests if needed, however this will take same time as my exams are comming up shortly!
• [x] I have updated/added relevant documentation in docs and added dartdoc comments with ///. --> I would gladly provide some more documentation however I did not find a place for it, similarly there does not seem to be any documentation for the parser
• [ ] I have updated/added relevant examples in examples. --> I will get to this soon, but would appreciate some guidance on my other questions and code?

Breaking Change

• [ ] Yes, this is a breaking change.
• [x] No, this is not a breaking change.

Related Issues

• #71

I have taken the liberty to rebase this branch to the current state of #77 as to integrate the new types introduced there!

[benni-tec]

This is a huge CL and I'm only half way through with it. I'll probably want more eyes on it than just mine.

Sorry, this is my first real PR. What does CL mean? 😅

Question: what's the motivation for exporting Tiled data? Are you building a Tiled Map Editor in Flutter/Dart? Is it for saving modified maps in game?

Well I wanted to build a game with flame_tiled however the tilesets I'm using are HUGE but I only use a small subset of them, so I wrote an optimizer in dart. In hindsight it would have been smarter to use another language, altough I could not find a tmx-library that can export apart from python (which is horribly inefficient) and C++ (which I'm not proficient in) I think!

[jtmcdole]

Sorry, this is my first real PR. What does CL mean? 😅

ah, sorry, "change list"; its the same as PR / Pull Request!

[jtmcdole]

Well I wanted to build a game with flame_tiled however the tilesets I'm using are HUGE but I only use a small subset of them, so I wrote an optimizer in dart. In hindsight it would have been smarter to use another language, altough I could not find a tmx-library that can export apart from python (which is horribly inefficient) and C++ (which I'm not proficient in) I think!

Could these be extensions on top of the classes that would then be optional for anyone else? It sounds like a neat project.

[benni-tec]

Could these be extensions on top of the classes that would then be optional for anyone else?

I don‘t think it is possible to achieve this using extensions, since they can not implement classes/interfaces and therefore it would be impossible to build an export tree.

Using extensions could work if I recreate all classes, use extensions to convert to them (this would require a huge amount of boilerplate code) and then build a separate hierarchy. However that would require a lot of effort to implement, double the required space while exporting and make it hard to maintain (keeping track if changes in this repo)!

I don‘t really see why this couldn’t just stay in the main package, is there any particular reason?

[jtmcdole]

I don‘t really see why this couldn’t just stay in the main package, is there any particular reason?

Maintenance.

You could totally do mixins since you're not really adding any values to the classes that are there solely for rendering.

extension TileLayerExporter on TileLayer {
 // all things exportable
}

extension ChunkExporter on Chunk {
ExportElement export() {... code}
}

There's no boilerplate; it just keeps the base classes cleaner for the 99% case of consumption.

side note; I think you mean implements Exportable instead of with. I thought "with" was for mixins. I guess there's not actually a compile here / warning here, so that's neat.

[benni-tec]

side note; I think you mean implements Exportable instead of with. I thought "with" was for mixins. I guess there's not actually a compile here / warning here, so that's neat.

Actually no, I'm using the Exportable abstract class as a mixin, this way the mixin implements ExportResolver, with it's exportXML() and exportJson() which is needed for the export tree by delegating to the ExportResolver that is provided to the export() method of Exportable.

This way I can just pass the object into the export tree insted of having to call x.export() every time.

abstract class Exportable implements ExportResolver {
  /// Returns the proxy usually an [ExportElement]
  ExportResolver export();

  @override
  XmlNode exportXml() => export().exportXml();

  @override
  JsonObject exportJson() => export().exportJson();
}

There's no boilerplate; it just keeps the base classes cleaner for the 99% case of consumption.

That's also where extra boilerplate code would come from when doing extensions, so I would prefer it to be included here. However if you do not want to maintain it, I can create an extension package for it. Altough I don't think there is actually going to be much maintenance since (as far as I unterstand) the tmx standard is actually pretty old and does not change anymore!

[spydon]

the tmx standard is actually pretty old and does not change anymore!

It is pretty old, but it does still update: https://doc.mapeditor.org/en/stable/reference/tmx-changelog/