Move terrain palette into TerrainPreset and pick kind by shape context #7

Open
opened 2026-08-15 15:55:53 +01:00 by liamjd · 0 comments
Owner

KIND_COLORS, KIND_BANDS and the Kind enum are hardcoded constants in terrain_grid.gd, shared by every preset. Two problems follow.

The palette is Earth, and the game is not

Grass, forest, snow and blue sea read as a temperate island. The design docs are about mining outposts and colonies on moons around a gas giant. Colours belong on TerrainPreset so a crater on an airless moon and an M-class habitable world can look like different places.

Water stays a valid option — some moons are meant to be habitable — but it becomes a per-preset choice rather than a fixed member of the palette.

Colouring by elevation alone fights the shapes

_kind_for(level) picks terrain from absolute height only. On the crater preset that means the interior floor and the exterior apron get the same colour, because they sit at similar absolute heights — so the one thing a crater image must communicate, inside versus outside, is exactly what the palette erases. The rim reads as a ring on a plain rather than the lip of a basin.

Kind selection needs shape context as well as height: something like _kind_for(level, x, z) so a crater can say "inside the rim is basin regolith, the rim is exposed rock, outside is dust plain" regardless of absolute elevation.

Scope

  • Kind stops being a fixed enum and becomes an index into per-preset data.
  • _build_mesh_library() currently loops Kind.size() and bakes colour onto each mesh (MeshLibrary has no per-item material override in 4.7). It must rebuild when the preset changes — _configure_grid() already gets called on preset switch, so the hook exists.
  • Retire TerrainPreset.get_preset_res() while here: it hardcodes paths to its own instances, so the resource class enumerates every preset file. That belongs on the node as an Array[TerrainPreset], or in the debug cycler.

Blocks any real art direction. Worth doing before more shape work, since shape and palette are judged together.

`KIND_COLORS`, `KIND_BANDS` and the `Kind` enum are hardcoded constants in `terrain_grid.gd`, shared by every preset. Two problems follow. ## The palette is Earth, and the game is not Grass, forest, snow and blue sea read as a temperate island. The design docs are about mining outposts and colonies on moons around a gas giant. Colours belong on `TerrainPreset` so a crater on an airless moon and an M-class habitable world can look like different places. Water stays a valid option — some moons are meant to be habitable — but it becomes a per-preset choice rather than a fixed member of the palette. ## Colouring by elevation alone fights the shapes `_kind_for(level)` picks terrain from absolute height only. On the crater preset that means the interior floor and the exterior apron get the same colour, because they sit at similar absolute heights — so the one thing a crater image must communicate, inside versus outside, is exactly what the palette erases. The rim reads as a ring on a plain rather than the lip of a basin. Kind selection needs shape context as well as height: something like `_kind_for(level, x, z)` so a crater can say "inside the rim is basin regolith, the rim is exposed rock, outside is dust plain" regardless of absolute elevation. ## Scope - `Kind` stops being a fixed enum and becomes an index into per-preset data. - `_build_mesh_library()` currently loops `Kind.size()` and bakes colour onto each mesh (`MeshLibrary` has no per-item material override in 4.7). It must rebuild when the preset changes — `_configure_grid()` already gets called on preset switch, so the hook exists. - Retire `TerrainPreset.get_preset_res()` while here: it hardcodes paths to its own instances, so the resource class enumerates every preset file. That belongs on the node as an `Array[TerrainPreset]`, or in the debug cycler. Blocks any real art direction. Worth doing before more shape work, since shape and palette are judged together.
Sign in to join this conversation.
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
liamjd/UntitledColonyBuilder#7
No description provided.