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.

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.

town-hall Devlog #1

Hello guys! I have started this little side project for two reasons. The first is that I want to take some time off to code without any help from AI. The second is that I have had a long-term interest in economics that I am only now beginning to acting on. Town Hall is an extremely simple economic simulation. The world I am modeling is one where everyone knows everything, there is only one kind of resource, people die if their resource count is 0 and people have full control over their resources and can invest them however they want (basically extreme capitalism). The scenario has some resemblance to real life but is exaggerated in some areas and extremely simplified.

The two biggest questions are:
What actions can an individual take?
AND:
How does an individual decide what action to do?

I have not fully answered the first question yet but for now I have added in these different options to serve as placeholders:

• Conserve
  This one basically means that they do nothing with their resources.
• Predict/Invest
  This one means that they invest x amount of money on someone else’s success and get rewarded for how good the prediction was.
• Give
  Giving means that they simply transfer their money to someone else, this one is just here to see if some rich people will do philanthropy or something.

I am not super happy with these options and it is just something I came up with after a moment of thinking, it WILL change later.

The answer to the second question is that we are going to let the individuals “think” using neural networks. We can have as many inputs as we want and randomized weights and biases that determine the behavior. The output neurons will translate into some action. Pretty simple stuff. Since entities die when they have no resources and the amounts of resources are finite the neural networks that are better at gathering resources will be those that survive over time. Later on I might make new brains inherit some weights and biases from their parents as well to strengthen this dynamic.

The complexity here is that I want this to run on the GPU so that we can run big simulations without having to wait for several minutes. This means that I have to find some library that can do computational work on the GPU. I also have to store the neural networks in a GPU-friendly way so that I can easily send all of them in one batch. A few months ago I vibecoded a Vulkan matrix multiplier (GEMM) that works pretty well so I decided to use that.

Now the big challenge was to find a way of storing the weights and biases of the different networks in a convenient way. I decided on having a struct called BrainPool (yeah I don’t love that naming lol) that holds all the weights and all of the biases of every single brain of the entities in two different vectors as well as two vectors that store the offsets for the entities in the weights and biases vectors. The last part means that the EntityId that all entities contain can be used to look up the associated brain’s weights and biases. This part took some time to figure out and I also had to do some research as well which also took time.

Thanks for reading this far! This is all very early in development and hopefully I will have a basic version of it working in the next devlog. I am thinking of making this more graphical in the future. If you have any suggestions for improvements or functionality I would appreciate it if you wrote it in a comment. Have a good rest of your day!

town-hall Devlog #1

Hello guys! I have started this little side project for two reasons. The first is that I want to take some time off to code without any help from AI. The second is that I have had a long-term interest in economics that I am only now beginning to acting on. Town Hall is an extremely simple economic simulation. The world I am modeling is one where everyone knows everything, there is only one kind of resource, people die if their resource count is 0 and people have full control over their resources and can invest them however they want (basically extreme capitalism). The scenario has some resemblance to real life but is exaggerated in some areas and extremely simplified.

The two biggest questions are:
What actions can an individual take?
AND:
How does an individual decide what action to do?

I have not fully answered the first question yet but for now I have added in these different options to serve as placeholders:

• Conserve
  This one basically means that they do nothing with their resources.
• Predict/Invest
  This one means that they invest x amount of money on someone else’s success and get rewarded for how good the prediction was.
• Give
  Giving means that they simply transfer their money to someone else, this one is just here to see if some rich people will do philanthropy or something.

I am not super happy with these options and it is just something I came up with after a moment of thinking, it WILL change later.

The answer to the second question is that we are going to let the individuals “think” using neural networks. We can have as many inputs as we want and randomized weights and biases that determine the behavior. The output neurons will translate into some action. Pretty simple stuff. Since entities die when they have no resources and the amounts of resources are finite the neural networks that are better at gathering resources will be those that survive over time. Later on I might make new brains inherit some weights and biases from their parents as well to strengthen this dynamic.

The complexity here is that I want this to run on the GPU so that we can run big simulations without having to wait for several minutes. This means that I have to find some library that can do computational work on the GPU. I also have to store the neural networks in a GPU-friendly way so that I can easily send all of them in one batch. A few months ago I vibecoded a Vulkan matrix multiplier (GEMM) that works pretty well so I decided to use that.

Now the big challenge was to find a way of storing the weights and biases of the different networks in a convenient way. I decided on having a struct called BrainPool (yeah I don’t love that naming lol) that holds all the weights and all of the biases of every single brain of the entities in two different vectors as well as two vectors that store the offsets for the entities in the weights and biases vectors. The last part means that the EntityId that all entities contain can be used to look up the associated brain’s weights and biases. This part took some time to figure out and I also had to do some research as well which also took time.

Thanks for reading this far! This is all very early in development and hopefully I will have a basic version of it working in the next devlog. I am thinking of making this more graphical in the future. If you have any suggestions for improvements or functionality I would appreciate it if you wrote it in a comment. Have a good rest of your day!

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!

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 #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!