Godot-proposals: New TileSet editor and TileMap improvements

[KoBeWi]

Describe the project you are working on:
A platformer game with tiles.

Describe the problem or limitation you are having in your project:
Godot's tilemaps have few inconveniences and missing features. The biggest issue is that TileSets are lists of tiles and when you want to draw tiles you have to look for the tile on the list, which is seemingly randomly ordered and just awful to use. I actually made a proposal once about tile palette, but since it's being closed, I decided to use this chance to make a bigger proposal for some tilemap/tileset overhaul.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

• So first thing, TileSet should store a tile palette. The palette would have a configurable size (i.e. number of rows and columns), something like this:
  
  You'd create new tile by right-clicking a cell on the palette and selecting "New Tile" option and then selecting a texture region. This means the tiles wouldn't be bound to textures and texture regions, but rather each would have its spot on the palette, so the palette contains all tiles in the order you want it. When editing TileMap, the right panel with tiles would have a minimal width to show all columns of the palette.

• Would be useful if multiple tiles on the palette could use the same region, but be transposed/rotated. This would help with creating auto-tiles without duplicate graphics.

• Tiles should be able to be reordered or duplicated. Also each tile on palette could be selected and inspected normally, in case you want to do the transformations I mentioned in above point or some other customization.

  • To make creating multiple tiles for palette easier, the right-click menu would also have "New Multiple Tiles" option, where you could select a texture region and it would be automatically sub-divided into tiles and they would be added to the palette. Something like this
    
    This would be very useful for autotiles. See, instead of defining autotiles as single tile, an autotile would be created from multiple tiles in the palette and each tile could have its bitmask set normally. The reason for this is that you don't always want to use auto-tilling and when you disable it normally, you get the standard ugly sub-tile list, which would also be incompatible with the palette. When auto-tilling is enabled, selecting any compatible tile from the palette would create the proper tiles in "auto way". This gives another possibility: my biggest problem with current autotiles is that you can't do proper slopes. You either have normal edges or sloped edges, due to bitmask limitations. Recently this got an option to randomize tile with matching bitmask, but it's still meh. But what if the selected tile would be favored? You'd have corners and slopes on the palette, with the same bitmask, but the one selected would be favored, so you would get autotilling and flexibility in one.

• There should be a shortcut to disable auto-tilling, if there isn't one already. It would make fine-tweaking auto-tiles even easier.

• The atlas tile would become probably obsolete with all above features.

  • Another thing that was requested many times is having ability to define "scene tiles", so placing objects as tiles instead of instancing everything manually. I know there's a workaround to replace certain tile ids with objects, but it has two problems: it's inconvenient (you need to configure it in code) and the bigger problem is that each "scene tile" needs an icon. I mean they have to still be represented as tiles somehow, so either you use basic placeholder, which makes your level visuals different in editor or spend too much time making icons. So why not make it built-in? For this we need new tile type: scene tile. Scene tiles would have 2 main properties: the scene (basically PackedScene resource) and offset. Offset, because you need to somehow fit the object inside a square tile, so to position it more easily, you could set offset for each object. Obviously you can use nodes bigger than tiles, the offset only affects the origin at which it is instanced relative to tile position. When you draw the scene tile, editor would fetch the preview (it already shows e.g. when you drop the scene file onto viewport), so you'd see visually where the object will be placed in the game. Convenient stuff.

• This however creates a minor issue with being unable to configure the tiles (in case someone wants). The easier way to do this would be allowing to instance individual scene tiles, which would create instance of the node as a sibling of Tilemap. However for easy mass-configuring, each scene-tile should be able to override exported properties of the scene (it would be done in the palette), which is obviously the more difficult way.

• The scene tiles would be visible in the palette as auto-generated small previews, or node icons in case there is no preview. Users could override the icon too.

  • Collisions. Right now making collisions is annoying af. Having the palette means that we can... draw them. This is example from RPG Maker:
    
    In Godot, instead of circles and crosses, the tiles would either be blue or normal. Also we could place slope collisions and any other collision. Just make one polygon (or set a predefined one) and then draw it over other tiles like with pencil.
    This basically means that all interactions with tiles would be moved to the palette. The only thing done "outside" palette would be creating tile region. When tile has region (which can't be bigger than cell size, but that is irrelevant, check below), this region is drawn on the palette and then you operate on the tile in the palette. This basically allows things like drawing collisions over multiple tiles (internally of course the colliders would be polygons like now).

  • Multi-tile drawing. Having a tile palette makes this trivial to make. Basically when editing TileMap, select multiple tiles (by dragging your selection) and drawing would draw the whole selected pattern at once. This solves the problem of having "bigger tiles", so each tile could have same size without losing functionality.

  • Layers. I've seen it requested few times. The workaround is to stack multiple Tilemaps, but it's inconvenient™. You can't easily switch between tilemaps. Would be useful if TileMaps could have multiple layers and we would be able to easily switch between them, to draw background and foreground tiles more easily. The layers could have configurable z-index and collisions.

So this is my vision for new TileSet system. Related proposals that would this solve:

739 (drawing collisions would make it ultra convenient already)

265 (same as above)

352 (another collision issue, same as above xd)

310 (with easier tile selecting and auto-tile shortcut, this becomes non-issue)

88 (might be resolved by the same reason as above)

574 (might become irrelevant, because tiles would be unnamed and just part of palette)

771 (see the point about rotated tiles in palette)

893 (very similar to above)

It's possible I might not covered how all existing functionality could look in the new system, so feel free to ask. I actually have limited experience with Godot TileMaps, I took much inspiration from RPG Maker here.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Basically a rewrite of TileSet editor and partial rewrite of TileMap editor. The new TileSet editor would be more focused on tile palette and simplify the process of working with tiles, which instead of being some separate entities vaguely on top of some region, would instead be more organized and grouped/related together (if that makes sense).

EDIT:
I could probably put some mock-ups here in case the new editor is hard to visualize from the description 🤔

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Everyone would use it if it become the new editor :v

Is there a reason why this should be core and not an add-on in the asset library?:
The current tile workflow is meh.

[Beefster09]

I've just been using Tiled to edit maps and using the Tiled importer from the AssetLib. It also gives me opportunities to run some post-processing on it to generate a better collision map and some other automation.

[golddotasksquestions]

Can't we split this massive proposal up into smaller pieces?

The general "tile palette" approach is nice, but other than that I am a bit confused by this proposal. Besides the tile palette idea (which we already kinda have) this seems to be a completely new and different approach to Tilemaps compared to our current implementation. With completely new approach comes least as many questions and unclear UX UI flow for me.

Collisions:
The binary RPG maker example of this proposal would actually be a quite a substantial loss in very useful functionality we currently have.
The biggest problem with the current system is that you can't draw the shape over multiple tiles and that there is no pixel snap. (you would have to set the snap options to 1,1 as a workaround, then set it back once finished)

Layers: I see that only making UX UI even more complicated. I don't understand the difference/benefit over using multiple Tilemap nodes.

Improving the "paletteness" of the Tile selection panel would be fantastic, being able to preview Multitile Single tiles as well. Even though I quickly see this being a serious screen real estate issue if that is not a toggle-able or mouseover option. What's the point of seeing a 48 piece 3x3 minimal autotile all the time anyway or a 256 complete 3x3? Maybe drawing a few tiles in the tile palette is more indicative of what this autotile can do, rather than having a single tile icon, or the whole set that would just eat up all screen space.

[KoBeWi]

I've just been using Tiled to edit maps and using the Tiled importer from the AssetLib. It also gives me opportunities to run some post-processing on it to generate a better collision map and some other automation.

Well, if users used Tiled instead of built-in tilemaps, it would make them kind of pointless.

Can't we split this massive proposal up into smaller pieces?

It's split up into points 🙃

The binary RPG maker example of this proposal would actually be a quite a substantial loss in very useful functionality we currently have.

I mentioned that it's a mock-up image. Instead of drawing binary collisions, we would have a mix of both - you could make a polygon shape on a tile and then draw it over other tiles.

Layers: I see that only making UX UI even more complicated. I don't understand the difference/benefit over using multiple Tilemap nodes.

The difference is that when working in one node, it's easier to quickly switch between layers (could be done with shortcuts). Less nodes is also less overhead and more opportunities for optimizations, especially for drawing and collisions.
Although this is not a crucial feature, I didn't even plan to mention this in the proposal initially.

Even though I quickly see this being a serious screen real estate issue if that is not a toggle-able or mouseover option. What's the point of seeing a 48 piece 3x3 minimal autotile all the time anyway or a 256 complete 3x3?

This is a good point actually. The autotiles I used weren't really big, so in my case I'd want them to be always expanded. Maybe showing the autotiles and using auto-tilling could be two separate things (sort of like show grid/snap to grid).

But then we need a way to make it toggle-able without breaking the palette. The solution I can think of now is making the auto-tile fold/unfold like lines of code

[itsjavi]

what I miss the most is being able to select a group of tiles that will become a brush, e.g. a tree that is 16x32 pixels (2 tiles of 16x16) . Right now I need to select the bottom of the tree paint it and then the top. It is a bit painful.

Lines and rects are also basic things that are essential.

I agree that this should be maybe split into smaller proposals, to be able to focus the discussion better. One or two steps at a time is always good.

[MCrafterzz]

Lines and rects would indeed be super helpful

[MCrafterzz]

@KoBeWi are you working on implementing this or is it only discussion for now? Would be nice to have this for the 4.0 and 4.0 feature freeze is probably still a few months away so it should be possible 😜

[MCrafterzz]

Also it would be very nice if the snap options were in the acual tileset window instead of in the inspector, so that they are together with the other options. Having them in the inspector feels really strange and hard to find. Implementing it like the snapping in blend trees would be optimal:

[KoBeWi]

KoBeWi are you working on implementing this or is it only discussion for now?

No. I was thinking about making a prototype/proof of concept (maybe even in GDScript), but overall this is lots of work. I wonder if it could qualify for a work package.

[MCrafterzz]

@itsjavi apparently you already can do lines and rects its just that they aren't in their own tool. Use the paint tool + shift to draw a line and paint tool + shift + ctrl to draw a square. Moving them to their own tool would be nice tho as that would allow shift to snap the proportions of the square for example (keeping it as a square and preventing it from turning into a rectangle). Shift when creating lines could snap it to every 15 degrees or something. @KoBeWi what do you think of that idea?

[KoBeWi]

what do you think of that idea?

Sounds good. The default drawing tool could keep the current Ctrl/Shift functionality, but the dedicated line/rectangle tools could be an alternative with additional options (i.e. squaring/snapping). Maybe ellipse tool could be useful too? 🤔

[MCrafterzz]

what do you think of that idea?

Sounds good. The default drawing tool could keep the current Ctrl/Shift functionality, but the dedicated line/rectangle tools could be an alternative with additional options (i.e. squaring/snapping). Maybe ellipse tool could be useful too? 🤔

Yeah I feel like that would be useful. Keeping it in the drawing tool doesn't make much sence imo.

[abueide]

So after digging around the tilemap editor, tileset editor, and tileset resource, trying to implement some simple ux improvements I think I have a pretty solid plan of attack to solve most of my gripes with the tile map system, which I will be submitting PRs for. If the following solutions fail to address something important to you, let me know. If it's easy to do or if its something I'd want too, I'll try to add it. This solution set tries to leverage the existing systems in place as much as possible in order to lower the amount of work required. Also I'm new to C++ and the editor codebase, so I want to keep tasks small and byte sized while I'm learning.

Tile Map Editor

• Cluttered tile palette
  
  
  
  • PR #39862 adds tabs in the top palette to filter tiles by the sprite sheet they came from. Often times developers group related tiles into a single texture, so this PR just offers a way to utilize that organization.
  
  
• Support for selecting & placing multiple tiles at once
  
  
  
  • Simply replace the bottom palette (subtile palette) with the same grid view that is used in the tileset editor instead of using an ItemList. Selecting multiple tiles in the subtile palette should default to placing all of those tiles in the same shape that they're selected in the grid view, rather than the randomization mode that selecting multiple tiles currently defaults to. 2 tool button bars indicating what mode you are in (random vs multitile placement) should be introduced along with a shortcut to cycle between placement modes.
  
  
  • utilize new tool bar for existing placement modes (erase, fill mode)
  
  

TileSet Editor

• Issue 1 - Tile Translations. A tileset editor should be able to edit tilesets. I'd like to be able to move tiles around. Also this feature is required for the animated tile issues described below.
  
  
  
  • This wouldn't have any affect in the image itself, the translations would be stored in the resource file. We would add a tool button that would let you export the edited tileset to a png file. This is because users wouldn't expect the tileset editor to automatically edit their png file, so we need to make it explicit that they're saving it as a new file or they're overwriting an old file.
  
  
  • User should be able to select a group of tiles or a single tile. When dragged on top of other tiles it'll simply swap the places of those tiles rather than distorting the rest of the tileset.
  
  
• Issue 2 - Tons of tile animations are stored in a spritesheet, however the only workable solution for tile animations in godot is to have multiple pngs of the same tileset, except each png is a different frame of each tile's animation. Then you have to importe these pngs as an AnimatedTexture, then import that animated texture into the tileset. Manually placing each frame of each tile into the correct tileset frame is a very tedious and error prone process, and there are no tools out there to automate this process which is required to have a workable solution for animated tiles in godot.
  
  
  
  • Solution: Allow users to select multiple tiles and "crunch" them into a single AnimatedTexture. When exported, it will export the tile as n pngs, where n is the number of frames the user selects when creating a new animated tileset. If the animated tileset is not exported, it will save it as an AnimatedTexture inside the tileset's resource file using the translation mapping system created in the first issue.
  
  
  • Potential Issue - If a user crunches a tile into an animation of 3 frames, and then another one of 4 frames, the animation with 3 frames won't loop evenly. We wouldn't have anything to put in for the 4th frame.
  
  
  • Solution: Make the user select the number of frames when creating a new animated tileset, and only allow the user to crunch tiles with a number of frames that evenly divides into the tileset's number of frames. Then just loop to fill out the rest of the tiles.
  
  
• Issue 3 - Custom Tile Properties
  
  
  
  • Solution: Allow the user to create a dictionary that is mapped to any tile or subtile. Add a method in the tileset that allows the user to query properties given a key, and a tile id, and optionally a subtile's position.
  
  

[KoBeWi]

@abueide

Cluttered tile palette

I don't think this is an issue, at least it wouldn't be with my proposed changes.

I might repeat myself, but what I propose is for TileSets to have a palette (grid) of tiles. For each cell in the palette grid, you set the texture coordinates, collisions etc. so each cell is basically one tile. Since you organize the palette yourself and then in TileMap editor it appears exactly the same as you organized it, I don't think the clutter is relevant.

Support for selecting & placing multiple tiles at once

Already covered in the OP (multi-tile drawing point).

Issue 1 Tile Translations.

Also covered in the OP (I mentioned that the tiles should be able to be reordered).

Issue 2

I didn't use Godot's current animated tiles, so can't say much about it.

Issue 3

You mean one dictionary per tileset or per tile?

[abueide]

@KoBeWi

I don't think this is an issue, at least it wouldn't be with my proposed changes.
Already covered in the OP (multi-tile drawing point).
Also covered in the OP (I mentioned that the tiles should be able to be reordered).

I'm not opposed to your proposed changes, its just that it would take significantly more work to redesign around the grid palette. I posted my solution here, because you closed my other proposal. I'd be happy to collaborate with you on the redesign, but as new (to the engine & c++) solo dev I'm not confident enough in my skills for a complete overhaul yet. I've specifically picked solutions I think I can achieve in the next few months.

Also the one concern I have with your proposal is how you're going to handle overlapping tile regions. Like if I add a new atlas that overlaps with another atlas or autotile, then how do I pick which one I'm selecting inside of the overlapping region if we're using a grid view?

You mean one dictionary per tileset or per tile?

I mean one dictionary per tileset, but it basically acts as if one dictionary per tile. You pass in the property name and the tile id which get combined as the key inside the function and then you get a value back. E.g. 2 different tiles can have 2 different values for a movementspeed property, but its stored in the same dictionary.

[KoBeWi]

I'm not opposed to your proposed changes, its just that it would take significantly more work to redesign around the grid palette.

No if there's a way to quickly add and modify tiles.
btw you yourself mention a palette in your comment, we might have something similar in mind.

Also the one concern I have with your proposal is how you're going to handle overlapping tile regions. Like if I add a new atlas that overlaps with another atlas or autotile, then how do I pick which one I'm selecting inside of the overlapping region if we're using a grid view?

Each would occupy a different cell in the grid/palette.

E.g. 2 different tiles can have 2 different values for a movementspeed property, but its stored in the same dictionary.

This sounds a bit confusing, but I think I understand. Basically you want each tileset to have a set of tile-properties and each tile could define a value for each property. Makes sense I think, more optimal than my arbitrary tile metadata idea I had.

Uh, I think I should really make a GDScript prototype.

[abueide]

Yeah, my solution just replaces the bottom pane (for viewing subtiles) with the grid palette you're thinking of. It'd be easier to implement since you just basically copy and paste the one that's used in the tileset editor, then add in some selection code. And that way you can have unlimited overlapping regions on the same tileset without it getting messy, since the gridded palette shows only 1 region rather than the entire texture. In my view it hits all the sore points, but also wouldn't cause any breaking changes to existing tilesets.

[samsface]

Maybe a little off-topic but how I handle needing more complex phys shapes on specific tiles is by having an editor plugin that combines TileMaps and Node2D into a Palette and then I can paint both Node2D and TileMap tiles in the same workflow: https://github.com/samsface/godot-palette-plugin

[Avarobin]

I highly agree the tileset editor workflow is really horrible and it needs a rewrite. Biggest current issues:

• The tiles are ordered randomly and you can't arrange them.
• The current UI for the tileset editor makes tiles, selected tile, collision and etc hard to see.
• Adding collisions and other things requires a lot of clicking and it's easy to accidentally revert your atlases by clicking on their region.
• Adding animated tiles is a convoluted process, you need multiple pngs instead of being able to use a spritesheet and you do tons of clicking.