World generation

Stage orchestration

ChunkGenerator coordinates generation stages; it should not absorb every biome’s rules. A Biome composes a surface builder, carvers, and placed features. This mirrors the useful Minecraft boundary: the generator schedules work while biome components describe terrain decoration and carving behavior.

WorldManager requests a column
  → ChunkGenerator builds base terrain and samples biome data
  → biome rules carve, surface, and place features into the column
  → lighting and section meshes derive runtime presentation

This shows responsibility boundaries, not a claim that every Minecraft stage is present. Read ChunkGenerator for the actual order and active stages.

Terrain to surface

The generation code under src/World/Gen/ includes noise, density, aquifer, carver, ore-vein, and surface-building responsibilities. Terrain density establishes the broad shape; carvers remove volume; surface builders replace exposed materials; configured features add ores, vegetation, and structures. Preserve stage order and deterministic random sources when porting behavior.

Biome composition

Use Biome, ISurfaceBuilder, IWorldCarver, and IWorldFeature to keep biome-specific behavior replaceable. Reuse feature implementations and configuration where possible instead of creating one-off logic in the central generator.

Biome selection and biome behavior are separate. MultiNoiseBiomeSource samples climate inputs and resolves a biome through the registry; the selected Biome provides configured generation pieces. When terrain appears in the wrong biome, inspect both lookup inputs and the selected biome’s composition.

Generation boundaries and known gaps

Generation currently operates within the project’s current world-height and chunk model. The porting plan identifies broader gaps such as dimension height and a chunk-status/world-generation region pipeline. Features that write across chunk boundaries need special attention until that pipeline exists.

Generation depends on random-source ownership and call order. Moving a stage or consuming extra random values can change later placements even when each feature’s local algorithm is unchanged. Keep random inputs explicit and scoped to the generation operation being ported.

How to port a generation feature

Locate the reference class and its registration/configuration data; identify its stage and random source; locate the GDCraft interface and neighboring implementations; translate the algorithm while preserving deterministic inputs; then update the roadmap/ledger if the resulting subsystem meaningfully changes its documented status.

Related: voxel storage, world lifecycle, and the terrain generation map.