It seems very nicely done :) Seems like the output format is custom (not the one from Tiled) so this will need an adapter I think.
Overall yes I think it would be a great addition - though we'll have to see how to make it seamlessly integrated (or as integrated as possible) to the existing scene editor.

I've created a card here: https://trello.com/c/yCXSSFFu/456-integrate-led-level-editor-inside-gdevelop-for-designing-tilemaps-levels-with-it

@4ian funnily enough, I've been using LEd since its newest update and asked the dev if they could output to the standard Tiled Json format.

They actually added it to their roadmap for 0.3.0.

In theory this would make it compatible with the work @blurymind
is doing.

Awesome! Making even more interesting to get this tilemap object working :) So we can start using it in games and see what's the best way to integrate an advanced editor like this.

if we could embed an external editor directly in gdevelop - as a tab, rather than a modal window - that could make it feel more integrated :) in any case if the developers make a tiled importer/exporter, it will save us the effort to write an LED importer

Just a heads up here for @blurymind and @4ian

LE-d has hit 1.0 and renamed to Level Designer Toolkit: https://deepnight.net/tools/ldtk-2d-level-editor/

I am thinking that the best way forward for this is to add the ability to parse LdTk JSON files to the tilemap extension.
The file data can be used to automatically detect if ldtk or tiled was used to create it - by the helper class.

From there on it can be sent to the correct parsing method.

Problems to overcome before ldtk can de embedded as an external editor:

• the concept of resource dependencies is missing in gdevelop. ldtk can have multiple tilemaps, each using multiple tilesets with multiple atlas images. All of their relative paths are in the ldtk json data, however gdevelop needs them all to be automatically added as new resources with the resource manager if they arent. Since we dont want the user to be manually selecting bazillion files which would lead to bad UX, gdevelop's tilemap extension needs to be able to handle this elegantly, just using the data it received from ldtk.
• a new parser for the ldtk json data structure needs to be added to the helper class of the tilemap extension

Potential alternative way to include LDTK in gdevelop is to make a new react component which wraps it - that way we could put it directly inside gdevelop as a new tab type and it will also work in the web version. Ldtk as a react component can be developed on a different gihub repository and added to npm as a module. This can attract more maintainers to it.

Potential alternative way to include LDTK in gdevelop is to make a new react component which wraps it - that way we could put it directly inside gdevelop as a new tab type and it will also work in the web version. Ldtk as a react component can be developed on a different gihub repository and added to npm as a module. This can attract more maintainers to it.

I agree.
Piskel was cool but open up in a new window is limited and break the immersion, i'am not fan.
With full integration of Ldtk in a new tab it will make this integration a lot better and multiplatform! Yay!

So, I've also posted over on the Pixi-tilemap Github about the possibility of adding LDtk formatted JSON support. I'm waiting for clarification from the maintainer as I'm not quite understanding his question.

Assuming that doesn't go through, if I understand correctly from @blurymind , this idea needs 3 things:

1. Wrap LDTk in a react component so it can show up as a tab in GD5.
2. Build a parser for LDtk JSON format to allow Pixi-Tilemap to ingest the tilemaps
3. Add Resource Dependencies or a way for GDevelop to properly understand the data/image sources from the LDtk json

Is the above accurate?
Is there an alternate for number 2? (Such as doing something that transcribes Tiled TMX to JSON since LDtk can already output to that format?)
Is there an alternate for number 3? (Such as instructing users that multiple-tilesets are not currently supported?, or something in the tileset object that shows the related resources?)

If the above are all accurate, is @4ian okay with me opening up a bounty on this?

Wrap LDTk in a react component so it can show up as a tab in GD5.

This is more or less the ideal situation yes. Unsure how doable it is, because it would need also disabling a bunch of LDtk feature that we would not need (some configuration settings or these kind of stuff that would not be relevant for GDevelop).

Is there an alternate for number 2? (Such as doing something that transcribes Tiled TMX to JSON since LDtk can already output to that format?)

I think we could as well handle directly as you said the LDtk JSON format, because it's not that complex and may be better than triggering a translation to Tiled TMX, then to Tiled JSON, all of this to finally be able to open it.

Is there an alternate for number 3? (Such as instructing users that multiple-tilesets are not currently supported?, or something in the tileset object that shows the related resources?)

In a first version, we can add some limitation to the LDtk supported features. Like one tileset, or separately export tilemaps maybe.

If the above are all accurate, is @4ian okay with me opening up a bounty on this?

Feel free to do so! Note that this kind of task seem actually more complex than actually adding the initial Tilemap object that we currently have (so that everyone has an expectation on the complexity of this).

Hey all, while it's not as large as I'd like it to be right now, I've started the bounty for this effort here: https://www.bountysource.com/issues/93298046-idea-add-new-externral-editor-to-edit-tilemaps-ldtk

@4ian, @Bouh, or @blurymind (or someone who can): Can we rename this to "Idea: Integrate/Bundle Level Designer Toolkit (LDtk) into GDevelop as a tilemap editor" or something similar? Just want to clean up the title for the bounty.

Updated, thanks! :)

I'd say lets investigate with the ldtk developer if we can get it as a react component. He might be willing to assist in some way or even engage this feature, since its marked as a milestone feature on the tracker there
deepnight/ldtk#126

General heads up, I was able to bump this up to roughly where I wanted to start it at. The bounty is now at $150: https://www.bountysource.com/issues/93298046-idea-integrate-bundle-level-designer-toolkit-ldtk-into-gdevelop-as-a-tilemap-editor

The bounty has been re-opened, and I've boosted it up to $200

https://www.bountysource.com/issues/93298046-idea-integrate-bundle-level-designer-toolkit-ldtk-into-gdevelop-as-a-tilemap-editor

@blurymind As a heads up, looks like a new version of pixi tilemap is out. Sukant pinged me about it on pixijs/tilemap#109 (comment)

Not sure if it's something that can help with stuff if we update.

Edit: Oops, he pinged you too. 😄 Either way, thought I'd chime in here.

Hey @blurymind, how is the development of this implementation? What about Tiled collisions? Any updates?

Thanks for the update @blurymind

I agree that Tiled Collisions will likely need to be a separate PR/bounty/etc. Honestly I think Intgrid and enums in LDtk are a much bigger boon than the collisions from Tiled at this point. With Tiled Collisions, you only save a few steps of drawing out your collisions with a single object.

With Enums and IntGrids, if we get the logic/events added around them, we could literally build out things like enemy paths, spawn points, checkpoints, etc.

Obviously this is all my opinion, but something I'd likely put out another bounty on someday.