Create stub pawn model and place on game map. Determine game map scaliing

liamjd commented

2026-08-18 06:54:49 +01:00

Owner

Create a simple Pawn scene with just a capsule shape. Determine the scaling of the game map - how big is a tile? Assume 1m² and see how that fits. A pawn will be approximately 1.6m tall if we're to assume realistic proportions, but is this a falacy?

liamjd added the

ui

label

2026-08-18 06:54:49 +01:00

liamjd added this to the Untitled Colony Builder project

2026-08-18 06:54:49 +01:00

liamjd commented

2026-08-18 18:25:44 +01:00

Author

Owner

Map scaling decision

Recorded here so it doesn't only live in a chat log.

Is "1 m² per tile, 1.6 m pawn" a fallacy?

Partly — and the code already contains the proof. Two arithmetic checks against the current TerrainGrid defaults:

1. The step rule contradicts the height quantum. level_height = 0.25 with max_step_levels = 1 says a pawn cannot step up more than 25 cm. A person manages 40–50 cm without thinking. On a metrically honest map the pathfinder therefore treats a kerb as a cliff, and a lot of the terraces visible on a plains map are already impassable for no readable reason.

2. The map is a house plot. 64 tiles × 1 m = a 64 m square. A football pitch is 105×68 m. The design docs want extraction → processing chains linked by manual haulage, with carry capacity and walking distance as real pressure (the Settlers 2 comparison in CLAUDE.md). A pawn crosses 64 m in roughly twenty seconds; there is no room for haulage to be a decision.

Growing grid_size would fix (2), but it is the expensive knob: _paint_cells() sets one GridMap cell per tile and _build_navigation() adds one A* node per walkable tile, both rebuilt on every reroll, under GL Compatibility. At 256×256 that is ~65k of each. tile_size is free; grid_size is not.

The general principle

Metric truth is not what matters — the ratio of pawn to tile to building at the default zoom is, plus whether the silhouette survives being zoomed out. Settlers, Anno and Two Point all make pawns oversized relative to buildings, because the pawn is the object the player's eye tracks.

The only quantities that genuinely need to be metric are ones the fiction prices: solar output per m², habitat area per colonist, storage volume. Those can be denominated in tiles rather than metres, which decouples them from this decision entirely.

Decision

Tile = 2 m, height step = 0.5 m, grid_size stays at 64.

	before	after
`tile_size`	1.0 m	2.0 m
`level_height`	0.25 m	0.5 m
map extent	64 m	128 m
1.6 m pawn vs tile	1.6× tall, 1.0× wide	0.8× tall, 0.25× wide
`max_step_levels = 1` means	a 25 cm kerb	a 50 cm stride ✓
`height_scale = 5.0` gives	20 terraces	10 terraces

Consequences:

The pawn stands inside a square with room for another to pass — the conventional builder read — instead of filling it edge to edge.
The step rule finally matches human ability, so cliffs are cliffs and slopes are walkable.
Coarser terracing suits the low-poly look.
Buildings get plausible footprints without a nine-tile minimum: 1×1 = a 2 m shed, 2×2 = a 4 m hab, 4×4 = an 8 m smelter.

The pawn itself stays at 1.6 m tall × 0.5 m diameter (capsule radius 0.25). Realistic proportions are kept — it is the tile that stops being human-scale, not the pawn.

Caveat to watch when changing `tile_size`

In _build_mesh_library() the picking collider is shape.size = Vector3(tile_size, tile_size, tile_size) — a cube as tall as the tile is wide. At a 2 m tile with 0.5 m terraces that collider hangs 1.5 m down into the tile below. Probably still fine for raycast picking (it is deliberately shallow rather than full-depth, per the comment there), but it is a coupling to be conscious of rather than surprised by.

Remaining work on this issue

Apply the new tile_size / level_height defaults and re-check the presets headed.
Spawn the pawn from game.gd after map.generate() using cell_to_world() / random_walkable_position(), plus half its height — the current game.tscn transform hard-codes y = 1.5406733, which is correct for exactly one seed at exactly one tile.

## Map scaling decision Recorded here so it doesn't only live in a chat log. ### Is "1 m² per tile, 1.6 m pawn" a fallacy? Partly — and the code already contains the proof. Two arithmetic checks against the current `TerrainGrid` defaults: **1. The step rule contradicts the height quantum.** `level_height = 0.25` with `max_step_levels = 1` says a pawn cannot step up more than 25 cm. A person manages 40–50 cm without thinking. On a metrically honest map the pathfinder therefore treats a kerb as a cliff, and a lot of the terraces visible on a plains map are already impassable for no readable reason. **2. The map is a house plot.** 64 tiles × 1 m = a 64 m square. A football pitch is 105×68 m. The design docs want extraction → processing chains linked by *manual haulage*, with carry capacity and walking distance as real pressure (the Settlers 2 comparison in CLAUDE.md). A pawn crosses 64 m in roughly twenty seconds; there is no room for haulage to be a decision. Growing `grid_size` would fix (2), but it is the expensive knob: `_paint_cells()` sets one GridMap cell per tile and `_build_navigation()` adds one A* node per walkable tile, both rebuilt on every reroll, under GL Compatibility. At 256×256 that is ~65k of each. **`tile_size` is free; `grid_size` is not.** ### The general principle Metric truth is not what matters — the *ratio* of pawn to tile to building at the default zoom is, plus whether the silhouette survives being zoomed out. Settlers, Anno and Two Point all make pawns oversized relative to buildings, because the pawn is the object the player's eye tracks. The only quantities that genuinely need to be metric are ones the fiction prices: solar output per m², habitat area per colonist, storage volume. Those can be denominated **in tiles rather than metres**, which decouples them from this decision entirely. ### Decision **Tile = 2 m, height step = 0.5 m, `grid_size` stays at 64.** | | before | after | |---|---|---| | `tile_size` | 1.0 m | 2.0 m | | `level_height` | 0.25 m | 0.5 m | | map extent | 64 m | 128 m | | 1.6 m pawn vs tile | 1.6× tall, 1.0× wide | 0.8× tall, 0.25× wide | | `max_step_levels = 1` means | a 25 cm kerb | a 50 cm stride ✓ | | `height_scale = 5.0` gives | 20 terraces | 10 terraces | Consequences: - The pawn stands *inside* a square with room for another to pass — the conventional builder read — instead of filling it edge to edge. - The step rule finally matches human ability, so cliffs are cliffs and slopes are walkable. - Coarser terracing suits the low-poly look. - Buildings get plausible footprints without a nine-tile minimum: 1×1 = a 2 m shed, 2×2 = a 4 m hab, 4×4 = an 8 m smelter. The pawn itself stays at **1.6 m tall × 0.5 m diameter** (capsule radius 0.25). Realistic proportions are kept — it is the *tile* that stops being human-scale, not the pawn. ### Caveat to watch when changing `tile_size` In `_build_mesh_library()` the picking collider is `shape.size = Vector3(tile_size, tile_size, tile_size)` — a cube as tall as the tile is wide. At a 2 m tile with 0.5 m terraces that collider hangs 1.5 m down into the tile below. Probably still fine for raycast picking (it is deliberately shallow rather than full-depth, per the comment there), but it is a coupling to be conscious of rather than surprised by. ### Remaining work on this issue - [ ] Apply the new `tile_size` / `level_height` defaults and re-check the presets headed. - [ ] Spawn the pawn from `game.gd` after `map.generate()` using `cell_to_world()` / `random_walkable_position()`, plus half its height — the current `game.tscn` transform hard-codes `y = 1.5406733`, which is correct for exactly one seed at exactly one tile.

liamjd referenced this issue from a commit

2026-08-18 19:46:41 +01:00

Rescale map to 2m tiles with 0.5m height steps

liamjd commented

2026-08-18 20:23:43 +01:00

Author

Owner

Status update

Both remaining checklist items are done on 22-add-pawn-scene:

Applied tile_size = 2.0 / level_height = 0.5 (873ad65). Also fixed a walkability bug found along the way — is_walkable() was comparing against the datum directly instead of asking _kind_for(), which left 61–85% of a plains map undrawn-but-unreachable — and restored plains.tres as the Map node's preset (it had been silently replaced by a blank embedded resource). Verified headed against all four presets.
Widened camera zoom range for the 128m map, verified headed at min/default/max (3ec2e35).
Pawn now spawns via map.random_walkable_position() + half its height in game.gd (a87c1ad), replacing the old hardcoded y = 1.5406733 transform in game.tscn.

Not yet done: opening the PR. Branch is pushed to origin/22-add-pawn-scene but no PR exists yet.

## Status update Both remaining checklist items are done on `22-add-pawn-scene`: - [x] Applied `tile_size = 2.0` / `level_height = 0.5` (873ad65). Also fixed a walkability bug found along the way — `is_walkable()` was comparing against the datum directly instead of asking `_kind_for()`, which left 61–85% of a plains map undrawn-but-unreachable — and restored `plains.tres` as the Map node's preset (it had been silently replaced by a blank embedded resource). Verified headed against all four presets. - [x] Widened camera zoom range for the 128m map, verified headed at min/default/max (3ec2e35). - [x] Pawn now spawns via `map.random_walkable_position()` + half its height in `game.gd` (a87c1ad), replacing the old hardcoded `y = 1.5406733` transform in `game.tscn`. Not yet done: opening the PR. Branch is pushed to `origin/22-add-pawn-scene` but no PR exists yet.

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

2026-08-18 20:24:48 +01:00

Add pawn scene and rescale map to 2m tiles, 0.5m steps #24

liamjd closed this issue

2026-08-18 20:25:33 +01:00