Add slope/neighbour-gradient query to TerrainGrid #27

New issue

Closed

opened 2026-08-19 06:35:46 +01:00 by liamjd · 0 comments

liamjd commented

2026-08-19 06:35:46 +01:00

Owner

docs/resource-prospecting.md says stone should be "richest against the side of a hill," and follow-up discussion settled that on the Quarry facility rather than a resource deposit: stone is extractable everywhere, but a Quarry may only be placed against sloped terrain (binary pass/fail, no yield gradient — deliberately dropping the "richest" framing from the doc). See #26 for the rest of that decision.

The gap

TerrainGrid (scripts/terrain_grid.gd) has no query that answers "is this tile against a slope." It tracks per-tile level_at(cell) and has neighbour-level-difference logic already, but only privately, inside _can_traverse()'s cliff check for pathfinding — not exposed as a general-purpose terrain query.

Scope

Add a public query (e.g. is_sloped(cell: Vector2i) -> bool) that checks whether any neighbouring cell's level differs from this one by more than some threshold.
Decide whether it reuses max_step_levels or needs its own separate, quarry-specific threshold — a slope steep enough to be interesting for a quarry site isn't necessarily the same steepness that blocks pawn movement.
Binary only, per the decision above — no richness/yield scaling by steepness.

Consumer

The Quarry facility's placement validation (not yet implemented) is the first and only planned consumer of this query.

`docs/resource-prospecting.md` says stone should be "richest against the side of a hill," and follow-up discussion settled that on the Quarry facility rather than a resource deposit: stone is extractable everywhere, but a Quarry may only be placed against sloped terrain (binary pass/fail, no yield gradient — deliberately dropping the "richest" framing from the doc). See #26 for the rest of that decision. ## The gap `TerrainGrid` (`scripts/terrain_grid.gd`) has no query that answers "is this tile against a slope." It tracks per-tile `level_at(cell)` and has neighbour-level-difference logic already, but only privately, inside `_can_traverse()`'s cliff check for pathfinding — not exposed as a general-purpose terrain query. ## Scope - Add a public query (e.g. `is_sloped(cell: Vector2i) -> bool`) that checks whether any neighbouring cell's level differs from this one by more than some threshold. - Decide whether it reuses `max_step_levels` or needs its own separate, quarry-specific threshold — a slope steep enough to be interesting for a quarry site isn't necessarily the same steepness that blocks pawn movement. - Binary only, per the decision above — no richness/yield scaling by steepness. ## Consumer The Quarry facility's placement validation (not yet implemented) is the first and only planned consumer of this query.

liamjd added the

enhancement

label

2026-08-19 06:35:46 +01:00

liamjd referenced this issue

2026-08-19 06:35:54 +01:00

Define resource deposit data model for ores and clay #26

liamjd added this to the Untitled Colony Builder project

2026-08-19 19:43:59 +01:00

liamjd referenced this issue from a pull request that will close it,

2026-08-19 21:44:41 +01:00

Wrote utility functions for neighbouring_cells() and is_sloped(). A slope is defined by neighbouring cells having a height difference greater than max_step_levels, but this value may need to change in the future. Claude provided the unit tests. #28