Samples and tests

The two sample games and what each shows, the engine's test suites and harness, and how a game adds tests of its own and runs scripted checks in the live game.

Samples

Built with the engine into build/release/ragnavoxel/samples/:

rv_Platformer2D: a pixel-art platformer on the interface-only renderer, with a tile-map level, tile collision, parallax, additive glows and Follow2DController. --stress N adds sprites, to see the batching hold up.
rv_VoxelCameras: a voxel diorama built with VoxelScene, seen through every camera rig. Keys 1 to 6 switch rigs and P toggles orthographic; --camera orbit|fly|follow|fps|iso|side, --ortho, and --voxel-size METRES (the same scene in 1/8 m blocks or 1/64 m microvoxels).

Both are a single source file you can read in one sitting, and a good starting point for a new game.

The engine’s tests

Every suite is registered with ctest:

ctest --test-dir build/release -j8 --output-on-failure

ragnavoxel_tests: the ECS, AoSoA storage, chunk compression, and the mesher’s watertightness against a brute-force face count.
ragnavoxel_unit_tests: hashes, the PRNG and noise, the job system, microvoxel models and their meshers, palettes, chunk and TileDB world persistence, Jolt physics and the character.

Writing tests

Suites are RV_TEST(suite, case) blocks, from the shared harness ragnavoxel/tests/RvTest.hpp, in a file under a tests folder; they are picked up on the next build.

#include "RvTest.hpp"

RV_TEST(inventory, equip_and_unequip) {
  // ...
  CHECK(inv.equipped(EquipSlot::MainHand).item == "iron_sword");
}

Each suite is its own ctest test (ctest -R mygame_tests.inventory), and a test program runs one suite or one case by name (./mygame_tests inventory, ... inventory.equip_and_unequip) and lists them with --list. Cases that write files should do so in a fresh directory under the system’s temporary directory.

Tests in the live game

LostVale shows how far this goes: lostvale --selftest plays through scenarios in a fresh world of its own (boot, movement, inventory, crafting, combat, weather, settlement, save and load, menus) and checks them from inside the running game, each registered with ctest under the label runtime. They need a GPU and a display; ctest -LE runtime leaves them out.

Scripted runs drive a game for screenshots and checks too: --screenshot PATH --frames N from AppConfig steps exactly one fixed step a frame, so the same script gives the same picture, and a virtual gamepad goes through SDL like a real one (see Physics, audio and input).

Written from the engine's headers and source as of commit 02e81b2 (2026-11-01).