Alternative to TileSet custom data layers

[glossy ledge]

I'd like to make a tile system like you see in Fire Emblem games -- every tile has a type, movement cost, might heal or damage units, might have stat bonuses for units, and so on.

My first thought was to use a TileSet's custom data layers for this, but... it's extremely unwieldy. Everything is just accessed by magic strings, there's no typed autocomplete when fetching data layers, you can't use something like an enum (if you wanted an enum of possible "types" for example), and just seems annoying and unsafe to work with.

I would much rather define my own sort of "Tile" or "TileInfo" class with specific, safely typed properties specific to my game, then assign one to each tile in the TileSet... or something like that. The one nice thing about custom data layers is that you can paint them right onto the tiles in the editor, though, so I'm not sure how you would get something like that.

Anyway, it would be nice if I could just access properties with a simple dot operator. Like if the TimeMapLayer had a dictionary of coordinates and "Tiles", you could just do something like tile_map.tiles[Vector2i].movement_cost or something to that effect.

How would you approach this? Or would you just use the built-in custom data layers because it's better than I think? Is there a safe, more wieldy way of using custom data layers that I just haven't figured out? Custom data layers basically do everything I need, but it's just that they seem very prone to error when coding. Maybe I just don't know how to use them well.

[grand raft]

For using the custom data layers, it may be worth writing your own TileProxy class that does the nasty string lookups and type casting behind the scenes, while giving you a more friendly interface everywhere else. You would basically make a lookup call on a tile manager class and, in turn, receive a new TileProxy instance that wraps the index and TileMapLayer:

tile_proxy = tile_manager.get_tile(x, y, layer)
tile_proxy.movement_cost

Another approach is to use scene tiles with a TileEntity class attached as a child of each scene. The TileEntity class houses any properties of interest and self registers/unregisters with a tile manager's Dictionary[Vector3I, TileEntity] in enter/exit tree based on its position. For things like ground properties, where you would probably want to use a texture atlas and thus don't have any way to attach a TileEntity node, you would probably need to create dummy scenes so that you could paint properties representing that terrain. You get better type control with this approach, but it takes additional work in needing to paint an additional data layer.