You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am developing a 2D tile-based game where precise control over where tiles can be placed is crucial. The current TileMap system allows drawing tiles anywhere, which can lead to issues when designing levels with specific boundaries or when implementing terrain-based game mechanics that need to consider area limits as terrain boundaries (similar to GameMaker's implementation).
Describe the problem or limitation you are having in your project
Currently, the TileMapLayer in Godot 4.3 lacks the ability to:
Set specific boundaries where tiles can be drawn/placed
Consider these boundaries as terrain when using terrain tools
Prevent tile placement outside designated areas
This limitation makes it difficult to:
Create levels with strict boundaries
Implement terrain-aware tile placement near boundaries
Prevent accidental tile placement outside intended areas
Create tools that respect level boundaries automatically
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a new feature to TileMapLayer that allows:
Setting a rectangular boundary (Rect2i) that defines where tiles can be placed
An option to treat the boundary as terrain, making the tilemap consider cells outside the boundary as "occupied" for terrain matching
Automatic terrain matching when placing tiles near boundaries (when enabled)
This would provide better control over level design and improve the terrain system's behavior near boundaries.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
void TileMapLayer::set_cell(const Vector2i &p_coords, ...) {
if (!draw_limits.has_point(p_coords)) {
return; // Don't allow placing tiles outside limits
}
if (consider_limits_as_terrain) {
// Check if we're at boundary
// Apply terrain matching considering boundary
// ...
}
// Continue with normal tile placement
}
If this enhancement will not be used often, can it be worked around with a few lines of script?
While this could be partially worked around with scripts, it would require:
Constant checking of coordinates before placing tiles
Complex custom terrain matching logic
Manual handling of boundary conditions
Additional overhead for every tile placement operation
A script-based solution would be less efficient and more error-prone than a native implementation.
Is there a reason why this should be core and not an add-on in the asset library?
This feature should be part of the core engine because:
It extends fundamental TileMap functionality used by many games
It requires deep integration with the existing terrain system
Performance is critical for tile operations
It would ensure consistent behavior across all tools and scripts using TileMap
The feature would benefit from being maintained alongside the core TileMap code
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
I am developing a 2D tile-based game where precise control over where tiles can be placed is crucial. The current TileMap system allows drawing tiles anywhere, which can lead to issues when designing levels with specific boundaries or when implementing terrain-based game mechanics that need to consider area limits as terrain boundaries (similar to GameMaker's implementation).
Describe the problem or limitation you are having in your project
Currently, the TileMapLayer in Godot 4.3 lacks the ability to:
This limitation makes it difficult to:
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add a new feature to TileMapLayer that allows:
This would provide better control over level design and improve the terrain system's behavior near boundaries.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
If this enhancement will not be used often, can it be worked around with a few lines of script?
While this could be partially worked around with scripts, it would require:
A script-based solution would be less efficient and more error-prone than a native implementation.
Is there a reason why this should be core and not an add-on in the asset library?
This feature should be part of the core engine because:
The text was updated successfully, but these errors were encountered: