Godot: Suggestion: Tile node for Tile Maps

[Lucrecious]

I really like the TileMap node so far - it's very useful, I just think it lacks a little bit of flexibility.

Let's say I have a game wherein walking on grass is slower than walking on dirt - picture a top-down racing game or a 2D side-scrolling game like Speedrunnerz.

From what I understand, right now, the only way to differentiate between tiles (whether the player is standing on them top-down or a Raycast2D is colliding with them) is by getting their ID. This is fine until you have more than one type of grass tile and more than one type of dirt tile - then your dictionary keeps growing and growing. It ends up difficult to maintain because TileSets themselves change a lot as development progresses.

---

My idea is to have a Tile node that inherits from Node2D, this would make the Tile node a sort-of meta node used only for converting a Scene into a TileSet. A Tile node contains a "Properties" panel. You can add a property of a specific type (bool, string, int, float, etc) and give it a value (similar to variable exporting in GDScript). If the character is standing on a tile, you can get the properties associated with that ID.

That being said, it'd be better if RayCast2D's get_collider() (and other colliders) would return the Tile node it's touching instead of the TileMap. If the user wants to access the TileMap, they could do so by a reference on the Tile node, let's say.

The Tile node adds some extra flexibility. For example, a user could create a Tile node with just a collision shape for its child; i.e. they could have tiles dedicated for collision (this isn't so far-fetched). Right now it seems like you must tie a Sprite with a CollisionShape2D even if you only need the CollisionShape2D.

I think the addition of a node like this could be pretty useful. I don't think it'd use much more memory than what TileMap already uses. In terms of CPU consumption, I think it would increase negligibly with collisions (since get_collider() would need to return the Tile node instead of the TileMap, but this seems like a simple math calculation).

Any thoughts?

[Zylann]

There has been an issue already where it was discussed to expose the existing custom Object properties, so that nodes in a tileset design scene could benefit from it, without the need for an Editor-only node.

However I remember a feature was merged recently, allowing tile properties to be set, in the TileSet editor (once you have a tileset, double-click on it and you should see an "autotile" dock)

I believe Tileset design scenes are a quick workaround to create tilesets, not a real tileset editor, it's a matter of time until we get one, slowly^^

[puppetmaster-]

If you are coding in Godot 2 you can test the new experimental Branch on my TilesetHelper Plugin.
The plugin adds predefined properties (3 at the moment) to each tile.
In the latest version (not commited) it is even possible to define your own properties.

[Lucrecious]

@Zylann this custom Object properties feature hasn't been implemented yet, right?

[nobuyukinyuu]

I noticed this has a 3.1 milestone on it. I ran into an issue recently when adding support for palettes to individual tiles where this kind of thing would definitely help. Right now I'm using a tool script to generate multiple copies of the same texture in a tileset, each with the properties I need (in this case to set the palette), and plan on making a separate tile editor to handle this situation in a way that's less obtuse to the people making the maps. Being able to set the properties of an individual tile would be great, but if this would create performance issues, I'm happy sticking to the soltuion I've got.

Would @Lucrecious 's suggestion be helpful for implementing animated tiles as well? I noticed that this appears to be a planned feature, but I'm not sure how it's going to be implemented.

[vnen]

For animated tiles it would be simpler to create an animated texture type (which can be based upon a ProxyTexture). In fact, I think you can already use a ProxyTexture with an AnimationPlayer to create that effect.

[akien-mga]

Since we're in feature freeze for Godot 3.1, moving to the next milestone.

[pixeltao]

That being said, it'd be better if RayCast2D's get_collider() (and other colliders) would return the Tile node it's touching instead of the TileMap.

I just want to reiterate on that bit mentioned by @Lucrecious . Also, being able to get a specific tile node with intersect_ray() via GDScript would make these types of collision routines simpler.

[Zylann]

Personally I would like too to get which tile is hit by a raycast. It's possible already (world_to_map on the hit), but not obvious, although there are other times where you care more about the hit layer than the specific tile too. However, not necessarily have it as a node, again because of the implication that every tile would have to be an actual full-fledged node. This sounds nice but it's not necessarily wanted as a technical solution due to the overhead instancing individual nodes would represent on large maps.
In Unity tilemaps can actually have both systems: you can have single sprites or full prefabs in every cell, so that having both cases is still possible, but I'm not sure how they handle collisions in depth.

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!