Roadmap

Audited against the source rather than against prior documentation. The absent rows are here for the same reason as the shipped ones: you should be able to decide against this engine using its own documentation, and find out on day one rather than in week three.

The full working document lives in the repository as Roadmap.md, with the dependency reasoning behind every ordering decision. This page is the public summary of it.

Baseline: rendering

One fact that sets the cost of several items above. The pipeline is forward rendering — pipeline states are organised as Opaque / Transparent / Fade with cull variants, with a storable depth target and a velocity target. There is no G-buffer. That is why reflections and decals are gated on adding a normal target, and why deferred decals are not simply "next up".

Baseline: host and world editing

Baseline: AI and foundations

The foundations block is deliberately unflattering. The project's central claim is that architectural minimalism recovers what a managed runtime costs — and that claim currently has no measurement behind it. Fixing that is Track D, and it is not scheduled late.

How the work is grouped

Work is grouped into tracks that map to the questions the project actually faces. Ordering inside each track is by dependency, not by appeal — several attractive features sit late because their prerequisites are infrastructure work across four backends.

Track A — Rendering

Three of the items are not features at all but infrastructure the others sit on. They are unglamorous and none of them produce a screenshot, which is exactly why they are named explicitly instead of being discovered halfway through building particles.

Why the order looks like that.

• Motion blur is first because it is nearly free: the velocity buffer already exists and TAA already consumes it. What is missing is one resolve kernel.
• Texture compression is not a visual feature. It is package size, web viability and the largest single frame-time win available on the integrated GPUs most evaluators will run this on. Runtime decode to uncompressed is an explicit anti-goal.
• SSR waits for the normal target because marching against depth-derived normals and adding the buffer afterwards means writing the resolve twice. On miss, SSR will fall back to the DDGI irradiance atlas — engines without a GI volume have to ship a separate reflection probe system to avoid black misses.
• GPU culling waits for a benchmark, not just for indirect draw. CPU frustum culling already ships and is on by default; without a recorded baseline there is no way to show the GPU path is faster. At ten thousand entities in a managed engine, the bottleneck is more likely per-entity Update cost than draw submission — and if so, A7 is the wrong fix.

Track B — Host and shareable worlds

An editor is a demonstration surface, not the workflow. It exists so the renderer can be seen. It does not exist to become the way the engine is used.

• B0 — decouple the shell from the scene. Today Create() builds the whole island unconditionally. "Run with no world loaded" and "create a new world" are the same capability, and everything else in this track needs it first.
• B1 — world serialization. The design rule comes before the format.
• B2 — editing affordances. Placement, then gizmos, then a property editor over construction parameters only, then hierarchy inspection, then undo.
• B3 — asset catalogue, with licence attribution as a required column, because bundled assets travel with shared worlds.
• B4 — a second reference world: mass unit scheduling. Tens of thousands of independently updated, individually animated units, instrumented from the start. It doubles as the benchmark A7 requires.

The anti-fragmentation contract. A serialized world record is a C# type name plus construction parameters. It is never a bag of properties with attached behaviour fragments. Layout is data; behaviour is code; the boundary is the type name. That single constraint is what keeps this from becoming an inspector-assembled component model.

That distinction has to be explicit in the format and visible in the UI, or the project inherits the exact dependency problem it is trying to avoid: a shared world that silently fails to load because a type is missing.

Track C — AI

• C1 — generated output into the engine. Eight generation capabilities ship and none of their output can become an engine asset. Generated image to material texture, to 2D sprite, generated audio to a playable source, a stable generated-assets folder — and the reverse direction: pick an object, send its current texture to image-to-image as the reference. Small work, and the highest return on effort in the whole roadmap.
• C2 — cloud models plus runtime C# generation, desktop only. An HTTP client with streaming and user-supplied keys, plus Roslyn compiling C# at runtime. The architecture is already shaped to receive the result: a behaviour is a Panel or Control subclass, so a generated class only has to be instantiated and added — no serialization format to satisfy, no component model to register with.
• C3 — 3D asset generation, static props only. The generation model is the small part; mesh decimation, UV unwrapping, normal repair and a glTF exporter are the work, and none of that exists today.
• C4 — automatic rigging. Research, not a commitment. It will not appear on a store listing before output quality is verified against real characters.

C2 comes before C3, which inverts the intuitive order. C2 is an HTTP client plus a Roslyn host; C3 is a mesh pipeline plus an exporter plus a model. C2's quality is supplied by frontier models and improves for free; C3's is capped by what local 3D models produce today, which is not yet drop-it-in-a-game quality. And C2 exploits something this engine has and its competitors do not — behaviour as a single compilable C# class.

Runtime C# compilation is unavailable under full AOT, which rules out iOS and WebAssembly. That constraint is stated rather than worked around: the feature is desktop-only by nature.

Track D — Foundations

Every item here is either a prerequisite for proving a claim in another track, or a prerequisite for the project surviving contact with contributors.

• D1 — benchmarks and image-diff regression. Fixed camera paths, fixed frame counts, recorded frame time, draw count and allocation. Plus headless reference-image comparison per backend: for a project whose pitch is the renderer is real, a silent visual regression is the most expensive possible bug, and the failures this codebase actually accumulates — per-frame buffer cross-talk, uncleared atlas memory, struct layout drift, shader divergence between four APIs — are exactly the kind a compile check never catches.
• D2 — frame allocation budget. Pure C# engines are dismissed on exactly one axis, GC pauses, and that will appear in the first community thread. The answer cannot be prose. "Zero bytes allocated per frame at ten thousand animated instances" ends the argument in one line; nothing else does.
• D3 — asset pipeline, absorbing texture compression, LOD generation, mesh decimation and import caching. The runtime must keep loading plain glTF and plain PNG directly: the pipeline is an optimisation, never an entry requirement.
• D4 — documentation and a sample ladder. A minimal BaseApp under 50 lines, one-concept samples, and a written walkthrough for adding a compute effect — currently the most contributor-friendly extension point in the engine, and discoverable only by reading Ddgi.cs.
• D5 — platform honesty. No fallback paths. Features declare requirements, unsupported features are visibly disabled with a stated reason, and the backend matrix is generated from the same source.

Track E — VR / XR

The renderer is single-view by construction: one camera per frame, matrices bundled per object, static render-target singletons, window-vsync frame pacing, pointer-only input and screen-space UI. Every one of those is an assumption VR breaks. So this track is deliberately last — it is a new platform claim, not a feature on the existing one.

A0.4 — the per-view matrix split — sits early in Track A precisely so the hardest refactor is paid for long before this track starts, and while the scene pass is already open for the normal target.

Phase view

Dates are intent, not commitment.

Phase 4 and beyond. A8 mesh LOD and A9 terrain; C3 static prop generation; C4 auto-rigging if quality justifies it; Track E starting as a Windows and Direct3D 12 pilot, then Quest; Mac and mobile store presence. Console technical adaptation is acknowledged and scheduled nowhere — it is gated on SDK access, which is gated on the engine's standing rather than on engineering effort.

Non-goals

A roadmap without these is a wish list. Each of the following is a decision, not an omission.

• Competing on feature count with editor-centric engines.
• Visual scripting, node graphs, or inspector-assembled behaviour, in any form.
• A generalised frame graph before the fixed schedule is genuinely limiting.
• Runtime texture compression, or any decode-to-uncompressed path.
• A centralised template or asset marketplace.
• Rebuilding around ECS for trend alignment. If bulk entity updates prove to be the bottleneck, the answer is a targeted data-oriented path for bulk entities, not a paradigm change across the engine.
• Fallback rendering paths. Capability reporting instead.
• Any XR runtime besides OpenXR — the same rule that killed OpenGL fallbacks.
• Console certification or store policy as engine work. Porting the engine is the vendor's side of the line; certifying a shipped game is the developer's.

How to tell whether this is working

• The renderer claim is provable: benchmark numbers and reference images are published, not described.
• The GC objection is answerable in one number.
• Someone can evaluate the engine in ten minutes without reading engine source.
• Generated assets end up in scenes, not in a folder.
• Adding a world type does not require writing editor code.
• Season/ stays smaller and clearer than the feature list would suggest.
• One implementation per domain still holds — no OpenGL fallback appears, no second animation format, no second text renderer.

Disagreements about ordering are welcome and useful. Open an issue — the reasoning in Roadmap.md is written down so it can be argued with.