Giving tiles a property dictionary

[timschellenberg]

One very, very basic TileSet functionality that I believe to be missing is a simple dictionary to hold miscellaneous data, which other nodes in the scene can then read to be aware of how exactly they should treat the tile.

I've personally seen this feature in almost every single tilemap implementation I've seen and think it's pretty essential.

To give you an idea of what exactly I mean, we can use Tiled as an example:

This tile, I would like to hurt any character that touches it. Of course, I'm not expecting the tile itself to run this code or be aware of anything, but for my characters to be able to see a tile they are colliding with and check its property dictionary for an "ontouch" value and do whatever that value tells them, in this case run a routine to hurt the player.
Another example I would actually like to use is, can you see that ice block on the left of that image? I gave it a property of "friction" with the value 0.3, which I would like to be able to read from within the game to adjust my character physics while walking over this tile. (This friction value isn't related to the built-in physics engine, it's just for my own KinematicBody physics handling.)
These applications are I think the most important reasons to implement something like this, just because I think it's actually impossible to get this sort of effect in Godot in any way at the moment, because these rely on the tile's own collision shape. The only workaround would be to completely strip the tiles' collision shapes and manually place TileMap independent staticbodies that can handle this interaction, which is... not optimal. Error-prone, inaccurate, cumbersome, all the bad things.

Similarly, I may want to run a script on level-load that places an object, such as a particle emitter, over specific tiles. It would be very helpful if I had some way to communicate to that script what type of particle emitter should be placed, and that one should be placed at all via these tile properties.
I realize that this example in particular could be done manually by hand, but so could a lot of things that a game engine is there to alleviate!
Another issue with doing it by hand is the much higher chance to make mistakes or to forget placing something.

I've seen people recommend to check the tile number in the TileSet resource and act on that, but I personally am not very happy with how inflexible this suggestion is. I may have different TileSets with different tiles in the same tile number slot, because a dozen tiles used in one TileSet would make no sense to even have in the other, so if I were to go by tile numbers then I would have to insert a lot of empty tiles just to make it fit.
Not to mention how hard to manage such a system would be in a bigger game, as well as its unintuitiveness.

The TileMap node and its lack of features is easily one of Godot's biggest 2D weaknesses, which is why I find myself having to resort to external tools (Tiled) to design my maps, and while it's absolutely no shame for an editor feature in an all-purpose editor like this to lose out to a specialized tool developed for exactly this use in terms of comfort and usability, it's not a great feeling to be stuck without a way to actually implement any sort of game logic inside the game based on a TileMap, something that even Tiled thought of.

Thanks in advance to anyone who may consider this idea, it'd really make me very happy if this were to actually be implemented eventually, especially since I personally feel like it's actually not that complex of a change!

[LikeLakers2]

What this makes me wonder is if there'd be any good way to have tiles inherit properties from other tiles, or perhaps from the TileMap node itself. It'd be nice to, for example, have the TileMap node set default properties for all tiles within it, and then have individual tiles override those defaults if they need to.

Imagine making a Minecraft clone with this feature -- as an example, all tiles might need to have a walk_speed setting that defines how fast the player moves over it, but only some will need to change it from its default. It would be nice to have the TileMap implement the default value, and then only have it overridden for specific tiles.

[timschellenberg]

I don't think that would be very needed. Default settings could be handled through anything ranging from level settings, other nodes, assumptions when the per-tile setting is missing etc.

On top of that, the TileMap node and the TileSet resource are definitely very different in function, there wouldn't be much sense in terms of organization for the TileMap node, which simply handles populating the scene with tiles, to hold any further information about these tiles or the TileSet.

At most I could imagine seeing that in TileSet, but even there I don't think it's terribly useful other than for very minor convenience.

[Zylann]

If tiles were a resource, it would have been easy to just add a script of yours on them, in which you can put whatever you like :p

[LikeLakers2]

First off, I didn't actually mean to confuse TileMaps and TileSets. But that's my bad for mixing the two.

Second, I'm not sure how it would be only a minor convenience. If you only have a few tiles, sure; but after a while, after you've added a lot of tiles to a TileSet, having a way to set the default for all of them rather than going through one by one would then be considered a possibly major convenience. Perhaps I'm not considering the reality of how TileSets are actually used? I'd still like to hear why you would consider it only a minor inconvenience, though, as perhaps I'm missing something.

Third, you mentioned using other nodes or other methods of creating a default properties list. While I won't deny that there is other ways, I'm not sure why you mention those options -- doesn't using one of those options contradict the point of custom properties being an option in the first place?

[Zylann]

I just had an idea:
You could make a tool script that you attach to the TileSet resource (yeah, you can do that, every Object in Godot can have a script :) )
In this script, you would expose a variable number of properties, one per tile, through usage of get_property_list. You can even have global properties if you like.
This way, for every tile your tileset contains, you will be able to have an inspector to set their properties. You could even go further and add custom editor panels (with EditorPlugin API) to edit these properties in a more convenient way.
Then, in the game, you could retrieve those properties by writing tileset.tile_get_property(tile_id, "walk_sound"), where this function would actually be implemented by your script. WDYT?

[LikeLakers2]

I may be misunderstanding slightly, but I'd like to make sure I get the basic idea. Are we talking something like this sort of setup?:

• Attach script to TileSet resource (however you do that)
• Script contains a tile_get_property method that checks if the specified tile has the property you want
  • If it does, it returns the value of that property
  • If it does NOT, it returns a default value, or otherwise null

Is this correct? Because if it is, I can see why it would work as an alternative and I could see it working, but once you get into creating your own editor panel, that to me feels like something that should be handled by whatever built-in editor panel will already be handling custom properties.

[Zylann]

@LikeLakers2 you can do this without custom panel, just exporting vars in the inspector (with _get_property_list since you may have variable number of tiles). But if you want more, like having a visual selector or something more friendly, you can use the EditorPlugin API to do it, because using only the inspector could be too limited. This is exactly what TileMap does for example, to show a list of tiles on a left panel.

Then, if the scripted feature becomes great and popular enough, you will be able to port it to C++ with no hassle and have it merged into the engine ;)

Not saying it shouldn't be done, just pointing the fact that adding game-specific properties to tiles is currently doable with scripting :)

[LikeLakers2]

Talked with @Zylann over Discord because I realized that I was having a hard time understanding his replies and figured a chat interface would help that a bit. I think I understand the suggestion for a tool script now (primarily I was confused over what was being suggested), though this still leaves me wondering why the primary suggestion for this is a tool script. Using a tool script would work, but it just feels sorta wrong for this purpose, so I'm going to stick to my suggestion for TileSet having a default properties dictionary that all tiles within that TileSet would inherit and be able to override.

EDIT: As it turns out, this whole debacle may have been a sort of misunderstanding. Whether from my side, Zylann's, or both, I think we both just misunderstood what the other was trying to do. Woops!

[Zylann]

Just had another idea, maybe the scene-to-tileset exporter could make use of this #11384 ?

[timschellenberg]

@Zylann I've actually already implemented something similar to what you're suggesting into my workflow as outlined here, but that is an approach that only really works by using a custom importer like that, since you can't set meta data on nodes through the editor interface itself yet.
It's a viable workaround until this exists in the editor in some form, yes.

@LikeLakers2 I was saying that having these default values on TileSet wasn't especially needed because any script that may want to access these custom tile properties could handle the default case itself.

Picture something like my earlier "friction" example, where tiles communicate different friction values to bodies that come in contact with them. Ranges from 0 to 1, we want a default of 1.
A code snippet to grab this value now would simply be something like this, where tile_id is the ID of our tile in the TileSet resource:

var tile_friction
if "friction" in TileSet.get_tile_props(tile_id):
  tile_friction = TileSet.get_tile_props(tile_id).friction
else:
  tile_friction = 1.0

Now every single tile that does not have a friction value explicitly set will assume that it wants to have a friction of 1.
At least, that was my original standpoint. I slept over it and now would agree that having a per-TileSet default value is useful, as for example some TileSets used for ice stages might just be more slippery by default, without now having to set the friction lower on each tile individually.

Also off-topic, but seeing your name surprised me a lot, I remember you from wayyy back on SMW Central! Small world.

[LikeLakers2]

@leoddd Eyyyy. I barely use SMWC anymore. But anyways.

Sleepiness does a lot to you, eh? If we're in agreement that a per-TileSet default is useful, then I'd also like to make it a point to have a way to figure out if we're getting a default value or one specified by the tile. Perhaps I'm asking for a little much now, but it would allow for any single script to easily use its own override just like different TileSets can have their own defaults. We could perhaps have a function that only ever returns what's explicitly defined in a tile's properties. Something like this (look at the second and fifth lines for the changes):

var tile_friction
if "friction" in TileSet.get_tile_props_list(tile_id):
  tile_friction = TileSet.get_tile_props(tile_id).friction
else:
  tile_friction = 0.8

In this context, get_tile_props_list only returns a list of custom properties that are explicitly defined for a tile, ignoring all defaults (for example, returns {"friction":0.5}). get_tile_props, on the other hand, takes the defaults and merges them with what's explicitly defined for a tile (returns {"friction":0.5, "solid":true, "sound":null}). So in this example, if friction is explicitly overridden by the tile, we will use that value, otherwise we will use a hardcoded value in the script. (There's probably a better way to implement this, but this example gets my point across.)

I'm unsure what the use cases for such a thing would be, and thus unsure how useful this would be, but I'm sure some developer will find a use case, so having some easy way to figure it out rather than forcing the user to work around such a limitation themselves would probably be pretty useful. Plus, I don't imagine it would be too much trouble to implement either.

[timschellenberg]

I don't know how useful that would be either. I guess that decision would just be left up to whoever would implement it in the end?

After reading through some related issues, I realized that one thing preventing this from being implemented is that there currently is no way to actually edit dictionaries through the Godot Inspector, which I am not sure what the status on that is as of right now (#12015).