Worldgen Phase 0: add biome and height distribution baselines

[MichaelFisher1997]

Parent: #646

Phase

Phase 0: Baseline and safety

Goal

Add deterministic baseline reporting for biome coverage, height ranges, ocean/land ratio, and mountain coverage across representative seeds.

Why

Terrain modifier and selector work will change distribution. We need a cheap way to compare before/after behavior without relying only on visual inspection.

Tasks

• Add a deterministic report helper or test utility that samples a fixed region for known seeds.
• Report biome counts/percentages.
• Report min/max/average terrain height and sea-level coverage.
• Report ocean/land ratio and high-elevation/mountain coverage.
• Keep output stable enough to use in reviews and tuning.

Acceptance Criteria

• Reports are deterministic for a fixed seed and sample area.
• The report can be run under nix develop --command.
• The implementation does not require launching the game window.

Parallelization

Can be done in parallel with the selector and terrain modifier test issues.

[github-actions]

This is a Feature Request for a deterministic world generation reporting utility.

Analysis:

The codebase already has infrastructure that can be leveraged:

• chunkFingerprint() in src/worldgen_tests.zig:22 - wyhash-based chunk fingerprinting
• OverworldGenerator in modules/world-worldgen/src/overworld_generator.zig - main generation entry point
• HeightSampler in modules/world-worldgen/src/height_sampler.zig:13 - height computation with computeHeight()
• BiomeSelector in modules/world-worldgen/src/biome_selector.zig - selectBiome(), computeClimateParams()
• BIOME_REGISTRY in modules/world-worldgen/src/biome_registry.zig:246 - 57 biome definitions with lookup table
• Existing determinism tests (e.g., test "WorldGen same seed produces identical blocks" at src/worldgen_tests.zig:30)

Proposed Implementation Approach:

A new test utility module (e.g., modules/world-worldgen/src/terrain_report.zig) could expose:

• sampleRegion(seed, origin_x, origin_z, width, depth) TerrainReport - samples a fixed region
• TerrainReport struct containing: biome counts, height min/max/avg, sea-level coverage, ocean/land ratio, mountain coverage

Implementation Notes:

• Leverage existing NoiseSampler.init(seed) for determinism
• Use HeightSampler.computeHeight() for terrain height
• Ocean detection via continentalness < 0.35 (from height_sampler.zig:39)
• Mountain coverage via getMountainMask() or peaks/valleys threshold

Clarifying Question:
Should the report output format be structured (return a struct for assertion in tests) or text-based (for human review)? And should specific "representative seeds" be defined, or passed as parameters?

opencode session  |  github run

[github-actions]

Analysis: Feature Request (Phase 1 - Terrain Modifier Integration)

Classification

This is a Feature Request with an implementation dependency. The issue acknowledges this via "Phase 1: Terrain modifier integration" and "Dependencies: Requires terrain modifier integration."

Current State

The struct exists in :

Wetland biomes already have terrain values set:

• Swamp (line 535):
• Mangrove Swamp (line 716):
• Marsh (line 936):

Root Cause: Terrain Modifiers Are Never Applied

The terrain modifier fields are defined but not wired into the height computation pipeline:

1. **** - only uses (from region controls). Biome-specific terrain modifiers are never passed in.

2. **** - Height is computed BEFORE biome selection (lines 248-270). Since biome selection happens after height, there's no opportunity to apply per-biome terrain modifiers.

3. **** - Biome definition (including terrain) is only used for surface properties after height is already computed.

Implementation Path

To enable this feature, the pipeline needs modification:

1. Option A: Move biome selection before height computation and pass to
2. Option B: Apply terrain modifiers as a post-processing step after initial height is computed (less elegant but lower risk)

Tasks Breakdown (per issue description)

1. Tune , , and for wetlands - blocked until integration
2. Verify no excessive inland sand beaches - requires rendering/testing after integration
3. Preserve ocean vs inland-water distinction - coastal generator logic unaffected
4. Add tests for wetland height behavior - needs new test infrastructure after integration

Recommendation

This issue should be split into two:

• Issue A (Integration): Wire into height computation pipeline - this is the hard part
• Issue B (Tuning): Tune wetland parameters once integration exists - straightforward parameter tweaking

The parent issue #646 likely covers the integration work.