Skip to content
AevornixAEVORNIX
CreateDeveloper Preview

Aevornix Engine

From intent to a playable world. Control, Core, AevCode and Design working as one pipeline rather than four applications you move files between.

Production path
  1. 01
    Intent
    Define the outcome, constraints and references.
    Aevornix Control
  2. 02
    Plan
    Break the outcome into tasks, dependencies and approval points.
    Aevornix ControlAevCode
  3. 03
    Build
    Create and modify scenes, systems, code and assets.
    AevCodeAevornix CoreAevornix Design
  4. 04
    Validate
    Test changes, identify failures, compare results and roll back safely.
    AevCodeAevornix Control
  5. 05
    Run
    Preview, play, profile and inspect the project inside the engine.
    Aevornix Core
  6. 06
    Publish
    Package, validate and deploy the project to supported targets.
    Aevornix ControlAevornix Core
Export pipeline

Platform relationship

Four systems. One production path.

Each system takes a defined input and hands a defined output to the next. The line between them is the part that matters; it is why this is a pipeline rather than a suite.

Four systems in one production path: Control, Orchestrates the project, the workflows and the agents. AevCode, Plans changes, validates them, and rolls them back cleanly when they fail. Design, Produces the images, textures, materials, meshes and animation a change needs. Core, Renders, simulates, edits and runs the project.

  1. Developer Preview

    Orchestrates the project, the workflows and the agents.

    In
    Your intent, and the current project state
    Out
    A planned unit of work handed to the pipeline

    Control decides what needs to happen and calls AevCode to work out how.

  2. Developer Preview

    Plans changes, validates them, and rolls them back cleanly when they fail.

    In
    A unit of work plus the project it applies to
    Out
    A reviewed, reversible change set

    Validated changes are applied to the project Core builds and runs.

  3. Developer Preview

    Produces the images, textures, materials, meshes and animation a change needs.

    In
    An asset requirement from the planned work
    Out
    Project-ready assets in engine formats

    Assets land in the project alongside the change that asked for them.

  4. Developer Preview

    Renders, simulates, edits and runs the project.

    In
    The project with its applied changes and assets
    Out
    A running scene, a test result, or an exported build

Workflow

What actually happens between intent and a build.

Six stages. Open any one for what you do, what the system does, what it produces, and what happens when its check fails.

Six stages: Intent, Plan, Build, Validate, Run, Publish. Each stage lists the user action, the system action, the produced output, the product responsible and what is validated.

  1. IntentOpen
    You do
    Define the outcome you want, with its constraints and references.
    The system does
    Control reads the current project state and scopes the request against it.
    Output
    A scoped request tied to a specific project
    Validation
    The project must validate before work is scoped against it.
  2. PlanOpen
    You do
    Review the proposed change before anything is written.
    The system does
    The outcome is broken into tasks, dependencies and approval points, and AevCode produces a plan naming every file it intends to touch.
    Output
    A reviewable plan
    Validation
    A plan that would write outside the project is rejected at this stage.
  3. BuildOpen
    You do
    Approve the plan.
    The system does
    The pipeline applies the change and generates the scenes, code and assets it needs.
    Output
    Applied changes and generated assets in the project
    Validation
    Changes are applied as a reversible set, so a failure part-way is not a half-written project.
  4. ValidateOpen
    You do
    Nothing, this runs automatically.
    The system does
    The project is validated and the test layers are run against it.
    Output
    A validation report and test results
    Validation
    A failed check rolls the change back rather than leaving it applied.
  5. RunOpen
    You do
    Play it.
    The system does
    Core materialises the runnable project and runs it, in the editor or headlessly.
    Output
    A running scene, or a headless test result
    Validation
    Tests that need the engine run in the engine, they skip rather than pass when it is absent.
  6. PublishOpen
    You do
    Choose a target and ship.
    The system does
    The release gate runs, then the build orchestrator produces the target.
    Output
    A build for the selected target
    Validation
    A critical test failure blocks the export. A missing toolchain reports a staged result rather than a fake success.

Capabilities

What the engine builds.

Eight areas, each carrying its real stage. Where an area is partial, the description says how it is partial rather than rounding it up.

World building

Scene generation, streaming cell grids for large worlds, and world validation. Streaming loads and unloads by radius around the player.

Available in preview

Gameplay systems

A game-flow spine (boot, game management and state) plus a live visual scripting runtime with breakpoints, stepping and per-node profiling.

Available in preview

Activity design

Mission and activity composition over generated worlds. Proven end to end on a full demo project, but the authoring surface is still thin.

In active development

Character systems

Greybox character rigs with skeletons, plus animation authoring. Production-quality character tooling is not built.

In active development

Interface and HUD

Interface and HUD construction as part of the pipeline, verified in-engine.

Available in preview

Audio and cinematics

Audio system construction and bus routing, verified in-engine. Cinematic sequencing is the thinner half of this area.

In active development

Multiplayer services

Real networked multiplayer (peer transport, remote calls and server authority) verified with two peers in-engine. Session and lobby services sit above it.

Available in preview

Project export

A release gate followed by platform ship targets. A missing toolchain reports a staged result instead of a build.

Available in preview

Evidence

What has actually been verified.

Each item names its source and the date it was last checked.

TEST RESULT

Engine test suite

The full engine test suite runs green. The count is a point-in-time fact from the run named below, not a rolling claim.

Result
783 tests passing
Command
npm test
Scope
Engine monorepo: CLI, forges, export centre, patch system, store
Last run
2026-07-25

Source: `npm test` at the engine monorepo root · Verified

EXPORT SAMPLE

Project structure

An Aevornix project is a declarative `project.aev` plus authored sources. The runnable engine project is materialised from it into a disposable runtime directory, so generated output is never the thing under version control.

project.aev
Canonical project definition: display, input actions, rendering
game/
Authored native sources: .aevscene, .aevmat, .aevmesh
.aevornix/runtime/
Materialised runnable project (disposable, regenerated)
.aevornix/reports/
Validation, test and release-gate output

Source: Project format as materialised by the runtime adapter · Verified

BUILD OUTPUT

Windows build output

A project taken through the release gate produces a real Windows executable. The gate blocks the export when a critical check fails, so a produced build is a passed build.

Target
Windows
Output
Executable produced
Gate
Release gate passed, a critical failure blocks the export

Source: Build orchestrator run, release gate followed by the Windows ship target · Verified

RELEASE

Assets sourced from the Aevornix Store

Asset browsing inside the editor resolves to the live Aevornix Store rather than a third-party asset library, so projects draw on the same catalogue the Store serves publicly.

Source: store.aevornix.com, reachable and serving the catalogue in production · Verified

Targets

Where a build can go, and how far each one is proven.

Four targets, each at its own stage, listed separately rather than as one capability.

Windows

Build status
Produces a real executable through the release gate.
Testing status
Verified: builds run, and the test layers execute against the built engine.
Known limitations
The single-file executable requires a built release template; without one the build uses the runtime-plus-package model.
Required setup
None beyond the preview install.

Linux

Build status
Export path implemented; reports a staged result when the platform toolchain is absent.
Testing status
Not verified end to end on a Linux machine.
Known limitations
Staged output names exactly what is missing rather than producing a build that will not run.
Required setup
A Linux build toolchain on the build machine.

Web

Build status
Builds for the browser through the WebAssembly toolchain.
Testing status
Verified to render in a browser.
Known limitations
Browsers have no Vulkan, so web builds render through the OpenGL-compatibility path rather than the forward renderer. A web build left on the desktop renderer shows a grey screen, the export sets the compatibility renderer for you.
Required setup
The WebAssembly toolchain, provisioned by the preview.

Xbox Developer Mode

Build status
Produces a Windows app package for sideloading onto a console in Developer Mode.
Testing status
Package production verified. Running on console hardware is not verified.
Known limitations
This is the Developer Mode route, not retail publishing. The Game Development Kit path is a packaging scaffold only, it stages rather than producing a package when the kit is absent.
Required setup
A console enrolled in Developer Mode, and the Windows SDK on the build machine for packaging.

Technical foundation

How it is built.

The decisions underneath the pipeline, the ones that determine what it can and cannot do.

Project format
A project is a declarative `project.aev` plus authored native sources. It owns display, input actions and rendering configuration, and it is the thing under version control.
Runtime model
The runnable engine project is materialised from the declaration into a disposable runtime directory. Generated output is never the source of truth, so it can be regenerated at any point.
Rendering approach
A Vulkan forward renderer on desktop, with an OpenGL-compatibility path used where Vulkan is unavailable, notably in the browser. Quality tiers and geometry optimisation sit on top.
Agent integration
Agents are part of the editor rather than an external tool. They call the same command surface the interface does, so an agent cannot do something the interface cannot describe.
Asset pipeline
Assets come from the Aevornix Store, from external files, or from the Design suite. Imported assets are recorded in the project so a materialised runtime can be rebuilt from the declaration.
Version control behaviour
Git underneath, with project-level locks, ownership and review mode over it. The disposable runtime directory stays out of version control by design.
Build system
A release gate runs the test layers first; a critical failure blocks the export. Only then does the build orchestrator run the ship targets.
Export paths
Standalone executables, installers, app packages and browser builds. Every path reports a staged result with the missing toolchain named, rather than reporting success it cannot back.

Development

What is being worked on now.

Filtered to the engine and creative tools. Dates appear only where a specific verifiable event backs them.

Active(2)

  • Engine Developer Preview

    Developer Preview

    Take the Control, Core, AevCode and Design pipeline from internal use to a preview developers outside the team can run.

    Depends on
    Preview distribution · Documentation
    Last update
    : Engine test suite green (783 tests, npm test, 2026-07-25)
  • Export targets

    Developer Preview

    Broaden verified export coverage beyond Windows, and raise the staged targets to verified.

    Depends on
    Platform toolchains
    Last update
    : Windows executable produced through the release gate

Next(1)

  • Engine documentation

    In Development

    Publish a documentation set covering the project format, the pipeline and each export target.

    Depends on
    Engine Developer Preview

Completed(1)

  • Let projects pull assets directly from the Aevornix Store instead of a third-party asset library.

    Depends on
    Aevornix Store
    Last update
    : In-editor asset browsing repointed to store.aevornix.com

Build with the Aevornix Engine.