Every README was read first, checked against the code in its directory, then rewritten to describe what the code actually does now. Corrected throughout: map size is config-driven (8192 default) not a fixed 4096; chunks are 24x24x256 not 32x32; road carving is implemented for all four tiers, not a 'next step'; Data/ and Resources/ are empty, not populated. Also fixed MATH_MARCHING_CUBES.md, which documented the density sign convention exactly backwards — it claimed positive was underground, where the code treats positive as above the surface and counts a corner inside when density < iso. Getting that backwards inverts every normal, a bug this project has hit before. The root README now carries accurate run steps: F5 runs the map generator (not the game), F6 on Scenes/Main.tscn runs the 3D world, and ChunkRadius is a load radius that should be dropped to 4-8 while iterating. Docs only. No code changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
50 lines
2.7 KiB
Markdown
50 lines
2.7 KiB
Markdown
# /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 (`AIR` 0, `BEDROCK`, `STONE`, `DIRT`, `SAND`, the
|
|
three grasses, `SNOW`, `WASTELAND_DIRT`, `ASPHALT`) with a safe `GetBlock` lookup.
|
|
- **`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`.
|
|
|
|
⚠ **`Biome` and `TownTier` are the `.dat` wire format.** They are declared without explicit values,
|
|
so each member's ordinal *is* the number written to disk, with no version gate and no validation on
|
|
read. **Append only, at the end — never reorder or insert.** Doing so silently reinterprets every
|
|
pixel and every settlement in every existing blueprint.
|
|
`RoadTier` is exempt: road tiers live in separate sections of the file, so it is never serialized.
|
|
|
|
### World data
|
|
- **`MapDataParser.cs`** — decodes the `.dat` blueprint into a `WorldBlueprint` (heightmap, biome map,
|
|
towns, four road tiers).
|
|
- **`ChunkData.cs`** — one chunk's density and block-ID fields, `+1` padded 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
|
|
1. **No Godot node inheritance.** Pure classes, structs and statics.
|
|
2. **No `_Process` / `_Ready`.** Nothing here is attached to a live scene object.
|
|
3. **Dependencies flow inward only.** `/Server` and `/Client` reference `/Core`; `/Core` never
|
|
references them.
|