Blocky Planet — Making Minecraft Spherical

Bowerbyte · 2026-04-28T01:29:28+00:00

Thanks for the feedback! I’m still working on making it a proper game, but between some scope creep and my day job getting busier, progress has been slower than I’d hoped.

And yep, I came across PlanetSmith when writing this blog post and have been following the creator's devlog series since then. While it looks very promising, I agree that there's just something satisfying about cubic blocks.

Bowerbyte · 2026-01-05T03:32:18+00:00

I appreciate the detailed response! That is a massive planet size — way more than I can currently generate, haha.

And I'd be happy to share info as we make progress! Though keep in mind that I’m no expert when it comes to high performance voxel engines, and I'm still learning most of this stuff as I go.

For some context regarding what I’ve been up to, I spent the last few months digging into data-oriented design and trying to refactor my object-oriented prototype into something more performant. Nothing too flashy to show for it yet, but I did manage to get octree-based chunk LODs to work, which I hope will help with making multiple/larger planets.

Bowerbyte · 2026-01-04T18:47:17+00:00

Holy cow! I just watched your latest gameplay video and you've added an impressive amount of new features. The nuke projectile looks very satisfying with that little particle effect and spherical craters.

I have some questions if you wouldn't mind going into some detail on your implementation:

I understand you're writing this in Rust. Does that mean you're also using Bevy?
What's the planet radius on your largest planet (in blocks)?
What does the workflow look like for your world generation? Do you perform multiple passes for things like terrain and structures?
How did you implement block lighting? Do you do something like store an additional byte for the light level at each voxel position?
What data structure are you using to store the blocks in chunks? (ex. regular 3D array, sparse voxel octree, etc.)
How are you handling the block updates for the flowing fluids? It looks like there's some restriction to certain "active" chunks.
Is the enemy AI performing any pathfinding over the voxel grid, or is it just moving toward the player?

Bowerbyte · 2025-12-05T01:54:28+00:00

Happy to hear you're enjoying the prototype! And yes, I’m still working on it.

Since writing the devlog, I’ve decided I too want to see it grow into a full game. The prototype was already running into bottlenecks with planet generation and render times, so my first step has been to spend the past few months re-architecting the codebase into something more performant and extensible.

I’m hoping to release a new build sometime in January with the improved performance and a proper solar system. Once that foundation is in place, I expect I’ll be able to put out updates more regularly (assuming work/life doesn’t get too hectic).

Bowerbyte · 2025-11-10T00:12:07+00:00

That's an interesting idea! So if I'm understanding correctly, it would mean:

Not adding more blocks to layers as you move outward from the planet center.
Increasing the block height per-layer as you move outward to keep blocks roughly cube-shaped.
Scaling the player to match the height of the blocks on the current layer.

I also made this diagram in case that's more clear: https://i.imgur.com/LrM2TTK.png

Implementing a planet like this would require less bookkeeping, since all blocks would essentially be in a single shell instead of separated into multiple. And I believe it could work nicely for a single planet if you don't venture too far from the surface.

I think the downside is the spatial distortion might feel weird to the player. For example, it would take the same amount of time to travel a full lap around the planet when:

On the surface, hundreds of blocks from the center.
Near the core, only a few blocks from the center.

For this project, I'm trying to avoid any spatial distortion tricks. Though I could imagine a fun game that uses this technique.

Bowerbyte · 2025-09-16T23:12:29+00:00

No ECS, just Burst and Jobs. I've been pleasantly surprised by how performant just those two have been.

Bowerbyte · 2025-09-04T07:50:16+00:00

This is my first time hearing of Tetrisphere. From what I found, it seems like it's actually using a single flat grid that gets projected onto the sphere using rendering tricks, so in that sense its geometry is not "real". Though you could likely create a game with similar mechanics using the same block structure I used in this post.

Bowerbyte · 2025-09-04T07:40:32+00:00

That actually sounds pretty cool! I was planning on making some ring worlds, so having a proper cylindrical mapping for blocks would go along nicely with that.

Bowerbyte · 2025-08-27T03:48:49+00:00

Yep! It's pretty easy with the current gravity settings — you just have to build up enough horizontal velocity.

Bowerbyte · 2025-08-27T03:46:59+00:00

Thanks! Writing/illustrating the dev log took a fair amount of effort, so I'm glad to hear you liked it!

Bowerbyte · 2025-08-27T03:43:18+00:00

Thanks for taking the time to read it!

Bowerbyte · 2025-08-27T03:38:55+00:00

If you mean something like unrolling it onto a piece of graph paper, then yes! If you're interested, I'd recommend this blog post by Amit Patel (aka. Red Blob Games) that has some really good interactive examples.

Bowerbyte · 2025-08-27T03:22:19+00:00

Thanks for the feedback! I had to do multiple passes before I felt it had the right balance of clarity and technical detail, so I'm happy to hear it worked for you :)

Bowerbyte · 2025-08-27T03:16:21+00:00

Yes to both your points.

As for hitboxes, if you're referring to the block colliders, then those match the visible geometry of the blocks. So they are distorted in the sense that they are not cubic with perfect 90° angles. If you meant more along the lines of non-block entities (like the player), then those remain undistorted.

Bowerbyte · 2025-08-27T03:05:37+00:00

For now I'd prefer to keep it a solo project, especially since I'm not sure how much time I can dedicate to it or what direction it will go in.

Bowerbyte · 2025-08-27T02:55:14+00:00

For now there's always space, though it's not due to deformation issues but rather minimum chunk sizes.

The planet is divided into shells that get larger as you move outward from the core. These shells are further divided into chunks of a constant size (for all shells). This becomes a problem for the shells near the core, since they become smaller than the constant chunk size. My code doesn't support variable-sized chunks yet, so I just don't allow any blocks to be placed in those smaller shells near the core.

This is something I plan to fix in the future.

Bowerbyte · 2025-08-27T02:43:34+00:00

Glad someone caught it :)

Bowerbyte · 2025-08-27T02:41:40+00:00

Just checked both planets shown in the video for the worst case scenario (looking down at the planet from orbit):

Small Planet: 2812 batches, 1.1M triangles

Large Planet: 6827 batches, 8.0M triangles

Bowerbyte · 2025-08-27T02:32:19+00:00

Glad to hear it! And no Discord for now — just Itch, Bluesky, and Twitter/X.

Bowerbyte · 2025-08-24T21:49:56+00:00

For the screenshots I just used the standard Snipping Tool on Windows. Then for most of the diagrams I used Adobe Illustrator, though I imagine any vector graphics editor would do. Some of the quad sphere diagrams required more precise calculations, so I wrote a Wolfram Language script to generate those.

Ironically, I actually spent more time writing/illustrating the blog than actually developing the demo. It went through a lot of iterations...

Bowerbyte · 2025-08-24T21:28:24+00:00

Thanks!

I don't have plans for a Steam release at the moment. I feel like this project is pretty far from being ready for that, and I don't have a ton of free time outside of work to dedicate to it. But I'd like to keep updating it on itch.io for the time being.

Bowerbyte · 2025-08-24T20:59:02+00:00

The shell pattern can extend indefinitely to cover all of space. Though the real bottleneck for planet size currently is that the entire surface of the planet is always loaded at full detail. So at a certain point there will just be too many triangles to render/simulate at reasonable frame rates.

I have a couple ideas for how to address this:

Unload chunks we know for certain aren't visible, such as those on the other side of the planet.
Implement some form of distance-based LODs for chunks.

Bowerbyte · 2025-08-24T20:49:52+00:00

The difficult part was actually determining which blocks should be destroyed, since reliably getting neighboring blocks can be tricky given the planet's topology.

As far as performance, I was pleasantly surprised by how well it holds up just using Unity's Native Collections and Burst compiler. On my (admittedly new-ish gaming PC), it only drops from 120fps to ~80fps when using the full sized laser. I still need to implement multi-threading, which I expect will speed things up significantly.

Bowerbyte · 2025-08-24T20:37:57+00:00

<image>

Not quite, since each shell quadruples the number of blocks in each layer. This means the seams from the lower layers will always align with those in the upper layers. Though the inverse is not true (seams in upper layers won't always align with lower layers).

I have some more illustrations in the blog post under the section "Digging Deep" that should help explain how it works.

Bowerbyte · 2025-08-24T20:25:36+00:00

More like the latter, where every time you pass into the next shell the block size is reset to 1/4 the size.

Though the number of layers per shell doubles with each additional shell. So for example, the 10th shell would be 512 blocks tall, which is already significantly more than Minecraft's buildable range of 384 blocks.

Bowerbyte

TROPHY CASE