Split some of TileMapLayer's functionality into multiple nodes and add Tile Resource

[Dynamic-Pistol]

Describe the project you are working on

A remake of a Tilemap heavy game for youtube

Describe the problem or limitation you are having in your project

• The TileMapLayer node groups tons of mechanics together with some of those being unlikely to be used
• Since the physics is integrated into the node itself, this forces it Area2D's body_entered and other signals to use a Node2D since it can either be a PhysicsBody2D or a tilemap2d
• The navigation system is awkward to use and i am pretty sure each tile counts as it's own navregion
• Also navigation system seems to use Astar2D rather than AstarGrid
• Both the physics and navigation have multiple layers for some reason (possible left over from TileMap node?)
• Working with data is awkward and there is no support for different data per tile builtin
• Terrains are a weird name and also ugly to work with
• Some options are split between the tilemap and the tileset with some being for no good reason
• Also some of those options being debugging stuff that should be handled the same way as other nodes

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Split some of TileMapLayer's functionality in seperate nodes that can be children of it such as

• TileMapRenderer
• TileMapPhysics (also TileMapCollision if it's preferred to be seperated) (also extends either StaticBody2D or PhysicsBody2D)
• TileMapNavigation (defaults to Astar2DGrid but can also use Astar2D)
• TileMapData

Note: unless needed, these should not be Node2D and instead extend Node

now the user can use the parts of the tilemap they only need

also the debug options default to the setting like the other nodes

and there should be a Tile resource, with Tileset being a collection of those resources, this also could allow tile types like DualTile, AnimatedTile and much more

there should be a AutoTile resource that replaces the terrain system

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

First we create a TileMapLayer node, then create a Tileset resource

that resource would then require us to create tiles for it, we can assign a single texture for a single tile, an spritesheet for multiple/animated/auto tiles

when we place a tile, nothing will happen

to see something, we need to add a TileMapRenderer child, afterwards we can start seeing the tiles, but we can't collide nor navigate on them

to collide, select one of 3 modes

• NONE: the tile has no collision
• FULL: the tile has a square collision
• POLY: the tile has an editable polygon shape

and then place a TileMapPhysics child to get collision working

what if we want navigation? just tick the navigable property and add TileMapNavigation child

what if we want data for tiles? there are 2 types of data

• Per tile data: this is for the tile itself, like: is_indestructable
• Per cell data: this is for each instance of the tile, like: health

for the per tile data, you can either add metadata to the tile resource or inherit from it
for the per cell data, you extend the tile type you want and override init_cell_data(...) -> Variant

finally add a TileMapData child, and then use functions to modifiy the data

If this enhancement will not be used often, can it be worked around with a few lines of script?

The current system handles this already, but it is not ideal

Is there a reason why this should be core and not an add-on in the asset library?

TileMapLayer is part of the engine

[KoBeWi]

Related I think: #10572

[Dynamic-Pistol]

@KoBeWi not really, i saw that pr but it didn't match what i mean
this post really focuses more splitting TileMapLayer's work, with the tile resource being added only to handle the communication between the layers, not making TileMapLayer abstract with separate subclasses

tho 1 thing i really like of that post is the TileMapSceneLayer and i was thinking of a way to have scenes in tilemaps, this sounds nice since you could just have a packedscene array, but i didn't wanna add extra unrelated stuff to my pr

tldr: that post has nothing to do with what i want except a solution to a problem that could be caused by my pr

[KeyboardDanni]

The TileMap system needs some work, but I don't think this is the way to address the existing shortcomings.

• Both the physics and navigation have multiple layers for some reason (possible left over from TileMap node?)

I can see a use case for multiple physics layers per tile if your game has a plane-swapping mechanic. Might also want additional collision data for things like ladders and tightropes while still having the wall collision in the same tile.

• Some options are split between the tilemap and the tileset with some being for no good reason

There's often a reason you see options in one and not the other. It can be very inefficient and error-prone both for the end-user and the runtime to have everything controlled per cell in the TileMap versus simply looking it up in the TileSet. Are there any options you have in mind that you'd like to see in both?

and there should be a Tile resource, with Tileset being a collection of those resources, this also could allow tile types like DualTile, AnimatedTile and much more

This doesn't seem like the right layer of abstraction to me.

Generally, when it comes to a tilemap system, there's two things I personally look for:

• Is it efficient to make assets for and to make levels with in the editor?
• Is it efficient at runtime?

For some games I suppose there's also a third one: Is it easy to modify the tiles at runtime?

Right now, I think the current system handles the first two acceptably. Could be better, but for my purposes it works okay. I wish the terrain system was more flexible, and custom-paintable per-tile data would be nice. But it also has a lot of very useful features for editing.

Typical workflow involves making a tilemap atlas texture in Aseprite or similar image program, then creating a TileSet resource in Godot and assigning properties such as physics, terrain, and sorting to multiple tiles within the same view. Then a TileMapLayer is placed within the scene and tiles are painted from the TileSet.

As far as rendering is concerned, having tile data per-atlas means it is easy to batch lots of tiles into the same draw call, as we know that they all use the same texture (typically having separate textures means needing to use multiple draw calls, which is much slower).

Having a separate resource for every individual tile in a TileSet would cause problems both for user workflow and runtime efficiency. A typical tileset has hundreds of tiles, meaning you'd need to have a lot of tile resources cluttering the filesystem. It would also make it much more difficult to both import the tileset texture and adjust properties across multiple tiles. From a runtime perspective, there's more layers of indirection the CPU has to go through to lookup the information it needs.

Instead, I think it'd be more efficient to make TileSets "composable", meaning you could add or remove rendering, physics, custom data, or other properties across the whole TileSet. This makes it easier to work with in the editor, and it saves us from having to query individual tiles for what they need to support. Either the whole TileSet has certain functionality or it doesn't.

[Proggle]

Multiple physics layers are crucial if you have tiles that are passable to certain movement types.

For instance, if water tiles are impassable to land travel, but are passable to boats. Or if enemies can't get through some tiles and players can.

In addition, they also offer an option to make tiles interactable - for instance, a bush tile can be cut because it has a physics layer that a weapon can collide with.

Generally speaking, I think that godot should always have a more powerful tile system than the barebones one offered by rpgmaker.