Hantverk'n
A downloadable game
Work in progress!!!
Hantverk'n™ is a voxel adventure & exploration game with an open "sandbox" world . Game play will include removing and placing blocks (made of voxels or even individual voxels), ores, item crafting, monsters and varied terrains by biome. Voxels will be tiny at 1/8 (or 1/16) of a meter.
Main to-do list:
- dynamic lighting
- sunlight
- color light sources such as lamps and torches
- anti-light sources (light suckers)
- procedually generated terrain and vegetation
- reflections
- transparent voxels (which filter light color)
- volumetric fog
- physics
- which allows trees to fall when cut down
- objects which rotate on pivot points (think Dutch windmills with turning blades)
- crumbling and falling voxel structures
- flowing liquids (water, lava, milk, etc.)
- vehicles made of voxels of any reasonable size (with moving parts)
- sailing ships
- airships
- minecarts
- world dynamic voxel volume (chunk) paging
- player modes
- single
- multiplayer
- creative
- see/walk through non-euclidean portals (both between dimensions [worlds] and within the same dimension)
- procedurally generated buildings, villages, structures, castles, etc.
- procedurally generated sounds (along with prerecorded/composed)
- animals
- NPCs
- plugin system
I'm implementing the engine for this game which uses high performance voxel volume based tetrahexacontree ray marching rendering from scratch in GLSL and C++ using the Vulkan graphics API. Voxels are rendered without the use of triangle meshes (not counting one quad made of two triangles that covers the entire screen) for more rendering flexibility and a much lower video card RAM footprint. I'm using ImGui for some of the user interface screens.
Initially I'm planning on releasing single-player mini-advanture/quest games with this engine that are donation based. Once creative and multiplayer mode, and load/save game support is added, I will make the full game available for purchase.
"Hantverk" is a Swedish noun meaning handicraft. "Hantverk'n" is a tribute in name to Mojang Studios and their creation Minecraft.
Development log
- Voxel-level ambient occlusion optimization bits generation via compute shader22 days ago
- Image rotation via shearing27 days ago
- Rotation without rotating28 days ago
- Voxel volume mipmaps generation via compute shader29 days ago
- Dynamic global illumination methods41 days ago
- More ambient occlusions optimizations68 days ago
- Procedurally generated grooved, cracked brick blocks71 days ago
- Procedurally generated cobblestone blocks with surface indentations71 days ago
Comments
Log in with itch.io to leave a comment.
This project is so underrated.
Thank you! I'm doing my best to create my "dream" voxel engine (within the confines of my abilities as a software engineer).
I'm considering at some point when my voxel engine is fully functional and multi-platform (Windows, Linux and maybe other OSs), I may release the voxel engine as a SDK in closed source form (object code, C++ headers, SPIR-V shader code) under a licence where free games could use it for free and commercial games would pay royalty per copy of games sold.
Yeah I'm currently planning on open sourcing my engine. what can I say, I like free stuff, I assume everybody else does as well. royalties is a pretty fair way of doing it, personally I prefer paying for a onetime license (if just for the current version).
And the list gets longer! lol
How do you handle the voxels? chunks? octree's? one giant array? I'm just curious.
I'm using a tree data structure (tetrahexacontree) of voxel volumes (chunks). Each voxel volume is 16x16x16 voxels in size. The tree data structure is only limited by RAM and it grows in size on the fly if something is placed outside of the tree data structure.
P.S. The tree data structure and voxel volumes primarily reside in host RAM (CPU side) where changes are made. The tree data structure and voxel volumes are also maintained / updated in buffers (parallel arrays) on the GPU RAM where the ray marching is done. The tree data structure on both CPU and GPU side consists of an array of tree nodes and an array of voxel volumes with nodes and volumes being indexed by offsets into said arrays (rather than pointers which GLSL does not support).
P.S.P.S. I hope I didn't make that confusing in the way I explained it. Feel free to ask more questions.
So the volumes are stored in RAM, and updated by the GPU? (The last bit about the pointers and whatnot has my scratching my head.)
No need to worry about the pointer thing if the programming language you are using doesn't have them. I'm a C++ programmer, so that's why I mentioned pointer.
Yes, the volumes are stored in an array in (CPU) RAM and are modified by the CPU during volume generation, block add, remove, etc. After the volumes are modified by the CPU, updates are sent to GPU RAM via Vulkan graphics API buffers. (There will be some compute shader updating going on later, but right now it's all done CPU side.)
I do know what pointers are. I don't work with them yet, I'm still learning c++
(I'm still reading the rest of your reply)
So just curious, How is your tetrahexacontree differ from a sparse voxel octree?
A tetrahexacontree is like an octree except at each node it subdivides space into 64 children (4x4x4) instead of 8 children (2x2x2) with an octree. The tetrahexacontree I've implemented is a sparse data structure. One can think of it as a squashed octree in that for a given amount of leaf nodes, it has half the depth. Less depth means better performance for ray marching because there is less moving up and down the tree (via a stack). My implementation of the tetrahexacontree has voxel volumes (16x16x16 voxels) for leaf nodes.
Hmm so its just an octree, with more children per leaf? what's the depth?
With a large scene loaded, I'm seeing a tetrahexacontree depth of four.
Here's a screen shot with tetrahexacontree nodes and volumes shown as wireframe cubes:
The blue lines are a corner of the tetrahexacontree root node, green wireframe cubes are nodes in between the root node and the voxel volumes, and the red wireframe cubes are the voxel volumes.
Yes, it's just a octree with more children per node.
Here's an animated gif showing a scene with and without tetrahexacontree wireframe display (click image to see large version) :
Everything I am seeing looks so amazing. You are doing great, keep up the awesome work!
Thank you!
looks good
Thank you!
I'm planning on a full creative mode besides easy ways to build things in regular player mode (beyond building things one voxel at a time which would be tedious).
Interesting.
Thank you!