Add distance-to-water query to TerrainGrid #30

New issue

Open

opened 2026-08-20 05:43:44 +01:00 by liamjd · 0 comments

liamjd commented

2026-08-20 05:43:44 +01:00

Owner

Clay's placement rule from #26 is "low-lying tiles within N tiles of water." "Low" is already answerable from existing level_at()/datum comparisons, but there is currently no way to ask how far a tile is from water.

The gap

TerrainGrid (scripts/terrain_grid.gd) classifies a tile's Kind (including Kind.WATER) via _kind_for(level_at(cell)), but nothing aggregates that into a distance query.

Scope

Add a query such as distance_to_water(cell: Vector2i) -> int, returning the Chebyshev or Manhattan distance (whichever is cheaper to compute correctly) to the nearest Kind.WATER tile. Grid sizes are modest (default 64x64), so a straightforward flood-fill from all water tiles, or a bounded-radius scan per query, is fine - no need for anything cleverer.
Decide and document the return value when a preset has no water at all (preset.has_water == false, or has_water true but none generated) - e.g. a large sentinel or -1 - so the clay generation issue can treat "no water on this map" as "no clay," consistent with resource-prospecting.md's "not all maps will have clay."

Consumer

#31 (clay deposit generation) is the first and only planned consumer of this query, the same relationship #27's slope query had to the (still unbuilt) Quarry placement rule.

Clay's placement rule from #26 is "low-lying tiles within N tiles of water." "Low" is already answerable from existing `level_at()`/datum comparisons, but there is currently no way to ask how far a tile is from water. ## The gap `TerrainGrid` (`scripts/terrain_grid.gd`) classifies a tile's `Kind` (including `Kind.WATER`) via `_kind_for(level_at(cell))`, but nothing aggregates that into a distance query. ## Scope - Add a query such as `distance_to_water(cell: Vector2i) -> int`, returning the Chebyshev or Manhattan distance (whichever is cheaper to compute correctly) to the nearest `Kind.WATER` tile. Grid sizes are modest (default 64x64), so a straightforward flood-fill from all water tiles, or a bounded-radius scan per query, is fine - no need for anything cleverer. - Decide and document the return value when a preset has no water at all (`preset.has_water == false`, or `has_water` true but none generated) - e.g. a large sentinel or `-1` - so the clay generation issue can treat "no water on this map" as "no clay," consistent with `resource-prospecting.md`'s "not all maps will have clay." ## Consumer #31 (clay deposit generation) is the first and only planned consumer of this query, the same relationship #27's slope query had to the (still unbuilt) Quarry placement rule.

liamjd added the

enhancement

label

2026-08-20 05:43:44 +01:00

liamjd referenced this issue

2026-08-20 05:44:02 +01:00

Generate clay deposits by water-proximity rule #31

liamjd added this to the Terrain Generation milestone

2026-08-24 06:02:36 +01:00