The Criogenio engine
Our games run on Campsur, the engine we write ourselves. Engine, editor and tools are one C++23 codebase, shaped by the games we ship: a small set of explicit systems and readable code paths rather than a general-purpose everything.
- Language
- C++23
- Platform layer
- SDL3
- Graphics
- OpenGL
- Physics
- Jolt
- Game UI
- RmlUi
- Networking
- ENet, Steam
Rendering
An OpenGL renderer for 2D and 3D on top of SDL3. glTF models skinned on the GPU, a sun and point lights that cast shadows (cube maps for every shadowed lantern), emissive glow, bloom and tonemapping, a procedural sky with a day cycle, and walls that fade out when they stand between the camera and the party.
Entity component system
Entities and components in sparse sets, systems run in ordered phases on a fixed-step clock, cached multi-component queries, and a world that saves to and loads from plain JSON levels.
Physics
Jolt Physics for 3D: rigid bodies, character controllers, kinematic movers and wheeled vehicles, synced with the ECS each step. Sprite games get a light 2D collision system of their own.
Skeletal animation
Animation sets map roles (idle, run, attack, cast) to clips, so a game asks for a role and never for a clip name. Retargeting plays clips across skeleton families, such as Mixamo-style and Unreal-style rigs. Crossfades, layered controllers with masks, clip events for footsteps and hit windows, locomotion with speed matching, characters built from separate parts, and bone sockets that keep what a character holds in its hands.
Online co-op
ENet and Steam networking behind one transport. Online co-op runs in deterministic lockstep: the host gathers every player's input for each tick and the peers compare state hashes to catch any drift. Snapshot replication with interpolation and client prediction is there too, voice chat goes through Opus, and loopback transports simulate latency, jitter and loss in tests.
Game UI
Menus, panels and HUDs are RmlUi documents styled like web pages, with data binding, gamepad and keyboard navigation, screens owned by one player in local co-op, popups and toasts, and translated text.
Live data
A game's tuning data is described once in C++ and saved as JSON. Every value can be edited while the game runs, from an in-game editor, the console or the editor's Data window, with ranges, units and tips taken from that one description, and files reload as soon as they change.
Effects
Visual effects are data too: particle emitters, meshes such as shockwaves and slashes, and floor telegraphs that warn of enemy attacks, all kept outside the simulation so they never touch the lockstep.
Editor
One editor for every project: a 2D and 3D scene viewport with play-in-editor, hierarchy, inspector and an asset browser with thumbnails; a Data window for any data asset; animation tools for clip events and animation controllers; and an effects window.
Import Animation Pack
Open a pack of clips (.glb, .gltf, .fbx or .blend), let the editor detect its skeleton family and reference pose, preview any clip retargeted on your character, give the clips you want a role, and import them cut down into the project's animation set.
The cook
Packages a game with only the files it uses: it follows every path named in the game's data, levels and code, stages the build with the libraries it loads and zips it per platform. A variant such as a demo leaves out everything past its end, and the cook fails if a shipped file still uses something left out.
Made for the games
Campsur grew with The Lantern Inn: the effects, the lockstep co-op, the animation sets and the cook all came out of what the game needed, and then became part of the engine for the next one. Every game opens with the engine’s logo and what it is built with.
Tested without a screen
Unit and integration tests run headless on every push, along with smoke tests that open each project in the editor, a health check that starts every sample game and watches its log, and golden images of the editor’s viewport.