Coming from Unity

A translation table, and then the four places where translating stops working because the two models disagree about something rather than spelling it differently.

It assumes Unity and explains Vixen. Everything here is also in the guide on its own terms; this page exists because a reader who knows one engine reads a reference for a second one through the first, and the words that look the same are exactly where that goes wrong.

The first hour, for the reader this engine is most likely to get — and for the specific failure of that hour, which is not confusion. It is writing something that compiles, runs, and is quietly the wrong shape: a component that is really a script, an ordering attribute that does nothing, a frame edited at a call site.

This is the difference every other ECS page is downstream of, and the one that makes a MonoBehaviour untranslatable as a unit.

A component is a plain struct marked [Component]. The ECS stores every component of one type in a column, so a hundred thousand positions are one contiguous array — which is what makes iterating them fast and is the entire reason for the arrangement. There is nowhere in that picture for a method that belongs to one object.

So a MonoBehaviour becomes two things: the fields become a component, and Update becomes a system that runs a query.

⚠ Do not translate a singleton into a component. A camera setting, the frame's clock, "the player" — a column of length one costs an archetype for nothing. That is a service or a singleton, and Unity's habit of putting one on an empty GameObject has no counterpart here.

⚠ Ordering is per phase, and an attribute that names a system the graph does not have is dropped without a word. [UpdateBefore] pointing at a renamed system, or one nobody registered, reads as though it works and does nothing — which is a different failure from Unity's script execution order list, where the entry at least stays visible. SystemPlan.Unsatisfied is what reports both, and vixen doctor systems prints it.

There is no render pipeline to subclass and no OnRenderImage. A StandardFrame asset expands into a compositor document, which builds a render graph of passes; quality tiers (.vxpreset) and look profiles (.vxlook) layer over it. Changing what draws is usually an edit to a document, not to a call site.

The vixen-game template ships one, and its OnConfigure names it:

⚠ Extraction is the half a frame cannot decide, and it is the commonest way a migrated project gets a picture that is subtly wrong rather than obviously broken: turning shadows on in the document also needs every mesh drawn into the Shadow stage, and temporal antialiasing needs the velocity pass fed through Motion. Both are config.Graphics.CasterStages lines, and a frame configured for something nothing is extracted into simply renders without it.

The flow is importer → asset database (with .meta sidecars) → content build → catalog and bundles. A file dropped into Assets/ is imported by whichever importer claims it, and the settings that governed the import live in the .meta beside it — which is the one part of this a Unity reader already knows by heart.

What is different is the far end. A shipping game reads built content, not source assets: the content build produces a catalog and bundles, and what a running game asks for is an entry in that catalog. So "it works in the editor and not in the build" has a first question here — is it in the content build — with a place to look up the answer.

Vixen.Ui is not a game overlay with a scene-graph canvas. It is the framework the editor is written in: a document, a cascade, a reactive graph, .vxml for the tree and .vcss for the style. There is no Canvas, no RectTransform and no EventSystem, and the layout vocabulary is flexbox and grid rather than anchors.

The nearest Unity thing is UI Toolkit — UXML/USS is the same idea — and the differences worth knowing on day one are that the reactive model is signals rather than data binding by path, that a .vxml compiles to a C# partial class rather than being loaded at runtime, and that the utility class vocabulary is Tailwind's.

⚠ Vixen.Ui never references Vixen.Engine, and that is enforced by the build. An interface does not get to reach into the world; a game hands it what it needs. That constraint is the whole application-framework claim, so it is the one rule on this page that is not a preference.

A spinning object, both ways. In Unity it is a behaviour with a field and an Update. Here it is the struct above plus a system that runs over every entity that has one — one query, one pass, no per-object dispatch:

Where the per-object habit is still right. An interface. A panel is a tree of objects with behaviour attached, and Vixen.Ui is that model deliberately — so the instinct a Unity reader brings, which is wrong for the world, is right the moment they open a .vxml. See the UI tutorial.

What has no counterpart. Coroutines. There is no StartCoroutine: per-frame work is a system, and waiting on I/O is async/await on the thread pool — importers block on I/O for exactly this reason and deliberately do not use the job scheduler, which cannot replace a blocked worker.

• Getting started — the SDK, the feed, the six templates and the first run.
• Components — what [Component] and [DataContract] each mean, and why the pair is the authored/internal distinction.
• Reading a frame's order without running it — phases, the ordering attributes, and the two ways they silently do nothing.
• The standard frame — the document a .vxcompositor expands into.
• Content in a game — the catalog and bundles a built game reads.
• Building an interface, end to end — the fourth difference, as a panel.