Closed razcore-rad closed 6 years ago
I'm not a fan of adding this stuff to TileSet. For me it makes little sense that a kind of tile would have such functionality. If you want to trigger something, add an Area2D to the scene where the TileMap is. Maybe TileMap itself could have something like this, since when you're placing the tile you might want it to trigger something, but I can't see this on TileSet.
CollisionShape2D is saved (does save when converting to a tileset); it's just the positions (offsets) don't get updated which forces us to use a PolygonShape. Intended or a bug? I have no idea
@vnen, the reasoning behind having it on TileSet
is if you want to create procedural levels and for example (my specific case) in a rogue-like where you want to have a doorway to the next level placed randomly it makes perfect sense to have it as a tile and not as a property of the TileMap
itself, but I do get it why you'd want TileMap
to also have this functionality. I think both are good cases to be considered and it will improve a lot the functionality for procedurally generated levels.
I see lots of people expecting tiles to behave as if they were nodes, in various levels. I mean, having functionality nodes would provide, but on tiles, or tile types. The problem is that Tilemap is a special kind of node that purposedly batches things for a better performance into one node, at the cost of uniformizing every property of tiles (forced to use one optional sprite, one optional collision polygon, a few other stuff and that's it).
Because of this, any functionality on individual tiles that is not present has to be added by script with the use of a different paradigm (see my post in this other issue about tilemap: https://github.com/godotengine/godot/issues/5965#issuecomment-236334540).
In the case of Area2D, that could still be solved in a simple way with the current Tilemap, maybe add a collision type in tileset, and I agree it's useful. But it's not the first issue/question I see where people expect more about tilemaps, and this node could end up handling too much things. For a reference, here are the properties a tile type can have: https://github.com/godotengine/godot/blob/master/scene/resources/tile_set.h#L42 (I don't see any sound-related things or any custom properties. See? So much could be added :p)
Yes, it is true that the tiles aren't nodes, but I would have thought that Area2D is related to the other collision shapes and it makes sense to have it included as part of TileMap. Might be wrong and maybe it isn't as easy as I think but anyway. There you have it :)
I am creating a game like space shooter. So I wanted a tile that is destructible. Let's say that Space ship shoots a projectile and hits the tile it should be destroyed. Does this feature helps in this too ?
I think you can do this without that feature with a bit of scripting: on collision, get the impact point (either in the hit or with a short raycast if precision matters for you), get the collider (tilemap) and get the tile position using world_to_cell
. Then you can delete it. Note that even if tiles have areas you would still need the tile position.
This would be very useful for coins and other pick-up items.
I'm reviewing my issues and this has been opened for some time now and there are other people working on tilemap improvements so I'll close this for now and see perhaps after v3.1 if more discussion is needed.
Operating system or device - Godot version: v2.1.stable.official
I tried doing a
TileSet
with anArea2D
as a tile and it seems that the collision shape isn't saved when converting the scene toTileSet
. Now, I know you can have aStaticBody2D
with aCollishionShape2D
that hasTrigger
set toOn
, but I think it would make much more sense to be able to have a tile with anArea2D
, which I guess it isn't possible now? Or am I missing something? You may want to have tiles which trigger certain events but don't block player / enemy movement for example so in this cases it would make sense to haveArea2D
. I'm sure this isn't a big deal but it would be a nice feature to have since this is exactly whatArea2D
is supposed to do (among other things)... unless I'm missing something obvious :)