Godot-proposals: Improve GridMap and TileMap

[PranavSK]

Describe the project you are working on:
This proposal is for any game that would need a grid-based level editor.

Describe the problem or limitation you are having in your project:
The current implementations of TileMap and GridMap are a bit of a black box, although internally they use the same core concepts achievable via existing nodes. While it may seem to simplify things it actually loses a lot of the flexibility afforded by the node-based approach of Godot. This also affects the UX and how it is designed as it does not fully take advantage of Godot's best feature.

Describe the feature/enhancement and how it helps to overcome the problem or limitation:
To better understand what the issue is we can look at what TileMap and GridMap try to provide:

1. A grid-based level editor.
2. Ability to paint the required mesh, sprite on to the scene.
3. Facilitate a modular approach to using assets. Potentially reuse or replace assets easily.

With this, we can also group some possible extensions a user might need:

1. Different types of grids - cartesian, hexagonal, Voronoi etc.
2. Custom paint functions - auto place tiles based on neighbours, scale the mesh instead of placing, auto-create a quadtree or octree from mesh (terrains for eg.), use mesh-instancing etc., or a combination of these.
3. Provide for an easy workflow to create the modular asset library from external tools, preprocess assets to be used in modular level editing as per game/tool requirements, create tests on import to assert valid modular assets etc.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Keeping the above in mind we can have the following:

1. A new resource called Grid. This would enable wrapping the custom grid using the cartesian coordinate system used internally by Godot. The core engine does not need to know actual conversions between the coordinate systems, Any custom grid types would extend and implement this the Grid class.
2. A new editor-only resource called Brush. This could be made available to runtime for supporting runtime level editors. These are dependent on the Grid resource (A brush needs to store the grid type it can work on). There are two main functions in the Brush resource - one to do instantiation/placement and another to resolve the asset to use.
3. An editor that uses these brushes to paint assets. The editor would work globally but resolve contextually i.e, it doesn't need a particular node type to exist in the scene but changes based on which node is selected.
4. A brush palette/library. This would also be stored globally and allows selecting a brush to use with the above paint tool. The brushes are grouped based on the grid. They can further be grouped based on the instantiation logic or based on the asset it places. This could be customizable by the user. The actual UX of creating this needs to be discussed. We could have a default brush per grid type (eg. a simple instantiate on the grid position). Any '.tscn' file could be dragged onto the library and brush is created using the default for that scene.

The idea here is that the brushes and the library depend on the grid, unlike the current approach where the library is more generic. This I believe makes more sense since the modular assets are generally created by keeping the grid in mind. With the ability to use custom grids, the library can still be used in different ways. Also by making the library global (per project) we can have a more unified place to organize them. This should also simplify the UX.

This approach would keep things intuitive in the Godot sense. It is also possible to make UX more unified with regards to level editing. We could also use this as a base for future editors (for eg. terrain editing). It is also easily customizable and a modular approach to level editing tools. Asset creators could provide grids or brushes and extend on other brushes easily. External editors that understand the Godot node-tree don't need to be retrofit to work in parallel with the level editor tools.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Not really but, when implemented a lot of the custom level editor tool creation can be simplified.

Is there a reason why this should be core and not an add-on in the asset library?:
It is a rethinking of existing implementation to provide for improved and customizable UX.

[Wavesonics]

I've used both Tilemap and Gridmap a lot, and I came up against a few stumbling blocks, I don't know if we'd want to address these, but here's a list for discussion:

• Assets of different cell sizes in a single Gridmap: I generally have "ground" tiles which are larger (8x8) and then "features" that are smaller (2x2) which means I need 2 separate Gridmaps overlayed on top of each other. It sure would be nice of they could live together.
• Tiles with different collision groups: This is a big pain at the moment. I would like to be able to define different collision groups for each Tile if I like. Right now I need to have separate Gridmaps for each collision group. It makes sense I think for each tile to know what group it should belong to, not for the Gridmap to decide.
• "Entity Tiles": Currently if I want to have something that's more complex than just some geometry/collider, then I need to go outside the Gridmap completely. I realize this is definitely outside the scope of the original Gridmap concept, but it would be a huge step forward to being more of a level editor if I could at least attach scripts to a Tile, or better yet, make a scene into a tile that can be painted into the Gridmap. This would allow for unlimited flexibility and could probably solve the level editor problem for a lot of games.
• Hide floors above X: There is some code in the current Gridmap to hide "floors" above a certain number, but it's not fully implemented. This would be a great feature to actually implement! So when your 3rd person view character is on floor 1, you hide for 2 so you can see him.
• Occlusion Culling: I know Gridmaps are already rendered efficient, but for some use cases it doesn't cut it. What ever the new Occlusion Culling system is going to be in 4.0, it'd be really great to have a way to implement it for Gridmaps as well.

[Calinou]

@Wavesonics It's probably better to create one proposal per requested feature (after searching for duplicates). This way, they can be discussed independently.