Parity

Last comprehensive audit against main: 2026-09-27. Targeted status and queue reconciliation: 2026-10-27. Verify individual rows when changing them.

What a game engine is expected to do, what Sindri actually does, and the distance between them. This file replaces function-matrix.md and feature-integration-matrix.md, which are deleted: both graded Sindri against Sindri, so a feature nobody had thought of had no row and could not show as missing.

That failure was not hypothetical. The integration matrix recorded 2D physics as Ready — masked runtime, body kinds, sensors, validation, velocity, impulse, all true — while a character could not be given a capsule with a circle at each side, because a collider was singular from the scene file down to BodyRecord2d. "Ready" meant complete against what we built, not sufficient for a game. A table with an outside edge would have carried a Compound colliders row reading ❌ from the first day it existed.

So this table is written from the outside in. The baseline column is what a person arriving from Unity or Godot expects to find. Rows exist for things we have never built and have no plan to build, because a gap with no row is a gap nobody schedules.

How to read it

Four surface columns, then the outward judgement:

Surface legend: ✅ works and is exercised · 🟡 a useful slice, with the gap named · ❌ absent · — genuinely not applicable to that surface.

Parity legend:

• Ahead — we do this better than the baseline, on purpose. Protect it.
• Par — a competent equivalent exists.
• Behind — the same idea, less of it.
• Absent — the baseline has it and we have nothing.
• Won't — a deliberate decision not to have it. See the anti-goals.

A ✅ still means what it always meant: implemented and exercised, not represented by a type, a schema, or an editor control.

What counts as proof follows the three kinds of project in AGENTS.md. For a gameplay capability, exercised means a game uses it: Causeway, Orbital Last Stand, or a genre showcase (games/<genre> — the platformer and Scorchball today). A feature example (examples/<feature>) or a lab such as Voxel Lab shows a capability on its own; that is a partial proof (🟡) for a rendering or tooling row, where isolation is the honest test, and not a proof for a gameplay one. Either way the gap cell names the project, so removing a project shows which rows it was holding up. Gather's removal is why this rule exists: it left eight rows citing a game that no longer existed.

The layout still lags the three kinds. examples/ holds camera, cube and triangle, three feature demos — voxel-lab, weave-poc and shapes-lab — live under games/, and most of the feature examples AGENTS.md names (audio, Weave, Decay, tilemaps, isometric, voxels) do not exist as examples yet. Moving and filling them is follow-up work, not a change to any cell here.

Ranking is by "does this stop somebody shipping a game", not by feature count. Unity has thousands of features and most of them do not matter. The ranked queue at the end of this file is the actionable output; the tables are the evidence behind it.

Where Sindri is already ahead

Written down first, and deliberately, because parity work is the most likely way to lose these. Every row below is somewhere copying the baseline would be a regression.

What we will not copy

The advantage of a foundation this new is that its mistakes are still avoidable. These are anti-goals; a PR that drifts toward one should be stopped by this list rather than discovered a year later.

• No sidecar metadata files or asset GUIDs. Identity comes from the path inside the project. Renames are the price; unmergeable scenes are not.
• No serialization by field-name reflection. Renaming a Rust field must not silently drop authored data. Schema versions and explicit decoding instead.
• No second render pipeline. Unity has three that split the ecosystem in half. One path, extended.
• No second input system. The action layer already in sindri-platform becomes the input system; it does not grow up beside the old one.
• No prefab variant hierarchy. Prefabs plus overrides through the reference. Nesting a prefab inside another is not a variant and is supported; a prefab that is "another prefab, but different" is not. If variants ever seem necessary, prove it with a game first.
• No assembly-definition graph. Crate boundaries in dependency-policy.md already do this job.
• No inspector that needs a plugin to be usable. Odin exists because Unity's is not sufficient. Ours has to be sufficient — see the ranked queue.
• No editor-only code path. What the editor plays is what the build runs.
• No silent defaults for things the engine cannot invent. A component that names a font, a sheet, or a clip has no blank; the registry already distinguishes a field template from a fresh default, and that distinction stays.

Stranded capability

A class the old matrices could not express: built, working, and unreachable. Neither of these appeared in either matrix, in any column, because nobody had written the row.

Stranded capability is the cheapest work in this file: the engine cost is already paid and only the reach is missing. It is also the most invisible, which is why it earns a section rather than a footnote.

Scenes, entities, and prefabs

Assets and the import pipeline

Voxel worlds and terrain

The ordered work required to close these gaps is tracked in voxel-system-completion-checklist.md.

2D rendering

3D rendering

3D has a shared foundation and is used by Causeway, but broader authoring, rendering, animation, performance and game proof remain incomplete. Follow-ups are ordered in 3d-update.md.

Animation

Still the weakest major system relative to the baseline, but no longer the one where nothing connects. Sprite clips exist, play, and are now chosen by gameplay: a script plays, stops, restarts and times a clip, and is told when a one-shot has ended. Sequences now animate any numeric field and tweens move values from scripts; what remains absent is frame events, blending and skeletal animation.

Physics and collision

Navigation and grids

Sindri's strongest domain relative to the baseline.

Audio

Input

UI and presentation

Effects

Scripting (Decay)

Editor experience

Where the most day-to-day friction is, and where one architectural change removes most of it.

The root cause of hand-typed fields (fixed)

This records the defect ranked queue item 1 removed; the tables it describes are gone. It stays because its conclusion — a component declares what its fields mean, and no consumer guesses it from a name — is the rule every new component follows.

The editor used to infer meaning for some fields, and it is worth being precise about how, because the mechanism was the defect rather than its absence.

Three lookup tables in the editor guessed a field's meaning from its name:

// editor/src/native/inspector_panel/field.rs
match (type_name, key) {
    (_, "texture") => Some(assets.textures),
    (_, "font")    => Some(assets.fonts),
    (_, "clip")    => Some(assets.audio),
    ("sindri.script", "source") => Some(assets.scripts),
    _ => None,
}

plus is_colour, which requires the key to be literally tint, color or colour, and editor/src/inspector/choices.rs, which maps (type_name, key) to an enum's spellings. The choices module is careful — it takes each list from the engine's own constants rather than repeating them — but it is still a table in the editor keyed by field name.

Four consequences followed, and they were why more table entries was not the fix:

1. The bare-key rules are global. (_, "texture"), (_, "font") and (_, "clip") match any component, including one a game brings of its own. A game component with a clip field is offered the audio list whether or not it holds audio.
2. Anything absent from the table is a free-text box, silently. A field named sheet, icon or portrait gets nothing. This is what happens to every component added since the table was written, which is why new work keeps landing as raw fields.
3. A colour must be spelled tint. Named anything else it is four number boxes; and the check is Numbers(4), which a UV rect and a quaternion also satisfy.
4. It lives in the editor. sindri-capabilities cannot document it, and no other tool can use it.

Underneath all four: meaning is guessed by the consumer rather than declared by the component. That is a second copy of knowledge about a component living away from the component — exactly the drift check_template was written to stop for field lists. ComponentSchemaRegistry stores a field template, a serde_json::Value exemplar checked against what serde asks the type for, so it captures each field's shape and nothing about its meaning. A texture id and a display label are both String to the registry.

A second consequence used to follow, and is now fixed. A value that is an array of objects fell to ValueKind::Opaque and was displayed as stored — the pieces array of a compound collider is exactly that shape, so compounds were authorable in a scene file and not in the inspector. The template's exemplar item is what closed it: it says what a piece consists of, what each field means, and what a fresh one is, so the panel can draw a list and add to it without inventing anything.

The fix was to move meaning to the registration — asset(texture), asset(script), asset(clip), entity reference, choice, colour, angle, bounded range, list-of — and have the editor read it instead of guessing. It extended the registry that already existed, made the knowledge checkable against the template the way field lists already were, travels to every tool rather than only the editor, and covers components not yet written. It was the highest-leverage item in this file.

Build, export, and platform

Diagnostics

Absent whole systems

Named so they are decisions rather than oversights.

What the Unity Asset Store proves

A plugin that sells for a decade is a feature the engine should have had. This is a market-validated gap list, and it is more honest than our own judgement because somebody paid for every row.

Tier 1 — Unity had to absorb it

The strongest possible evidence: Unity bought or cloned these, conceding they were native gaps. Treat these rows as close to automatic.

Tier 2 — still not native, still selling

Read together, the two tiers say the same thing three times: camera, tweening, and input mapping are the features people reliably pay to add. Camera is now built and used; input mapping is built and used, including Orbital’s saved burst binding; managed tweening is now used in Orbital, with composition built and property binding still absent.

The ranked queue

This is a current proposal, ordered by impact on games and shipping. Each item needs a scoped design and proof in the named project before it is marked done; the order does not imply that every gap has been independently retested.

1. Integer-scale pixel camera. Lamplighter's 320 by 180 art grid needs a whole-number scale and letterboxing at arbitrary window sizes. Prove it on different desktop and phone viewports in the game.
2. Decay language tooling correctness. Follow the P0 items in decay-lsp-modernization.md: synchronization, workspace refresh, positions and protocol coverage. Incorrect diagnostics and completion undermine every game using Decay.
3. 3D character animation. Follow the skinning slice in 3d-update.md: import a rigged GLB, sample and render a clip, expose playback and authoring, and prove it in a real game. Establish a small end-to-end slice before claiming general animation support.
4. Complete the shared 3D path where a game needs it. Material texture bindings and alpha, model authoring and performance remain; choose a concrete Causeway or 3D game need and follow the dependencies in the 3D plan.
5. Ship a complete game. Use a real game's release to expose the remaining asset import settings, compression, native packaging and shipped-build error reporting needs. Browser export already uses the shared project host.
6. Shorten the editor feedback loop. Prioritize multi-select/bulk editing, live edits during Play, and export and project settings workflows against work in Lamplighter and Causeway.
7. World persistence and navigation as games demand them. Voxel edits need a durable save path for a game that depends on digging; off-grid navigation and avoidance need a game that exercises them.
8. Finish scoped profiling. Native benchmark GPU intervals exist; the interactive profiler, browser GPU timing and full-frame accounting remain incomplete. Measure actual game bottlenecks before setting new targets.
9. Scene serialization and input follow-ups. A world containing multiple scenes does not round-trip through to_scene; project-level/per-player input and binding persistence also remain. Prioritize the specific game failure each would resolve.

The original queue's basic autotiling, camera behavior, audio buses, tween composition, 2D query and inspector slices have shipped. Their remaining limitations are recorded in their feature rows rather than described as absent. The 3D query, editor and game-proof gaps are not closed by the 2D query slice.

Proof that lived outside this repository

The advanced sprite colour transform and the UI slider were both found by Mujaffa Remaster, an external project, and for a while neither had a user here. Both now do: the slider in Orbital's pause mixer and Sound Mixer, and the colour transform in Orbital's mine blast, which flashes white-hot through the colour offset because a tint, being a multiply, can only darken.

Beyond parity — where Sindri could lead

Everything above answers "what is an engine expected to do", and every row can be checked against Unity or Godot. This section answers a different question: what could an engine provide that none of them do? It is kept separate deliberately. Mixed into the tables above, a reader could no longer tell "the baseline has this and we do not" from "nobody has this and we might", and that distinction is what makes the rest of this file worth reading.

Nothing here is scheduled. These are candidates, and they compete with each other rather than with the ranked queue.

The thesis

Sindri already refuses to hand a game raw dt and raw key states and wish it luck. It has a fixed step, input edges consumed exactly once, and a seeded stream that replays a run on every host. Read together those are one idea:

The engine gives you primitives for translating imperfect human input and time into deterministic gameplay.

That is a stronger position than any single feature below, and it is a description of what Sindri is rather than a direction bolted on. The candidates worth taking are the ones that follow from it.

Judged against the games, not against plausibility

A candidate earns a row by replacing something a game in this repository is doing by hand today. Where a game is not asking for it, that is recorded too — an idea that sounds good and nothing needs is the most expensive kind.

The one that changes something above

Spatial queries expose a framing error in this file's own physics section, which lists raycast and overlap as physics queries. Target selection in player.decay is not a physics problem — it is a gameplay query over tagged entities. The first slice now lives in World.nearest and World.within_radius, with Orbital proving the filtered targeting path. Physics overlap/shape casts, cone/box queries and spatial indexing remain separate follow-up work.

Determinism also matters here in a way it does not for the baseline: a query that answers in world order answers the same on every host, and a game built on "the nearest enemy" then replays from a seed. Neither Unity nor Godot promises that.

Buffering, narrowed

The tempting version of this is a general forgiveness system — jump buffering, coyote time, grace periods — authored in one block. Half of it does not belong in an engine.

"Remember a press for 120ms and let gameplay consume it exactly once" knows nothing about a game and is genuinely engine-level. "A grace period after being grounded" requires the engine to know what grounded means, which is game-specific: a top-down shooter has no such state, and an engine that assumed one would be a system games fight rather than use.

So the half worth taking is the input half, and it already has a home: the input action layer in sindri-platform, which now reaches scripts. Buffered press and consume-once are features of a named action, not a new subsystem — which folds this candidate into an existing queue item instead of adding an eleventh.

Decay tooling modernization

Decay is the primary gameplay language, so language tooling is part of the authoring surface rather than optional editor polish. The September 2026 deep audit found concrete drift and protocol/test gaps in decay-lsp and the VS Code integration. The complete prioritized checklist and definition of done live in docs/decay-lsp-modernization.md. Update that checklist in the same change that closes or discovers a Decay tooling gap.

Maintenance rule

Update this file in the same change that moves any cell, as AGENTS.md requires. Four specific rules keep it from rotting into a checklist nobody reads:

1. A surface cell claims only what is implemented and exercised. For a gameplay capability, exercised means a game uses it, and the gap cell names which — see "What counts as proof". capabilities.md remains the detailed evidence.
2. A parity cell is a judgement and must survive an argument. "Ahead" is a claim about the baseline, not enthusiasm.
3. Add the row before the feature. The value of this file is that absent things have rows. A gap discovered during work belongs here in the same change, marked ❌, even when nothing is planned.
4. Keep the two questions apart. Everything above "Beyond parity" is answerable against Unity or Godot. Everything below it is not, and moving a candidate up requires the baseline to have grown it, not for us to have liked the idea. A candidate earns its place by naming what a game in this repository does by hand — and when no game wants it, the row says so.