All four road tiers now carve into the 3D world. Rugged and Trail were generated, exported and parsed all along, but nothing ever consumed them — which is why county roads visible on the 2D map did not exist in 3D. Tier identity is now carried into the carve via a RoadSegment struct, so each tier gets its own width, shoulder and grade-smoothing from one tunable block in Constants: highways widest and holding a grade, trails narrow and hugging the land. Rugged and Trail surface as dirt rather than asphalt. Because tiers now have different reach, nearest-by-distance was no longer a sound way to pick the governing road — a nearby footpath could shadow a highway whose shoulder still covered the column. The carve now considers only roads whose shoulder actually reaches, and takes the closest of those. The per-chunk cull pad is derived from the widest shoulder plus a margin, so widening a road cannot silently truncate it at chunk edges. Untouched: density field, Marching Cubes interpolation/welding, chunk dims, the .dat contract, the 2D A* generation, and mesher normals. 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 | ||
| 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 Directory - Isla Apocalypse
Overview
The /Core/Scripts directory is the dedicated code repository for all pure C# data structures, universal enumerations, and static mathematical utilities. Everything in this folder is compiled into the shared assembly used by both the authoritative /Server and the rendering /Client.
Core Philosophy: "Pure Data, Zero State." Scripts in this folder define what things are and how to calculate them, but they never remember current game events. They do not track who is online, what chunks are loaded, or what time of day it is. They are stateless, universal blueprints.
🧩 Current Systems (Phase 2)
1. The Voxel Palette System
BlockData.cs: The fundamentalstructdefining the properties of a single voxel (ID, Name, IsSolid, BaseColor).BlockRegistry.cs: The static master dictionary. Contains the hardcoded IDs for every block in the game (Air, Bedrock, Dirt, Asphalt) and provides a safe lookup method (GetBlock) for both the mesher and the physics engine.BiomePalette.cs: The translation layer between 2D and 3D. Contains the logic that dictates the vertical stacking of blocks based on biome and depth (e.g., ensuring mountains have stone beneath snow, and roads are topped with asphalt).
2. Universal Identifiers
Enums.cs: The master repository for global enums (Biome,TownTier,MapHalf). By keeping these here, the offline Map Generator, the Server, and the Client are guaranteed to use the exact same integer values for biomes and POIs.
🚀 Future Roadmap & Planned Additions (Phase 2 & 3)
As we build the 3D Chunk Manager and multiplayer networking, this folder will expand to include:
3. The Blueprint Parser
MapDataParser.cs(Next Step): A static utility to open and decode theMapData_Seed_[X].datbinary file into usable C# arrays for the Server to ingest.
4. Chunk Data Structures
ChunkData.cs: The raw 3D array (byte[,,]) that holds the voxel IDs for a specific 16x16x64 area.- Note: This structure will include the
IsPlayerProtectedboolean flag to support the "Land Claim" delta-backup system, preventing player bases from being wiped out by chunk corruption.
5. Math & Coordinate Utilities
VoxelMath.cs: Static helper functions for translating massive 3D World Coordinates into local Chunk Coordinates (e.g., finding out which specific chunk file to load when a player walks to X: 5000, Z: -200).
6. Network Packet Definitions
- Structs that define the exact byte layout of multiplayer messages (e.g.,
PlayerDigPacket,ChatPacket) to ensure precise Server/Client synchronization.
⚠️ Directory Rules & Best Practices
- No Godot Node Inheritance: Scripts here should rarely, if ever, inherit from
NodeorNode3D. They are pure C# classes, structs, or static utilities. - No
_Processor_Ready: Because these are not attached to active objects in the game world, they do not use Godot's frame-by-frame loop functions. - Strictly Independent: A script in
/Core/Scriptscannot reference anything in/Clientor/Server. The dependency flows one way: the Client and Server look in to the Core; the Core never looks out.