Creating and editing tilemaps

I was surprised to notice tileset / tilemap support seems to be a bit unclear and labeled as a new experimental feature. Apparently it exists but there’s no ability to edit tiles internally: I worked with Tiled before and am always happy to use it, but was still curious if an editor inside GDevelop itself will ever exist. Also if things like map format may change and break later thus I should wait, though I presume the Tiled JSON format will never be deprecated, ideally used by the engine’s own editor in the future.

The page I looked at also suggested you need to do collisions separately in GDevelop after exporting a map from Tiled. That part has me tempted to wait: I might make quite a few maps then edit them in the future, not sure if I should go for doing the extra work of drawing collisions separately, especially if their format may later change to allow defining them in tilesets.

Strangely enough this video from 2017 shows a tileset editor but I can’t find it in recent versions. They don’t mention it being an addon, seems to have been a core feature at the time. Was that removed at some point, or am I just silly and not able to find it in the new menus?

2 Likes

GDevelop 4 had a tilemap editor. But was also basically a completely different engine.

The engine was mostly built from scratch in late 2018 with GDevelop 5, and some items didn’t make the cut since the renderer was also completely changed. (now pixijs)

There are plans to bundle LDTK into the engine as a tilemap editor (I have a large bounty out on it, and someone has already shown interest), but that is on hold until LDTK file support can be implemented.

That is in progress, but is also pending changes by @davy on the main dev team, who is working on a slight rework of the current tilemap implementation as well as to support collision creation from the file.

Setting up collisions manually right now isn’t a huge deal, though. You can see how I did it in the Not-a-vania example in the main example list.

2 Likes

Thanks for the clarification, that explains it. Think I read something about that briefly but it seemed like a community initiative, so if’s an official plan that’s expected to happen.

And the format will be different too then… good to know. Might be best to hold off on making any real maps in this case, even if I start working on any project, though that may be awkward to even test.

Any timeline on when this integration is expected to happen? At least if it will be this year if that’s known? If its format is final, I can at least use LDTK separately till it’s fully integrated, as my main concern is something important that can’t be ported or upgraded changing in the future and requiring I redo all maps.

I wish I could answer this, but I cannot. I am unclear on when Davy will return to his changes, which means I’m unclear on when the LDTK format support being worked on by Blurymind will be next worked on.

Note: even if LDTK integration happens, making Maps in Tiled right now will not hinder you since you’ll still be able to import them.

What I personally do is make my maps in LDTK, export them as tiled TMX format, then import them into Tiled and immediately export them into json. I do this because I find LDTK’s ease of map creation substantially faster than doing the same things in Tiled. That’s me, though. :smiley:

2 Likes

Tiled and LDTK seem to both support JSON format, but I take it the two editors use a different structure and naming scheme internally? But if tilemaps will be able to define their own collisions in the future I’ll definitely want to make use of that, so if I worked on maps now I’d still need to redo them later for this reason. It seems my best bet is to hope there’s progress on this in the next release(s)… or find a way to store maps in such a way that I can easily re-export them once full support is ready.

Correct. JSON is just the wrapping structure/filetype. Both LDTK and Tiled use wholly different data structures, which is why LDTK cannot currently just export to Tiled JSON. My workflow is LDTK > Tiled TMX > Tiled > Tiled JSON because it only takes a few seconds to do the last 3 parts, and I find it faster to use LDTK to make the maps.

What I would say for right now:
Do not add collisions to your tilemap files right now. The requirements behind collision handling may be totally different than you think (you may have to use specialized naming, or special tags, or heck, polygons on an object layer rather than Tiled’s normal collision drawing).

Better to do it a way that will continue to work (Building the collision object in GDevelop and just stretching/copying it as needed) for now. This way you only have to update new maps once the update is out.

I recommend this because if you use the collision builder in Tiled right now, and then it comes out that each collision/tile has to have a very specifically formatted Tag, you now have to go back in to every tile on your map anyway (so all time spent building collision polygons in Tiled didn’t save you a lot of time).

2 Likes

Did want to ask one more question I realized I forgot in the meantime. To what extent should I wait for and use a separate tileset system, compared to just defining each tile as a sprite and placing it in the scene using the grid? Especially if I’m to use larger tiles and not have thousands of sprites per map?

I guess the first advantage to using a tilemap is everything being packed into one image which helps performance, followed by ease of editing such as being able to use brushes. On the other side, defining each tile as a sprite would let you do more with it such as giving each one custom behaviors: Imagine you want smoke particles always coming out of that chimney in one tile, or that other tile damaging the player if you touch one part of it, or another tile containing a jump pad that always throws the player in the air: The tileset system won’t allow such complex behaviors to be defined in tiles will it?

I’m curious which approach you think is best for which scenario. Should I wait for full tilemap integration, or is it good practice to just use sprites manually if you can and want full flexibility?

Tilemap will likely get you better performance, but in addition to that, placing tiles in a tilemap editor is usually going to be faster and more efficient than manually placing hundreds of sprite objects in the scene editor.

Additionally, if you use LDTK, you can set up auto-tiling rules pretty easily and literally just paint your map to have it fill in with the tiles you want. (Tiled has automapping as well, although it’s more of a scripting system rather than a visual rule set up).

True, thought of that hence why I’m undecided. But what I mean is: Will I be able to assign a custom behavior to every tile using the upcoming system? So for instance some tiles always produce certain particles at a given point, or place a light there, or have an ambiental sound at that location? I understand they’ll support collisions at least… even there though, can I filter the surface type of every tile for customized footstep / collision sounds and particles?

At some point, probably. There is a desire to enable using “entity” data from LDTK (and similar attribute data from Tiled), which is on a per-tile basis. I don’t know that there’s a specific timeline for that, or even a fully fleshed out plan yet.

More info here: How should GDevelop handle entities in Tilemap data from LDtk and Tiled · 4ian/GDevelop · Discussion #2836 · GitHub

Been a bit. Is there any news on progress with the builtin tileset / level editor? I’m still waiting for a final way to do those before trying to put much effort into projects. I know tilesets exported from Tiled work for now, but last I heard there would be a new format and I don’t want to work on something that will be deprecated later or is less optimal to do right now.

2 Likes