Add Deposit and ResourceDeposits classes for resource placement #29

New issue

Open

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

liamjd commented

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

Owner

`DepositType`

A Resource, not part of Deposit itself - authored, shared config data (display name, colour for visualisation, flavour text), identical for every deposit of that kind on every map. Same pattern as TerrainPreset: one .tres per type under something like resources/deposits/ (e.g. iron.tres, clay.tres), loaded via load() and referenced rather than duplicated. No enum of resource types anywhere - adding a new resource later is authoring a new .tres, not touching an enum or a switch statement.

`Deposit`

A plain RefCounted, not a Resource - a deposit is transient, per-map generated output, not authored/shared data the way DepositType or TerrainPreset are. Fields:

type: DepositType - a reference to the shared, authored resource above, not an enum. load() returns the same cached instance every time (see terrain_grid.gd's note on this under next_shape()), so == comparisons and type-filtering work the same as they would against an enum value.
footprint: Array[Vector2i]
richness: a single flat value for the whole deposit

No per-cell richness variation and no discovered/revealed state field. #26 leaves room for both (the dot-grid richness gradient, and a reveal/fog-of-war mechanic), but neither has a consumer yet, so adding the fields now would be speculative. They can be added when something actually needs them.

`ResourceDeposits`

A class of its own, sibling to TerrainGrid rather than a responsibility bolted onto it - TerrainGrid already owns terrain shape/seed lifecycle and is busy enough. Holds Array[Deposit] and exposes basic query accessors (e.g. deposits at a cell, deposits of a given DepositType) - enough for the two placement issues and any future consumer, without guessing ahead at what mining or sensors will eventually need.

generate(terrain: TerrainGrid, map_seed: int) is called by game.gd immediately after TerrainGrid.generate(), mirroring the existing seed-handover pattern (TerrainGrid deliberately doesn't generate in _ready() so its owner can hand over the run seed first - same reasoning applies here). This issue can leave generate() as an empty placeholder; #31 and #32 are what actually populate it.

References

#26 (deposit data model decision). Depended on by #31 (clay deposit generation) and #32 (iron deposit generation).

First implementation slice of #26's deposit data model, scoped to just enough to get two resources - Iron and Clay - modelled. No placement algorithm here; this is the data type and its container only. Ore and clay generation land in separate issues that build on this one. ## `DepositType` A `Resource`, not part of `Deposit` itself - authored, shared config data (display name, colour for visualisation, flavour text), identical for every deposit of that kind on every map. Same pattern as `TerrainPreset`: one `.tres` per type under something like `resources/deposits/` (e.g. `iron.tres`, `clay.tres`), loaded via `load()` and referenced rather than duplicated. No enum of resource types anywhere - adding a new resource later is authoring a new `.tres`, not touching an enum or a switch statement. ## `Deposit` A plain `RefCounted`, not a `Resource` - a deposit is transient, per-map generated output, not authored/shared data the way `DepositType` or `TerrainPreset` are. Fields: - `type: DepositType` - a reference to the shared, authored resource above, not an enum. `load()` returns the same cached instance every time (see `terrain_grid.gd`'s note on this under `next_shape()`), so `==` comparisons and type-filtering work the same as they would against an enum value. - footprint: `Array[Vector2i]` - richness: a single flat value for the whole deposit No per-cell richness variation and no discovered/revealed state field. #26 leaves room for both (the dot-grid richness gradient, and a reveal/fog-of-war mechanic), but neither has a consumer yet, so adding the fields now would be speculative. They can be added when something actually needs them. ## `ResourceDeposits` A class of its own, sibling to `TerrainGrid` rather than a responsibility bolted onto it - `TerrainGrid` already owns terrain shape/seed lifecycle and is busy enough. Holds `Array[Deposit]` and exposes basic query accessors (e.g. deposits at a cell, deposits of a given `DepositType`) - enough for the two placement issues and any future consumer, without guessing ahead at what mining or sensors will eventually need. `generate(terrain: TerrainGrid, map_seed: int)` is called by `game.gd` immediately after `TerrainGrid.generate()`, mirroring the existing seed-handover pattern (`TerrainGrid` deliberately doesn't generate in `_ready()` so its owner can hand over the run seed first - same reasoning applies here). This issue can leave `generate()` as an empty placeholder; #31 and #32 are what actually populate it. ## References #26 (deposit data model decision). Depended on by #31 (clay deposit generation) and #32 (iron deposit generation).

liamjd added the

enhancement

label

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

liamjd referenced this issue

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

Generate clay deposits by water-proximity rule #31

liamjd referenced this issue

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

Generate iron deposits by seeded scatter #32

liamjd added this to the Untitled Colony Builder project

2026-08-21 06:40:28 +01:00