Green Engine
The engine written because nothing available would run the game we wanted to make. A C++ core, the game itself in Rust running as WebAssembly inside it, and a world made of separate planes joined by portals.
What it is made of
-
Planes and portals.
A level is a set of planes: separate coordinate spaces that coexist in one level without occupying space in each other. A portal is a bounded surface that connects two of them, rendered by drawing the far side into it, so a doorway can lead into a space that has no position in the room it is entered from. Each plane runs its own physics and streaming, and a crossing is a hand-off between registries, with no fade and no load.
-
Rust as WebAssembly.
Every level, entity and item is a Rust module compiled to WebAssembly and loaded at runtime; the engine itself contains no game code. One schema file declares every function a module may call, generates both sides of the boundary, and is hash-checked at load, so the two cannot drift. Each script runs under an instruction budget, so one badly behaved entity cannot slow a level for everyone in it.
-
One material, three uses.
An authored asset carries its own data, its attachment points and the name of the behaviour that drives it; a mesh on its own is only geometry. A material is one description read by rendering, physics and audio together, so a surface looks, feels and sounds like the same thing. New content ships as data and reaches players in a running world without a new client.
-
Grown from a seed.
Large and endless levels are generated from authored pieces by deterministic rules. The client and the server grow the same geometry from the same seed, so the network only ever carries what changed, never the world itself. Chunks stream in tiers around each player, per plane, and coordinates are relative to their chunk, which keeps precision intact however far from the origin someone walks.
-
Real loudness.
Sources carry real sound-pressure levels and the mix keeps that range instead of compressing it, so a gunshot indoors is as loud as it should be. Walls occlude and colour sound by their material. The listener has a hearing model: a loud event leaves ringing and muffling, repeated exposure leaves damage, and ear protection is attenuation. ASIO and MIDI devices are supported.
-
One server per level.
Everything that matters is decided on the server, which treats the client as a renderer with local prediction. Each populated level runs as one process on one machine and is never split across several, because people converging on one spot is something the game is built to produce. Every item has a server-minted identity, so duplication is impossible rather than detected.
-
Traced light.
Lighting is ray-traced: direct and indirect light are sampled against the scene each frame, reused across pixels and frames, cached in world space and denoised. This is the approach the industry has settled on. What is particular here is that the traced state is kept per plane, and a portal is lit as a window showing what is beyond it. Cameras carry focal length, aperture, shutter and sensitivity, so exposure and depth of field follow from those.
-
Breaking the client.
Some levels in the canon exist to destabilise the game, and the engine supports that as content: shaders glitch, audio corrupts, the UI breaks, and at the far end the client really does crash, on purpose and through one gated call. It never touches anything outside the game's own process, the player's state is saved before it fires, and the level warns first.
At a glance
- C++23. SDL3 for the window and input, bgfx over the graphics APIs, Jolt for physics, EnTT for entities, miniaudio under the audio.
- Rust, compiled to WebAssembly and run by the engine in Wasmtime. One schema file generates both sides of the boundary; the hash is checked at load.
- Planes joined by portals. Each plane has its own physics and streaming. Large levels are generated from a seed on client and server alike.
- Vulkan and Direct3D 12 at parity, with ray queries on both. Direct3D 11 as a fallback path. Built to run the full pipeline at minimum quality on an entry-level ray-tracing card.
- Real sound-pressure levels, material-based occlusion, a hearing model on the listener. ASIO and MIDI through one device interface.
- Windows and Linux
- The game client, the editor, the dedicated server, and a crash reporter
- Not offered. Green Engine exists to run Backrooms Universe and nothing else.
Built for one game
Green Engine is a purpose-built engine, not a general one. Every system in it exists because Backrooms Universe needs it, the game's requirements are so specific that we needed to build the engine, and it is very unconventional. Levels that never reset, non-Euclidean space, lighting and sound that need to behave realistically in a world that does not follow the laws of reality.
The editor is the authoring tool and renders through exactly the same pipeline as the client, so what an author sees is what ships. The game itself is on the Backrooms Universe page, and the reasons for all of it are on the Vision page.