New TileSet editor and TileMap improvements #896
Comments
|
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. |
|
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: 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. |
Well, if users used Tiled instead of built-in tilemaps, it would make them kind of pointless.
It's split up into points 🙃
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.
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.
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 |
|
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. |
|
Lines and rects would indeed be super helpful |
|
@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 😜 |
|
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: |
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. |
|
@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? |
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. |
|
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
TileSet Editor
|
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.
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 didn't use Godot's current animated tiles, so can't say much about it.
You mean one dictionary per tileset or per tile? |
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?
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. |
No if there's a way to quickly add and modify tiles.
Each would occupy a different cell in the grid/palette.
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. |
|
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. |
|
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 |
|
I highly agree the tileset editor workflow is really horrible and it needs a rewrite. Biggest current issues:
|
|
The most annoying thing I find is the atlas one. For a temporary solution, it should be ordered exactly the same as the defined the area, like this:
For a permanent solution, |
|
@SysError99 This is already a thing in the new editor in 4.0, including property painting. This proposal is now obsolete, for any new feedback use #1769 (try a nightly build first) |
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.
The text was updated successfully, but these errors were encountered: