Intermediate Voxelius devlog

I ultimately decided against rewriting Voxelius from scratch and instead just adapting all the knowledge I gained when working on CAQ software at work and on QFortress/QFengine at home; because most of the things came from QFortress, this also serves as a short development log into it although I really doubt it will see the light of day as a game… Instead, I may as well just make Voxelius a shooter. Imagine TF2 but with voxel destruction around some parts!

QFengine forward-porting

A lot of things came from a private repository that sometimes changes its name around with a pool of variants including voxelius-rewrite, qfortress and qfengine. So when I decided to revisit Voxelius, I ported a lot of stuff from there:

Build scripts (now they reside in tools subdirectory hence they don’t trash the repository root);
C++20 features: std::bit_cast instead of floathacks, std::string_view instead of const char* almost everywhere where it makes sense (and it’s actually sometimes faster than C strings);
Thread pool wrapper architecturally moved into the core library;
RTTI-based (std::type_index) resource management system. Now instead of defining a hashmap in every resource loader separately with implemented templates, everything is abstracted with a simple API for loading, looking up and cleaning up resources;
Clang-format config and code style improvements: more line break penalties (so the formatter is encouraged to not split argument and parameter lists before at least placing a single one on the line before breaking) and split subdirectory includes;
Nuked out include guards (ifdefs) in favor of #pragma once;
Header-only typed AABB implementation (math::AABB<T>), so ChunkAABB is now a typedef. It always bothered me how I just copypasted the math::AABB and replaced glm::fvec3 with chunk_pos;

Metavoxels: `world::Voxel` and `world::Item`

I decided to refactor how voxel and item registry works a bit. Now it operates with pointers to a Voxel class which can be modified if instantiated as a VoxelBuilder class. It basically contains the exact same information as VoxelInfo did except with a more safe approach of only allowing the external code to modify voxel atlas plane offsets…

The exact same thing happened with items, although the item system is still very yuck and will be revised later in the development.

Metavoxels: random ticking

Now world::Voxel has three callback functions for when a voxel is placed, removed or randomly ticked. Random ticking happens in the same manner as with Minecraft and allows a plethora of things to happen. Currently grass spreading and decaying under voxels is implemented.

New versioning schema

The major version is the protocol version now and the clientside UI now accounts for this. Plus most packets now transmit the full version triplet:

Red badge is when the triplet’s major value differs, the client will not be able to connect to the server regardless, and I presume the server will just kick the client as soon as it tries to connect;
Yellow badge signifies minor or patch versions differing. This might not be critical but the server config now features an option that allows operators to allow players with differing minor and patch versions to play;
Green badge signifies a fully matching game version;

TODO

Refactor the core part of the game: io subdirectory should contain things like file handling, GLFW windowing, input drivers, etc; gui subdirectory should contain GUI stuff, maybe split ingame UI into hud or gui/hud; game subdirectory should contain actual gameplay-related code.