Voxelius devlog (0.0.1.2501)

This is a yet another collection of release notes for Voxelius 0.0.1.2501. This time I have some time to spend on actually work on the game (because it’s New Year holiday week in Russia), so I was actually able to commit some very big and important things into the project, actually making it feel like an actual video game.

Collision detection and gravity

I finally decided to make a semi-significant gameplay change and gave players a collision hull that can now interact with the voxel world. The entire collision detection system is still kind of… weird, I guess? If your velocity is high enough, the system will stop you before you actually touch a voxel’s edge which visually looks like you land on a pillow. But anyways it’s definitely a system and it works.

View rolling

Since players now can move on the ground, it makes sense to add a visual feedback to when the player moves sideways; and I know just a thing that does it: view rolling! When the player moves sideways, view angles are modified with a custom roll value that is calculated like this:

angles[2] = radians(-roll_angle * dot(velocity / max_speed, right_vector))

And the visual result looks really decent and actually gives a Quake/Half-Life feeling to the entire movement system:

Actual Quake/GoldSrc movement

The old movement code was using something one can call an infinite-impulse-response filter to accelerate/decelerate the player according to the wish direction they want to go in. This approach was very framerate-dependent.

Don’t get me wrong, it’s still good when you’re flying through space and I might just use that for generic flight moving for something like spectator gamemode, but for ground/jump moving I decided to implement movement that is pretty much in my muscular memory and implemented basic quake/goldsrc/source movement into the game. Yes, you can bunnyhop. Yes, it is very fun to do so!! Yes, it will persist as a game feature! And, finally, yes, this movement code may very well just migrate into a TF2-like game I have plans on making!!

New voxels

Since I implemented voxel collision to have different touch responses for different voxels, it made sense to add at least two voxels that would have different touch response types.

New voxel registry API functions to setup the touch responses have also been added:

// Slime; it's bouncy!
game_voxels::slime = voxel_def::construct("slime", VoxelType::Cube, false, true)
  .set_touch(TOUCH_BOUNCE, Vec3f(0.00f, 0.60f, 0.00f))
  .add_texture_default("textures/voxels/slime_01.png")
  .build();

// Mud; you sink in it
game_voxels::mud = voxel_def::construct("mud", VoxelType::Cube, false, false)
  .set_touch(TOUCH_SINK, Vec3f(0.50f, 0.75f, 0.50f))
  .add_texture_default("textures/voxels/mud_01.png")
  .add_texture_default("textures/voxels/mud_02.png")
  .build();

Slime

I added a slime voxel that is bouncy. When you fall onto it from a height, it bounces you up with 60% of your original vertical velocity applied in the opposite direction.

Mud

An another touch response type is TOUCH_SINK which retains your velocity but multiplies it by a factor of sorts. To test that, I added a mud block in which you sink through and it makes your walking speed 50% slower.

Item system

If you haven’t already noticed on the screenshots above, I started working on a new item registry so that the hotbar can actually show what voxel you have selected and what voxel you’re going to place.

And it does things in a literally the same way as the voxel registry, which has been renamed to voxel_def for consistency with item_def. To add a new item you also call construct and use builder functions to setup your new item:

// Cobblestone; a bunch of small stones
game_items::cobblestone = item_def::construct("cobblestone")
  .set_texture("textures/item/cobblestone.png")
  .set_place_voxel(game_voxels::cobblestone)
  .build();

Fix your timestep

A huge improvement to the entire project is named as an omage to a similarly named blog post; most implemented game logic now runs on a fixed time step and is visually interpolated.

This entire feature ensures client-side experience is very smooth regardless of what tickrate the remote server runs on. Single-player worlds always are simulated at a constant rate of 60 ticks per second.

Bug fixes

Fixed game questionably crashing and not working on 32-bit builds due to modulo operator returning negative results with negative input coordinates (which seems to not be a thing on 64-bit; perhaps, it is not implemented as a separate math operation or is optimized into a masking operation by the compiler);
Intermediate interpolation fixes that didn’t have a chance to get themselves into a release build at all;

untode.su