Crafting a Spherical Minecraft World: A How-To Guide

▼ Summary
– Blocky Planet is a tech demo that maps Minecraft-style cubic voxels onto a procedurally generated, fully destructible spherical planet using the Unity engine.
– The spherical structure introduces unique challenges, such as aligning block faces with gravity and minimizing mapping distortion using a quad sphere approach.
– The project uses a multi-shell system to handle depth distortion, grouping blocks into shells that quadruple in size to maintain edge alignment and efficient processing.
– Key mechanics include custom gravity pulling players toward the planet center, terrain generation using 3D noise for seamless spherical mapping, and structured block addressing for placement and neighbors.
– Future potential features include multiple planets, chunk-based gravity, cave generation, and improved biomes, though development is limited by the creator’s full-time work schedule.
Creating a spherical Minecraft-like world presents unique challenges that transform traditional voxel mechanics into a planetary adventure. Blocky Planet, a tech demo built in Unity, explores this concept by mapping cubic blocks onto a spherical surface. The planet is fully destructible and supports over twenty different block types, offering a fresh take on familiar sandbox gameplay.
While many elements resemble standard Minecraft clones, the spherical structure introduces distinct design hurdles. This guide focuses on those specific challenges rather than rehashing common voxel techniques.
How can I play it?
The latest version is freely available on Itch.io. A native Windows build offers optimal performance, while a browser-based version provides accessibility with some expected quirks.
Why create a spherical voxel world?
Inspiration struck after encountering an earlier tech demo by Jordan Peck. As someone fascinated by procedural geometry and voxel games, recreating the concept with added features—like textured blocks and large-scale destruction—seemed like a rewarding challenge.
Will this become a full game?
Likely not, at least not to a commercial standard. Full-time work limits development time, and transitioning from prototype to polished product demands substantial effort. Occasional updates may still arrive.
How long did development take?
Coding required just over a month at roughly fifteen hours per week. Prior voxel experience helped, though adapting everything to a spherical format proved demanding. Ironically, writing this article took twice as long.
What tools were used?
Unity 6 and C# formed the foundation. The project leveraged Unity’s Job system and Burst compiler but avoided a full DOTS implementation due to its steep learning curve and modest performance returns for this scope.
Is the source code available?
Not currently. The codebase isn’t yet clean enough to share publicly, though that may change later.
Where do the block textures come from?
All textures were custom-made using pixel art tools or generative scripts. Interestingly, many Minecraft-style textures can be approximated by applying color tints to noise patterns.
How can I share ideas or ask questions?
Feedback and suggestions are welcome on the dedicated Reddit post. Reasonable ideas might even make it into future updates.
Constructing a Spherical Framework
Building a sphere from blocks is simple in code: select cubes whose centers fall within a set distance from a central point. While effective for creating hollow structures, this method fails for functional planets because surface blocks don’t align with gravity. Walking or building upward becomes problematic without gravity-oriented faces.
The solution involves two key adjustments: mapping a 2D grid onto a 3D sphere and maintaining consistent block dimensions across curved space. Multiple approaches exist, each with tradeoffs.
Mapping the Unmappable
Cartographers have long struggled to project spherical surfaces onto flat maps without distortion. Gauss’s work confirms that perfect mapping is impossible. Many games use a quad sphere—dividing the globe into six cube-like sectors—to minimize distortion. Each sector uses a separate grid, significantly reducing visual warping compared to single-rectangle projections.
Constructing a quad sphere involves subdividing a cube’s faces and projecting each vertex onto a unit sphere. This process inevitably distorts the original squares into irregular quads. Pre-distorting the grid before projection helps counteract this, yielding more uniform blocks across the surface.
Managing Depth Distortion
In flat worlds, stacking identical block layers is straightforward. On a sphere, constant block height would create undersized blocks near the core and oversized ones near the surface. Adding more blocks per layer outward helps, but aligning edges requires increasing block counts by integer multiples—often doubling per shell. This organizes blocks into clean grids but means blocks at a shell’s bottom are quarter-sized compared to those at the top.
An alternative restricts players to a single shell, avoiding depth issues entirely. This works well for large planets where shell size increases exponentially. For Blocky Planet, supporting tiny worlds and deep digging made multi-shell design preferable.
Planetary Architecture
Flat voxel worlds use column chunks subdivided into render chunks. Spherical worlds use six sectors, each subdivided into shells of increasing size. These shells are further split into standardized 16x16x16 chunks for efficient processing. This structure allows uniform chunk handling regardless of location, though very small shells near the core remain unplayable for now.
Locating Blocks
Every block has a hierarchical address: Sector → Shell → Chunk → Block. Converting a world position into this address involves determining the sector based on the dominant axis, identifying the shell by distance from the center, and mapping to chunk and block indices within that shell.
Finding Neighbors
Identifying adjacent blocks is crucial for gameplay mechanics and rendering efficiency. While simple in flat worlds, spherical layouts complicate neighbor detection—especially across shell or sector boundaries.
Vertical shell transitions mean one block below can connect to four above, and vice versa. Sector edges require careful handling due to differing local coordinate orientations. Consistent rules for edge alignment ensure correct connections despite these mismatches.
Gravity and Movement
A custom gravity system pulls players toward the planetary center, with strength decreasing near the core to simulate balanced forces. A thruster ability lets players counteract gravity or achieve orbit. Smooth rotation adjustments keep the player’s “down” aligned with the gravity direction, avoiding disorienting snaps.
World Generation
Terrain height derives from 3D noise sampled across the sphere, avoiding seam and distortion issues inherent in 2D-to-3D mapping. Biomes are simple: arctic regions near the poles transition to forest areas elsewhere, with noise-blended borders. Block types assign based on height, proximity to surface, and water level.
Structures and Building
Saved block structures—like trees or player-built designs—can be placed using relative directions from an origin block. This method handles problematic zones where sector corners or shell boundaries disrupt simple grid copying, though some visual oddities may occur.
Future Possibilities
Potential expansions include multi-planet systems, chunk-based gravity calculations, cave generation, and advanced biome modeling. Voxel-based lighting could enhance immersion, though current implementations rely on Unity’s built-in systems.
Community input can shape these developments. Share thoughts on the project’s Reddit thread to contribute ideas or feedback.
(Source: Bower Byte)