VYREX INTERACTIVE
Technology

Vyrex Engine

Vyrex Engine is our own engine. It is written in C# on .NET, it is not built on a licensed engine, and every game we make runs on it. That is a slower way to start and a much better way to finish: when a frame is slow or a collision is wrong, the fix is in our code, not in a support ticket.

It is built for the games we actually make. Big worlds that stream in around you, destructible terrain, exact-shape collision at speed, and multiplayer that survives a real connection rather than a loopback test.

C#Written in
DX12 + VKRenderer
OursPhysics

Mod our games

VrxScript, the editor and the asset tools are public. The modding board on the forums is where the tooling questions get answered.

Modding forum Support
Under the hood

What the engine does

Rendering

A renderer written from scratch: DirectX 12 on Windows, Vulkan on Linux, with a separate hardware-accelerated 2D path for the top-down game.

  • One renderer, two backends. Shaders, materials and the frame graph are shared, so a Linux player gets the same picture as a Windows player rather than a cut-down port.
  • Physically based materials, image based lighting and a deferred post chain: bloom, ambient occlusion, depth of field and motion blur.
  • Hardware raytraced reflections and sky lighting on cards that support them, with a raster fallback on cards that do not.
  • Optional tessellation and parallax occlusion mapping, both off by default so they stay a choice rather than a tax.
  • A batching Direct3D 11 renderer for the 2D game: one vertex format and one shader for sprites and shapes, so a full scene draws in a handful of calls.
  • Multisampling, a cached text rasteriser, and a frame pacer that holds a stable frame rate instead of leaning on the driver.

Worlds and voxels

Both games stream their worlds in around the player, and the terrain is real volume data rather than a static mesh.

  • Chunked surface nets terrain that can be dug, carved and rebuilt at runtime.
  • Carve and ore state is saved per chunk, so a tunnel you dug is still there when you come back.
  • Landable planets are playfields the engine loads in place, not separate levels behind a loading screen.
  • Physics is rebased to a local origin near the player, which keeps collision accurate in worlds that run to millions of units across.

Physics

Our own physics engine, forked from Box2D and Box3D and rewritten to fit the games. Collision is exact shape against exact shape.

  • Convex hulls built from the real meshes, swept along the movement path so nothing tunnels through a wall at speed.
  • Collide and slide response with penetration recovery, so contact glides along a surface instead of bouncing off it.
  • The 2D game runs the 2D fork, kept to contact resolution so movement and network prediction stay deterministic.
  • Owning the solver means we can tune it for space-scale worlds and for netcode, rather than working around someone else's defaults.

Multiplayer

The netcode is host authoritative and built for real sessions, not a demo.

  • UDP transport with sequenced state channels and reliable ordered channels for everything else.
  • Client side prediction with server reconciliation for your own ship, so input stays responsive on a real connection.
  • Dedicated servers for both games, native on Windows and Linux, listed in the Steam server browser and on our own master list.
  • Steam lobbies, ticket based authentication, late join replay of world state, in-game voice chat and text chat.
  • Easy Anti-Cheat integration for online play.

Audio

FMOD Studio drives the mix, with the banks built as part of the normal build.

  • Positional audio for weapons, engines, mining and ambience.
  • The bank pipeline runs headless, so audio builds on the same machines as the code.

Assets and file formats

The engine ships its own formats. Source art is converted once at import time and never at runtime.

  • .vrxtex textures: BC7 blocks with a full mip chain, 2D and cubemap.
  • .vrxmdl models and .vrxanm animation clips, converted from FBX, OBJ or GLB.
  • .vrxcfg for all content definitions, .vrxsav for world saves.
  • Loading is a binary read with no importer in the shipping build, which is most of why load times are short.

Tools

The tools are built on the same code as the games, so what you see in them is what the game does.

  • Vyrex Editor: a mod manager and a full script IDE with syntax highlighting, completion and live error checking.
  • Asset Builder for batch conversion, and Asset Viewer for previewing converted models and textures without launching a game.
  • Command line converters for pipelines and automation.

Modding with VrxScript

VrxScript is the engine scripting language. It compiles to bytecode and runs in a sandbox.

  • Scripts see a published gameplay API and nothing else. No file access, no network access, no reflection, and no reach into rendering or netcode.
  • A fuel budget and a recursion cap per event, and a script that keeps throwing is disabled instead of taking the game down with it.
  • Server scripts run only on the world authority and receive the sender identity from the packet, so events cannot be spoofed by a client.
  • Mods package scripts, textures, models, animations and data in one folder, and can be shared through the Steam Workshop.

Platforms and builds

Every release is built for Windows and Linux from the same source, on the same day.

  • Native ahead of time compilation on both platforms, so builds start fast and ship without a runtime install.
  • Release builds are obfuscated and code signed.
  • The dedicated servers are headless builds of the same engine, not a stripped side project.
In use

Games built on it

All games
In Development

Starbreaker

A full-3D open-space sandbox: fly, land, build, and break the black.

Licensing the engine is not something we offer today. If you want to build with it, the modding SDK is the way in, and we read the forums.