Project Watt Cubed Devlog #3

Good day people! I have been taking a bit of time off from this project for the past few days. Today has been a final surge of progress before I take another (although involuntary) break. Next week I will be away and therefore not able to work on any of my projects so this devlog is a temporary goodbye.

I have fixed an issue regarding chunk loading causing a lot of lag when moving at high speeds. The fix was to make the chunk loading scheduling system smarter by having it not try as hard when it won’t be able to load chunks in quickly enough anyway. I also fixed the audio system and added in some simple placeholder sounds. Some small additions have also been made to the documentation regarding the crafting system.

Devlog #2

Hello everyone I hope you are all doing well! Big things have happened since last time, we have worked hard on improving the architecture, fixing bugs, improving the UI, optimizing and writing down more features into the documentation. With some of these changes in place we are approaching a stage where we could call it a demo version.

One of the biggest changes is that graphics related logic in project_watt_cubed has been moved to voxel_engine. This enables a higher level of control and optimization by interacting directly with Vulkan. More specifically this meant adding in compute-shader culling and replacing per-frame terrain draw submission with GPU mesh records that stay from frame to frame (I am not listing everything to save some time). I thank RestitutorOrbis for this contribution. During the same session audio infrastructure was added in as well.

A few days later I did some testing on my own and found a bug with the chunk loading queue. The bug occured when the player was flying quickly away from chunks that were in the process of being loaded. Going away from them quickly made the process of loading them stop suddenly and corrupted the chunk loading queue. This resulted in a lot of lag and weird LODs artifacts. I also discovered that lighting seemed to not be very performant (I discovered this by disabling the sunlight setting and discovering that it made my FPS increase by 15000 lol). I gave clear instructions and advice to claude to solve this and it did, yay. Whilst flying around and testing I also decided to make chunk loading not make the chunk go transparent but instead keep the lower detail LODs look until it is done. This makes it seem like there’s just a less sharp version of the terrain there until it is fully loaded in.

Documentation

The essence of this task is to try to translate the initial vision into concepts and mechanics that can be implemented into the game. One of the hardest mechanics to figure out has been crafting. In this game crafting has to be different from other games, I do not want a crafter block that does some magic and then outputs a new block. The whole is to base features on clear rules, a crafter would be bad since it’s an arbitrary abstraction.

To be able to understand the solution I came up with you have to understand some of the fundamentals of how this game is structured. Here’s the short version: There are many different elements, they have different properties. There are two different kinds of blocks, natural blocks and configuration blocks. Blocks inherit the properties of the elements that they contain. Natural blocks are an equal blend of a collection of elements. Configuration blocks are also mixtures of elements but the elements exact position in the block can be determined by placing them out in a small voxel grid inside of the block.

The solution is to add in a blueprint block. When a blueprint block collides with a natural block the elements that the natural block is made of get placed according to the blueprint inside of the blueprint block, essentially filling it in according to its configuration. The blueprints are consumed after having gotten enough resources to complete the configuration. If further edits are to be made to the block another blueprint can be placed inside of and resources can once again be added. Blueprints can be crafted by the player without spending any resources (and maybe also autocrafted later on). There should also be a way to name blueprints things and save them for later but that will probably be through a mod.

NOTE: Much of this is not 100% decided upon yet and not all details have been discussed here. There is much more information available on github.

That’s about it for this time! Here’s some pictures of the game for you to enjoy!

Devlog #1
Hello everyone! I hope everyone reading this is doing well and feeling as excited about the Stardance challenge as I am.

I have been working on a game for some time, and it is gradually becoming my dream game. Right now, we have a voxel game running at up to 4,000 FPS on an RTX 3070 at a 20-chunk render distance on low settings. It already includes crafting, distinct world generation, an inventory system, local-network multiplayer, and a fairly elaborate modding API.

Like many teenagers, Minecraft was a major part of my childhood. Its possibilities fascinated me, and I spent a lot of time talking with friends about inventions and projects we could build together. Eventually, though, I began to find parts of the game tedious, limiting, and unrewarding.

Around the same time, I got into programming. I became interested in open-source software, customization, optimization, and strong design philosophies. That made me think again about what I had actually loved about Minecraft.

I also started learning Vulkan, probably the hardest technical subject I have attempted so far. After about half a year, I had built a renderer capable of drawing simple shapes with vertex and index buffers, along with swapchain recreation for window resizing.

Then something clicked:
I wanted to build the game I had wanted Minecraft to be.

I realized that what I loved most about Minecraft came down to two things. The first was invention: building, experimenting, and uncovering your own world. The second was people. Multiplayer gave everything meaning through conversations, pranks, alliances, wars, and large collaborative plans.

My goal became to create a focused multiplayer sandbox built around creativity, invention, and meaningful interaction. The game should be defined by a simple and enjoyable ruleset—not tedious simulation, but a foundation for experimentation and freedom.

Implemented:
Open source
Procedural generation across all three axes
Extensive moddability, including menus and game mechanics
Strong performance
Element-based blocks that derive properties from their materials
Cross-platform graphics through Vulkan

In progress:
More multiplayer-focused features
Physics and simulation optimized for fun
Distinct scenery that is rewarding to explore

Both the game and its custom Vulkan renderer are written in Rust. The renderer uses Ash, a set of Rust bindings for Vulkan. Rust is a good fit because it is fast, modern, and memory-safe.

An important disclaimer is that much of the implementation has been produced with help from AI models such as Claude and ChatGPT. I created the central concept, design direction, documentation, and early renderer work, including roughly the first twenty commits. I also make technical decisions, review and test the results, and coordinate the project. A friend has helped with some of the more recent development.

The next devlog will be faster-paced and more technical, with more focus on the actual development process and recent progress. Thanks for reading!