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!