beezm
566abe9784
COAST. The task's premise -- "the island edge is the steepest part" -- is
right, and the diagnostic locates it precisely: it is the SEABED, not the
land. HeightCurve.Apply returns early at and below sea level, so tasks
05-09 reshaped the land and never touched the water. Measured on the same
seed, distance-from-shore vs height:
land reaches 10 m seabed reaches 10 m gradient
curve OFF 31 px 31 px 0.254/0.258
curve ON (ships) 186 px 31 px 0.038/0.258
So the landward side is ALREADY the broad shallow shelf terrain_design.md
asks for -- 54% of the island sits under 14 m -- and flattening it further
would only make it mushy. What is left is a shoreline that shelves gently
on land and then drops 6.7x steeper the moment it goes under.
CoastShelf fixes that side: depth' = depth * (1 - 0.775*exp(-depth/100 m)).
The seabed leaves the waterline at 22.5% of its former gradient and
recovers smoothly, so deep water and the Trench keep their shape. Measured
after: 5 m depth at 43 px (was 15), 10 m at 75 (was 31), 30 m at 150 (was
94) -- a 2.4-2.9x wider shallows.
It is strictly positive for positive depth, so it CANNOT move the waterline
by one pixel. Biomes and water bodies come out bit-identical, which is why
the coast is separable from elongation in the batch rather than tangled
with it -- contrary to the task's expectation that all coast work moves
biomes.
ELONGATION. IslandAxisX/Y replace the 1.15/0.90 literals (the spine shares
AxisX, as it always shared the literal). Sized by replaying candidate
falloffs against real terrain rather than guessing -- the replay reproduces
the shipped extents exactly, bbox and land count.
That replay says the task's suggested 1.30/0.85 buys +2.0% aspect, because
THE ISLAND IS ALREADY TRENCH-CLAMPED IN X: it spans 90.5% of the map width,
and 1.15 -> 1.40 moves the west coast only 393 -> ~360 px. Aspect responds
almost entirely to AxisY, which costs land:
1.30/0.85 +2.0% aspect +2.9% land 1.30/0.80 +4.9% -2.2%
1.30/0.82 +3.7% aspect -0.1% land 1.30/0.75 +11.5% -7.3%
Default 1.30/0.78 -- a visible step (+~8% aspect, measured 1.137 -> 1.200)
at ~4% land. The developer's eye tunes it from the batch; the table above
is the price list.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| BiomePalette.cs | ||
| BiomePalette.cs.uid | ||
| BlockData.cs | ||
| BlockData.cs.uid | ||
| BlockRegistry.cs | ||
| BlockRegistry.cs.uid | ||
| BLUEPRINT_FORMAT.md | ||
| BlueprintFormat.cs | ||
| BlueprintFormat.cs.uid | ||
| BlueprintWriter.cs | ||
| BlueprintWriter.cs.uid | ||
| ChunkData.cs | ||
| ChunkData.cs.uid | ||
| ConfigManager.cs | ||
| ConfigManager.cs.uid | ||
| Constants.cs | ||
| Constants.cs.uid | ||
| Enums.cs | ||
| Enums.cs.uid | ||
| MapDataParser.cs | ||
| MapDataParser.cs.uid | ||
| MarchingCubes.cs | ||
| MarchingCubes.cs.uid | ||
| MATH_MARCHING_CUBES.md | ||
| README.md | ||
/Core/Scripts
Pure C# data structures, shared enums, and static maths. Compiled into the shared assembly used by
both /Server and /Client.
"Pure data, zero state." These scripts define what things are and how to calculate them. They never track live game events — who is online, which chunks are loaded, what time it is.
What's actually here
Voxel materials
BlockData.cs— struct describing one block type (ID, name, IsSolid, BaseColor).BlockRegistry.cs— the byte-ID master list (AIR0,BEDROCK,STONE,DIRT,SAND, the three grasses,SNOW,WASTELAND_DIRT,ASPHALT) with a safeGetBlocklookup.BiomePalette.cs— decides which material sits where, given biome, depth, and whether the column is roadbed. Two paths on purpose: an integer classification that decides what is stored in each voxel, and a float-depth version used for rendering that returns the two materials either side of a boundary so colours fade rather than snap.
⚠ Note that BlockRegistry and the mesher's colour table hold different RGB values for some
blocks. The mesher's table is what you actually see; BlockData.BaseColor is currently unused by
rendering.
Shared identifiers
-
Enums.cs—Biome,TownTier,MapHalf,RoadTier.⚠
BiomeandTownTierare the.datwire format (u8 in the v2 container, i32 in legacy v1). They are declared without explicit values, so each member's ordinal is the number written to disk. Append only, at the end — never reorder or insert. The v2 reader range-checks ordinals so drift fails loudly at parse time, but only the append-only rule keeps old files meaning the same thing. Legacy v1 has no gate and no validation at all.RoadTieris exempt: road tiers live in separate sections of the file, so it is never serialized.
World data
BLUEPRINT_FORMAT.md— the byte-accurate.datcontainer contract (v2 tagged sections + the v1 legacy summary). Read this before touching the writer or parser.BlueprintFormat.cs— the single registry of v2 constants: magic, version gate, section tags (FourCC), validation bounds, re-encode sentinels.BlueprintWriter.cs— writes aWorldBlueprintas a v2 file. Blueprint-typed on purpose: the map generator and the round-trip harness are both just callers.MapDataParser.cs— decodes a.datblueprint into aWorldBlueprint(heightmap, biome map, towns, four road tiers, and — v2 only — the embedded generation params, per-town highway-node flag, and the optional water-bodies data:WaterBodyIds,WaterBodiestable,WaterSurfaceQ). Dispatches on the first byte: v2 tagged-section files get validation (version gate, size bounds, section-length and ordinal range checks); legacy v1 files still load, intact, with a deprecation warning. Nothing at runtime consumes the water data yet.ChunkData.cs— one chunk's density and block-ID fields,+1padded on every axis so the mesher can reach into the neighbouring chunk, plus the per-column data the renderer needs.Constants.cs— chunk dimensions,ISO_LEVEL,VOXEL_SCALE, and the visual/road tunables (material blend band; per-tier road width, shoulder, grade smoothing and surface).
Maths
MarchingCubes.cs— density field →ArrayMesh, with analytical normals and deterministic integer-keyed vertex welding.MATH_MARCHING_CUBES.md— an explainer of the algorithm.
Rules
- No Godot node inheritance. Pure classes, structs and statics.
- No
_Process/_Ready. Nothing here is attached to a live scene object. - Dependencies flow inward only.
/Serverand/Clientreference/Core;/Corenever references them.