Roblox Voxel World Creation Comparison

Prompt

Your task is to create a complete, production-quality infinite voxel world engine in Roblox Studio using only Luau code. ## CORE RULES 1. No Toolbox assets. 2. No imported models. 3. No prebuilt terrain. 4. No external packages or frameworks. 5. No plugins required. 6. All world geometry, terrain, trees, ores, and structures must be generated by code. 7. Use Roblox APIs only where appropriate. 8. All scripts must be complete and runnable. 9. Do not provide pseudocode for core functionality. 10. Do not skip important systems with comments such as "implement this later." 11. Do not generate one enormous Script. Use clean ModuleScripts and separate responsibilities. 12. The system must support an effectively infinite world through chunk streaming rather than generating the entire world at once. ## PROJECT GOAL Create a voxel sandbox engine similar in concept to Minecraft's terrain system, but implemented from scratch in Roblox Luau. The player should be able to: * Spawn in a procedurally generated world. * Walk in every direction indefinitely. * See terrain generated around them. * See distant chunks load as they approach. * See old chunks unload to save memory. * Mine and place blocks. * Explore caves and mountains. * Encounter multiple biomes. * See code-generated trees and vegetation. * Have world changes replicated correctly in multiplayer. * Save and reload modified chunks. The terrain must be deterministic: the same world seed and chunk coordinates must always produce the same original terrain. # PHASE 1 — ENGINE ARCHITECTURE Create the following modules: ReplicatedStorage └── VoxelShared ├── BlockRegistry ├── VoxelConfig ├── VoxelTypes ├── NoiseGenerator ├── ChunkCoordinates └── Serialization ServerScriptService └── VoxelServer ├── WorldServer ├── ChunkManager ├── ChunkGenerator ├── ChunkStorage ├── BlockService ├── VoxelMesher ├── NetworkService └── Main.server.lua StarterPlayer └── StarterPlayerScripts └── VoxelClient ├── ChunkRenderer ├── ClientChunkManager ├── InteractionController ├── SelectionController └── Main.client.lua You may adjust the architecture if you can explain why the change is better. All modules must have clear APIs, type annotations where useful, and no circular dependencies. # PHASE 2 — VOXEL DATA STRUCTURE Implement a chunk-based voxel data structure. Initial configuration: * Block size: 4 studs. * Chunk width: 16 blocks. * Chunk depth: 16 blocks. * Chunk height: 128 blocks. * World coordinates: integer chunk coordinates. * World height range: 0 to 127. * World seed: configurable integer. * Each block must have a compact numeric block ID. Store chunk data efficiently. Do not create a Roblox Instance for every invisible or empty block. Each chunk must support: * GetBlock(localX, y, localZ) * SetBlock(localX, y, localZ, blockId) * WorldToLocal(worldPosition) * LocalToWorld(localCoordinates) * Chunk coordinate conversion. * Bounds validation. * Dirty state tracking. * Serialization and deserialization. Use a flat array or another efficient representation rather than deeply nested tables for every block. Handle negative world coordinates correctly. # PHASE 3 — BLOCK REGISTRY Create a BlockRegistry that supports registering blocks using numeric IDs. Include at least: * Air * Grass * Dirt * Stone * Sand * Snow * Water * Bedrock * Coal Ore * Iron Ore * Gold Ore * Wood * Leaves * Glass Each block should have properties: * Numeric ID. * Name. * Solid or non-solid. * Transparent or opaque. * Breakable. * Hardness. * Material. * Color. * Render priority. * Optional tool requirements. The system must not depend on physical Parts to know what a block is. # PHASE 4 — DETERMINISTIC TERRAIN GENERATION Build a procedural terrain generator using Roblox's built-in math/noise functionality or a custom deterministic noise implementation. Use the seed and world coordinates as inputs. The same seed must produce the same terrain every time. Implement: ## Height generation Use layered noise for: * Continental terrain shape. * Hills. * Mountains. * Detail variation. * Valleys. Example conceptual formula: height = baseHeight + continentalNoise * 30 + mountainNoise * 45 + detailNoise * 5 Do not blindly copy this formula. Tune it for a playable world. ## Surface rules * Grass on the surface. * Dirt below grass. * Stone deeper underground. * Bedrock at the bottom. * Snow at high elevations. * Sand in suitable dry or beach regions. * Water filling low areas below sea level. ## Biomes Implement at least: * Plains. * Forest. * Desert. * Mountains. * Snowy Mountains. * Beach. * Ocean. Biome selection must be deterministic and based on world coordinates. ## 3D caves Use 3D noise or another deterministic volumetric algorithm to carve caves. Requirements: * Caves must exist underground. * Caves should have natural variation. * Avoid excessive caves that destroy all terrain. * Caves must be deterministic. * Do not use thousands of random parts to represent caves. ## Ores Generate ores based on deterministic coordinate-based rules. Requirements: * Coal, iron, and gold. * Depth-dependent distribution. * Veins or clusters. * Same seed produces the same ore locations. # PHASE 5 — CHUNK MANAGER Create a server-side chunk manager. Responsibilities: * Load requested chunks. * Generate missing chunks. * Track loaded chunks. * Unload distant chunks. * Track chunk states. * Prioritize chunks near players. * Prevent duplicate generation. * Prevent race conditions. * Respect a per-frame generation budget. * Avoid generating the entire infinite world. Chunk states: UNLOADED QUEUED GENERATING GENERATED MESHING LOADED DIRTY UNLOADING FAILED Implement a priority queue or equivalent. Prioritize: 1. Chunks around the player. 2. Chunks in the direction the player is moving. 3. Chunks required for rendering. 4. Background chunks. Use configurable load and unload radii. The engine must not freeze the server when a player moves quickly. # PHASE 6 — VOXEL MESHING / RENDERING Create a rendering system that turns visible voxel faces into Roblox geometry. IMPORTANT: Do not create a Part for every block in the world. Start with a correct face-culling renderer: * Render only exposed block faces. * Do not render faces touching another opaque block. * Avoid rendering internal faces. * Support transparent blocks. * Support chunk borders. * Correctly handle neighboring chunks. Then implement greedy meshing as an advanced optimization. Greedy meshing should merge adjacent faces with compatible block properties. Requirements: * Reduce visible geometry. * Handle chunk boundaries. * Rebuild dirty chunks. * Avoid unnecessary rebuilds. * Avoid memory leaks. * Clean up unloaded geometry. Use a safe Roblox-compatible rendering strategy. If custom mesh generation is used, ensure it works within Roblox Studio and does not rely on unavailable APIs. # PHASE 7 — WORLD RENDERING Create a client-side renderer. The server owns the authoritative voxel data. The client renders chunks received from the server. Implement: * Chunk visual creation. * Chunk visual destruction. * Chunk updates. * Chunk rebuilds. * Client-side render distance. * Distance-based prioritization. * Render budget per frame. * Visual loading state. * Correct rendering of chunk borders. The client must not be able to permanently modify the world by sending arbitrary block data. # PHASE 8 — BLOCK INTERACTION Implement mining and placing. Requirements: * Raycast from the player's camera. * Highlight the targeted block. * Show a selection outline. * Left click or designated input breaks a block. * Right click or designated input places a block. * Server validates all requests. * Prevent placing inside the player's character. * Prevent modifying blocks beyond a configurable reach. * Prevent modifying protected blocks. * Prevent invalid block IDs. * Prevent client-side spoofing. * Support breaking delays based on hardness. * Support tool requirements if implemented. The server must verify: * Player is alive. * Player is close enough. * Target block exists. * Requested action is valid. * Rate limits are respected. # PHASE 9 — MULTIPLAYER NETWORKING Create a secure networking layer. Requirements: * RemoteEvents for client requests. * Server-authoritative block modifications. * Chunk data replication. * Delta updates for changed blocks. * Per-player chunk subscriptions. * Request validation. * Rate limiting. * Duplicate request handling. * Safe handling of disconnects. Do not send the entire world to every player. Only replicate relevant chunks. Do not trust client-generated chunk data. # PHASE 10 — SAVE SYSTEM Implement persistent world modifications. The original terrain is generated from the seed. Only modified blocks need to be saved. Requirements: * Save world seed and configuration. * Save changed blocks by chunk. * Save placed blocks. * Save broken blocks. * Save block metadata if needed. * Load changes when a chunk is loaded. * Autosave. * Save on player leaving. * Save on server shutdown where possible. * Retry failed DataStore requests. * Respect Roblox DataStore budgets. * Avoid excessive writes. * Use versioned serialized data. Do not attempt to save every generated block in the entire infinite world. # PHASE 11 — CODE-GENERATED CONTENT Generate everything through algorithms. Add: * Trees. * Grass. * Flowers. * Cacti. * Simple rocks. * Ore clusters. * Natural structures. Structures must be deterministic and generated from the world seed and coordinates. Ensure structures crossing chunk boundaries are handled correctly. Do not generate structures using imported models. # PHASE 12 — PERFORMANCE This is a major requirement. The system must include: * No per-block Instances for invisible blocks. * Chunk streaming. * Mesh merging. * Generation budgets. * Render budgets. * Object cleanup. * Memory-conscious data structures. * Efficient coordinate conversion. * Minimal RemoteEvent traffic. * No unbounded loops. * No unnecessary full-world scans. * No repeated regeneration of unchanged chunks. Add debug metrics: * Loaded chunk count. * Generated chunk count. * Queue size. * Generation time. * Meshing time. * Rendered geometry count. * Memory usage where available. * Block update rate. * Network update count. * Failed chunk count. Expose these through a debug module or an optional debug UI. # PHASE 13 — TESTING Create a test suite. Test: 1. Positive chunk coordinates. 2. Negative chunk coordinates. 3. Chunk border access. 4. World-to-chunk conversion. 5. Chunk-to-world conversion. 6. Deterministic generation. 7. Different seeds produce different worlds. 8. Chunk save/load. 9. Mining validation. 10. Placing validation. 11. Invalid block IDs. 12. Rate limiting. 13. Unloading and reloading chunks. 14. Multiple players near the same chunk. 15. Generation queue duplicates. 16. Neighbor chunk meshing. 17. Structures crossing chunk boundaries. 18. DataStore failures. 19. Player disconnects. 20. Rapid movement across the world. Each test should clearly report success or failure. # PHASE 14 — DELIVERABLES Provide: 1. Complete Roblox Studio folder structure. 2. Every Script and ModuleScript in full. 3. Exact location for every script. 4. Setup instructions. 5. Configuration instructions. 6. Explanation of chunk generation. 7. Explanation of rendering. 8. Explanation of networking. 9. Explanation of saving. 10. Test instructions. 11. Performance tuning guide. 12. Known limitations. Do not claim the system is complete unless the code for the core functionality has actually been provided. # DEVELOPMENT METHOD Build in phases. First implement a minimal working terrain engine. Then add: 1. Chunk data. 2. Deterministic terrain. 3. Chunk streaming. 4. Rendering. 5. Interaction. 6. Multiplayer. 7. Saving. 8. Caves. 9. Biomes. 10. Greedy meshing. 11. Optimization. 12. Testing. At the end of each phase, explain: * What was implemented. * Which scripts were added or changed. * How to install it. * How to test it. * Known bugs or limitations. Do not move to the next phase while the current phase has critical errors. ## FINAL QUALITY STANDARD The result must be a real code-based voxel engine, not a collection of fake demo parts. It must demonstrate: * Strong Luau architecture. * Procedural generation. * Algorithms and data structures. * Performance engineering. * Secure multiplayer design. * Persistent world modifications. * Correct handling of infinite coordinates. Start by designing the architecture and implementing Phase 1 and Phase 2 with complete, runnable code.