INFO - Compatible engines

[di-effe]

Hi, I'm not sure if this "space" can be used for a generic discussion. If not feel free to delete this thread :)

Is there a list of engines / framework that can support ldtk maps out of the box or with documentation to import the maps with all the features?
Other than Haxe that atm is a bit our of reach for me :)

[deepnight]

LDtk being pretty new, there's no official importer except Haxe for now 🙂 I'll be soon looking for devs to support major frameworks, it's on the roadmap.

For now, if you wish to help, you should be able to write your own Json parser easily (the format is well documented and not that complicated) 👍

[di-effe]

I'm not able to guarantee a result (just an amateur here ^^=), but I can try to something for Godot.
As far as I know there will be limitations, but maybe I can figure out something basic for the tilemap and collisions.
There a few things ready for TMX but maybe it make more sense to work from your native format

[deranjer]

I have an experimental build for godot import. It pulls in the tilesets and auto-generates a grid of regions based on the grid size. Obviously missing a ton of critical features like autotile, and currently working on getting levels generated, but Godot seems to not want to create new scenes for me. I've never used Godot or built any 2D game in my life, so it is a little bit of a struggle.

Right now, just trying to get it so that we skip over transparent tiles and then if the tile is part of a saved selection, then Godot will treat it as one "region" (in Godot terminology). That should at least cover the very basics.

@deepnight Is there an example LDtk file somewhere I can download to see all the advanced features in use? I've also never done pixel art so currently just creating my own tilesets for testing.

Here is the repo, if anyone is interested. Obviously in extreme alpha: https://github.com/deranjer/godot-ldtk-import

[JoshLee0915]

@deranjer I actually just got a very rough importer plugin up and running tonight. It only loads tilesets and layers atm but if you point it at a LDtk file it will create a new 2D scene and the needed tilesets for the tilemaps. Once again its still very rough and I have not really tested it much outside of a one layer level, but could be handy for figuring the issues with your importer.

https://github.com/JoshLee0915/GodotLDtkImporter/tree/feature/GDScriptPlugin

I know the two things that got me was the tilesets are a bit of a pain to setup (had to dig into Godots C++ code to see how they where doing it) and packed scenes will not pick up child nodes if you do not set the owner property on the child node.

[deranjer]

@JoshLee0915 Looks much better polished than mine is at the moment. I will just fork yours I think. Tileset setup via the API seems incredibly poorly documented, I managed to google the answer to that, but really should be a summary of what is required in the documentation.

Setting the owner property also caused some issues for me initially at first, finally found some information on that.

So I'll fork yours and dissect it, then try and add "Saved Selection" from LDtk (looks like yours currently doesn't have that) and see what else can be done.

[deepnight]

If you have specific needs here, don't hesitate to ping me with your requests.

[deranjer]

@deepnight If you could provide me with a fully featured example file, I would love that!

[deepnight]

Sure, I can do that :)

[JoshLee0915]

Ya @deranjer that was an intentional exclusion on my side. I actually try to load the least amount of data I can from the tileset defs and I did not see a need to load the Saved Selection field since it gets flattened out in the layers anyway so I can still create the tilemaps by just referencing the individual tiles.

I am curious as to what in your use case may require that information if you do not mind me asking? I am mainly designing for the use case that a level designer would be mainly using this and not much modification of the map itself would be done in engine so have been focusing on only importing the minimum amount of info required to turn a LDtk file into a Godot scene.

[deranjer]

@JoshLee0915 But what if you have tiles like doors or something that span two grid tiles? In LDtk I can save those and then when I select it I can paste the entire sprite in one go... I don't see a way to define multi-tile sprites in LDtk and then have then transfer to godot. You would have to set that up again in godot (w/o Saved Selection). In fact you would need to delete what you had setup from import and re-edit it. I must admit again that I have zero experience with pixel/2D art or godot.

I do see your point though. I guess if you needed to make a quick change you could hop back into LDtk and make the changes, then export and re-import the entire thing. Just thought it might be nice to make quick changes directly in godot.

I randomly decided I wanted to make a tactical RPG like I used to play on GBA (Tactics Ogre) I had a few ideas about some new mechanics I might try out to make it interesting. Unfortunately all of my experience is with 3D and Unreal, but not well suited for 2D stuff. I thought I might poke around and learn pixel art, godot, gdscript and see if I thought it might be possible. I saw the video about LDtk and decided that would be a great starting point for level design since godot out of the box stuff for tilesets and level design did not seem the greatest.

I figured as I learned and the game developed I might want to make quick changes to the levels I had exported in godot, I wanted the import as a starting point and for setting up all the autotiles and tile general setup. Obviously I would still have to do collision and everything.

[JoshLee0915]

Ah I see your points @deranjer and it was kind of what I expected.

A few things to note is on the layer level when you place a saved selection in LDtk it seems to get flattened out to its individual tiles. So on a layer level there is no reference to saved selection 16 but instead tile 5 at grid [1,0] and tile 6 at grid [1,1] (assuming a 1x2 door for example). Also, while its only implemented well for the tilesets atm my importer will not overwrite scenes every time. I plan on having it update only the nodes required if the scene already exists which will allow for easier updating from LDtk. The reason I am taking this approach is the GDScript plugin is just a stopgap and I would like to integrate the importer with Godots existing asset importer so it can be imported like a .blend or .png file which will allow for auto updates when the LDtk file is modified.

That being said I do see your point with being able to make quick edits in engine. You can actually make something like saved selections by adjusting the region when you create the tile. Using your door example again if you have a door that is 1x2 and it was a 10x10px grid you would set the region to be 10x20 and that would give you one tile made up of those two tiles in Godot.

There are some limitations to note though

1. In Godot these selections must be continuous. I think LDtk allows for selections that do not have to be continuous and if that happens the best you can do is split it up into discrete continuous chunks.
2. There is a possibility of tile ID conflicts. You will need to ensure the ID you use does not fall into the ID range for any tiles in the existing tileset in LDtk and you may need to do some mapping.

Obviously I would still have to do collision and everything.

Ya, it would be nice if we could define things like that in LDtk. @deepnight may I ask if there are any plans to allow users to add metadata to tilesets like human readable names or shapes for colliders, ect? If not I would be happy to open an issue for discussing it as its a feature I think would be very handy.

[deranjer]

@JoshLee0915 Ah, thanks I didn't play around with godot long did not realize they had to be contiguous, I knew that was not a requirement in LDtk, although the tilesets I was creating did have contiguous pieces.

So if we have a tileset with a large tree in godot we would need to go and delete all of the regions that were autocreated on import, and create a whole new region if we wanted to add a tree in godot? I suppose if it is integrated directly in godot then who cares, just edit it in LDtk and it updates right away.

One other question I had, in my script it pulled the tileset image from the filesystem directly (via reading the JSON) and added it to res:// then used it there. seems like your script looks for it in the root? Any specific reason?

[JoshLee0915]

So if we have a tileset with a large tree in godot we would need to go and delete all of the regions that were autocreated on import, and create a whole new region if we wanted to add a tree in godot?

If I understand your question correctly the answer is no. Godot tilesets will actually allow you to define tiles on top of tiles. This is because as far as Godot is concerned tiles are comprised a 3 basic components (there are more actually but these could be reasonably considered the 3 base components)

1. An Id which is an integer
2. A texture
3. A region that defines the portion of the texture that tile should render

Due to this setup all tiles are 100% independent from each other. So using your above case you should be able to just add a new single tile and define the entire area of the tree even though the individual tiles are already defined by the importer. I should state I am 90% sure this is the case as I have done it with Atlas and Auto Tiles in the past though there could be some UI issues that could interfere with doing this with Single Tiles but it should work.

The one thing you still need to be mindful of is id conflicts but this should not be an issue unless you change the size of the tileset grid or the texture it uses in LDtk.

One other question I had, in my script it pulled the tileset image from the filesystem directly (via reading the JSON) and added it to res:// then used it there. seems like your script looks for it in the root? Any specific reason?

Yes, this is once again due to me wanting to eventually integrate the plugin into Godot's asset import system. The asset import system looks in the res:// directory for assets to import so I wrote the plugin with the same assumptions to keep it as in line with the current asset import system as possible. Also, it saves me some work by not having to worry about copying files around and I personally prefer the organization of having LDtk files within the Godot project proper.

[deepnight]

I have plans to export tiles in a more sprite oriented manner (ie. keeping group of tiles as objects and having custom properties over them). Related #68

[JoshLee0915]

Ooo I look forward to seeing what you have planned there then!

[deepnight]

I added a sample called Test_file_for_API_showing_all_features in dev-0.6.0 branch, but it will probably require latest GIT build. It uses latest JSON specs from git upcoming 0.6 version (see JSON_DOC from 0.6 branch)

Here it is:
Test_file_for_API_showing_all_features.zip

[JoshLee0915]

If this is not a good place for this @deepnight I would like to apologize ahead of time but my importer plugin for Godot seems to be in a rough but usable state for anyone who wishes to help test it our wants to use it. As you can see in these images here is the LDtk level

And here is the scene produced by the importer

The entity import will create new nodes using both instanced scenes and node class names. The reserved property _Node. Past that it will try to update any properties whose names match the properties on the LDtk entities.

While it is usable I have not done a release yet as I have a few more touches I want to do to it, including an issue pointed out by @deranjer, and I need to work on getting the docs ready.

Anyone wants to use it though you can find it on this branch.
https://github.com/JoshLee0915/GodotLDtkImporter/tree/feature/GDScriptPlugin

Quick side note, those odds lines on the tiles in Godot is a rendering issue in the editor. They go away when you run the scene.

[deepnight]

Closing as duplicate of #273