The Ten, Audited: Turian in October 2026

In 10 Personas: Who Turian Is Built For I introduced the ten people Turian is built for, and the one thing each of them loves and hates. This is the companion piece: the honest audit.

For every persona below you will find what Turian gives them today, what is still owed, and the one success signal that would tell me the persona is actually being won, between the same loves and hates as in the first article. What exists and what is planned are kept separate, and where a loved thing is only half answered, the text says so. A feature list that pretends everything is done helps nobody.

This is the October 2026 analysis. When reality disagrees with this page, reality wins, and the next analysis replaces this one.

Ana

The teenage hobbyist

P·S·I·J: Prototyper, Shopper, Integrator, Journeyman.

In Turian today

Turian Studio can create a project with a starter scene, and Play (F5) runs it inside Studio. Stopping throws the running copy away, so a mistake cannot break the scene being edited.
A manual written for beginners on the site, in four languages, and Studio itself is localized with the same system.
The asset store, with some bricks on the shelves: the camera controllers (Free Fly, FPS, Orbit, Follow) and the in-game UI are installed, not rebuilt.
Input actions: a control is a named action rather than a raw key.
Modding by variation. A prefab variant or a data asset variant is the original plus the values overridden, and it keeps following the original when that changes.

Still owed

Step-by-step tutorials. They do not exist. The manual is a reference, and a beginner needs a path from zero to a first game.
Third-party assets in the asset store, ready to shop and download.
2D authoring. Beginners reach for 2D first, and Turian is a 3D editor today.
Polished showcase projects, each focused on one area and ready to open, edit and run, with a README and the engine version they need.
Project templates and complete kits through the asset store.

Success Signal: Share of first sessions that end with a running, exportable thing.

Benjamin

The solo code-first indie

C·P·A·J: Closer, Purist, Architect, Journeyman.

In Turian today

turian-cli runs the same compiler, importer, exporter and renderer as Studio: new, compile, export, play, scene, screenshot, playmode, pick. Exit codes are non-zero on failure, so scripts can trust them.
A project is a folder of plain files. Scripts are ordinary C# under assembly definitions stored as data, and packages are declared in Bricks/manifest.json, so nothing requires the editor to be open.
Headless rendering to avif, even on a machine without a GPU, and turian-cli ui renders a UI document without a scene at all.
The engine is under the MPL 2.0, and the source can be read, so any implementation can be investigated instead of trusted.
Reusable libraries that live outside the engine and can be used without it, such as Graph and Guinevere, with names and releases of their own.
A configurable fixed-tick simulation with pause and single-step, plus command replay, so a headless test can drive a game tick by tick.

Still owed

The engine and its attributes as NuGet packages, so a plain C# project can reference Turian without a Studio install.
A code-only showcase project that builds and runs without ever opening the editor.
Code-only data assets: creating, reading and using a data asset from plain C#, with no editor involved.
A profiler. There is none yet.

Success Signal: Share of projects where the editor is never opened.

Carlos

The mini jam-born studio member

I·W·I·C: Iterator, Worldbuilder, Integrator, Conductor.

In Turian today

Play, Pause and Step Frame (F5, F6, F10) inside Studio, running a copy of the open scene. When a script fails to compile, the last working build stays loaded, so a typo does not end the session.
Bricks double as the plugin system, and the asset store carries them: what a jam needs is installed, not written.
Multi-object editing in Studio: select several objects, edit a shared field once, and undo the whole batch in one step.
Caching that pays off mid-jam: reopening a project reuses imported files and compiled code when nothing changed, and File → New Scene opens a throwaway scene for experiments.

Still owed

Designers changing values and listeners while the game plays, on top of the data assets Fernando uses. The pieces exist (see Fernando); the live-editing loop does not yet.
Keeping the values changed during Play Mode. Today stopping discards the running copy and everything tuned in it, always.

Success Signal: Median edit-to-play loop time across active projects.

Daniela

The game artist

A·P·I·J: Alchemist, Purist, Integrator, Journeyman.

In Turian today

FBX and OBJ import plugins for her models.
Dockable layouts in Studio: the workspace she arranges is the workspace she keeps.
One renderer draws Studio's Scene and Game views, the headless screenshots and the exported game, with PBR metallic-roughness materials. What Daniela sees is what ships.
Instanced models carry a color tint and four custom values each without breaking the batch.
Prefabs and prefab variants keep kits consistent, with an asset browser, undo and redo.

Still owed

An animation system with curve editing and a timeline.
2D sprites. Turian renders 3D, and a 2D workflow does not exist yet.
Particles.
There is no audio system yet.
Shadows, image-based lighting, a skybox, post-processing and custom render passes from project code, then a node-based shader editor.

Success Signal: Share of asset imports that need no rework after the round trip.

Eduardo

The level designer

I·W·C·J: Iterator, Worldbuilder, Curator, Journeyman.

In Turian today

Physics through Bepu, out of the box.
Failures never touch the scene being edited: Play Mode runs a copy, and stopping discards it. Prefabs, variants, an asset browser, undo and redo keep a crowded scene consistent.
GPU instancing merges every run of identical mesh and material into one draw. In a test scene, 10,000 identical props went from 8,791 draw calls to one, with identical pixels. Frustum culling skips what the camera cannot see.
Tags and independent layer spaces, visibility and selection locks, rectangle selection, rotation gizmos and an orientation control: the small tools that make a crowded scene workable.

Still owed

Particles. There is no particle system yet.
Tweens and an animation timeline. There is no animation system in Turian yet.
Post-processing.
Drag-and-drop: a model file dropped into the scene straight from the file manager.
Snapping, including to other models and not just the world grid.
World-building tools such as scattering and terrain, after animation and the rendering gaps.

Success Signal: Crash-free session rate among users who never open a code file.

Fernando

The economy designer

I·H·I·J: Iterator, Hermit, Integrator, Journeyman.

In Turian today

Game data lives in data assets, plain JSON files edited with forms in the Inspector. A programmer exposes a new type once with [CreateAssetMenu], and after that designers create and edit it themselves. Data asset variants override only what changed.
A file watcher in Studio that reimports external changes: edit a data file outside the editor and it is picked up without being told.
Tags and layers are assets too, so renaming or reordering them breaks no scene or prefab reference.
The first cut of data-asset-driven design: events, variables, runtime sets and state machines are assets designers wire together, shipped as bricks alongside the engine.
The data-exchange pipe: one .strings table per locale with a stable key, source, translation, note and state, fallbacks that never throw, substitution, plural and select blocks, --locale to force a language for a session or a screenshot, and an editor library that reads and writes XLIFF 1.2 and CSV while keeping key, source, target, note and state.

Still owed

The Studio overview showing what listens to what, plus live values and a manual raise button while the game plays.
Table import and export for data assets, with validation and undo. The string tables already round-trip through CSV; game-balance tables do not.
The XLIFF workflow around the library: export and import from Studio and the command line, a tested round trip, a report of what changed between exports, XLIFF 2.x, validation of keys and placeholders, and right-to-left scripts.
Analytics, so balance changes can be judged against what players actually did.
Cloud services. Nothing in Turian assumes a backend today, and nothing helps run one.

Success Signal: Share of content changes entering the game without a programmer.

Gabriel

The DevOps

C·P·A·C: Closer, Purist, Architect, Conductor.

In Turian today

An official container image with the SDK and a software Vulkan driver. turian-cli export runs on any CI service, and the manual includes ready workflows for two of them.
Pinned inputs. Brick restore is automatically --locked whenever CI=true, the lock records version, hash, registry and signing key, and signatures are ordinary OpenSSH ed25519 keys. A brick cache folder can be shared between runs.
turian-cli oap validate checks a package's header and the CRC-32 of every asset, and exits non-zero on failure.
Simulation checkpoints with a state hash at every tick, compared across 30, 60 and 144 Hz rendering and across save-and-resume. Reproducible gameplay is proven for the headless fixture, not promised.

Still owed

Size and build-time reports per brick and per package, so a patch's weight is known before it ships.
A CI check that builds twice and compares the bytes. Today Turian can promise identical inputs; it cannot yet promise identical outputs.
Graph asset analysis on build.
Asset packing for shipping; today an export ships the imported tree as it stands.
A profiler.
iOS, Android and console targets; today export is desktop (Windows/Linux).
Headless NativeAOT servers; early samples already export without trim warnings. Cross-platform physics determinism remains future work.

Success Signal: Distinct organizations running the CLI in CI.

Isabela

The AA studio president

C·H·A·D: Closer, Hermit, Architect, Director.

In Turian today

The terms in plain language: MPL 2.0, no royalty, the game's license is the studio's choice. Releases are small and frequent, a major version means a change can break a project, and each major ships a migration guide in the manual.
Release notes that quote measured numbers and say what they do not prove, such as 10,000 instanced props in one draw call and about 0.6 ms of CPU time for 10,000 colored cubes, or "cross-platform physics determinism remains future work".
A statistics display in Studio and in the runtime reporting draw calls, instances and culled counts. Headless screenshots report the same counters, so anyone can reproduce a number.

Still owed

A released game. Any, made by anyone, on any store. The count today is zero, and I will not pretend otherwise.
Strong demos: the kind a studio can hand to a new hire on day one, not release notes with numbers.
Official support, free or paid. Today support is me.
A public, reproducible benchmark suite: fixed scenes, assets, camera and quality settings, published with hardware, driver, exact versions and date, reporting average and worst-case frame time, peak memory, first-frame latency and export size.
Showcase projects built on released versions, and mobile export with a published acceptance checklist.

Success Signal: Commercial games credited to the tool.

Julio

The AAA producer

C·H·A·C: Closer, Hermit, Architect, Conductor.

In Turian today

Every team's content is a brick with an id, a version, declared dependencies and an engine compatibility range. Releases outside a store's auto-approved names wait for approval, versions are never deleted or replaced, and yanking or deprecating a release is explicit and carries a reason.
Assembly definitions: a team's scripts compile as units with explicit references, so work can be split without everyone compiling everything.
Pre-baked bricks: brick pack --precast ships compiled assemblies, so restoring a brick is not recompiling it.
Asset packages (OAP) can require a base package and override assets by id without rewriting references, the foundation for shipping only what changed.
Reopening a project and running Build & Run reuse imported files and compiled code, copying only what changed, which makes build time something that can be tracked from week to week.

Still owed

Size and build-time reports per brick and per package, so a patch's weight is known before it ships.
A systematic pass on warnings and error messages that pinpoint the problem, per build, per import, per script. Some already do; it is not a promise yet.
Support with an answer time he can put in a schedule.
An optional multiplayer brick with dedicated server builds.

Success Signal: Inbound inquiries that cite packaging and patching.

Mariana

The toolmaker

C·S·T·I: Closer, Shopper, Toolsmith, Influencer.

In Turian today

Studio is itself a plugin of a plugin platform. Panels, commands, menus, shortcuts, settings pages and themes all go through the same registries a third-party plugin uses.
Extensions come from project C# code using attributes, with no reference to any editor assembly: [MenuItem], [Panel], [CreateAssetMenu], [ComponentContextMenu], etc, plus inspector attributes such as [Button], [Range] and [ReadOnly].
The brick manifest carries id, version, compatible engine range, dependencies, NuGet needs and an SPDX license. Every script and asset ships a .meta file whose id other projects refer to, so renaming and moving files breaks nobody.
Guinevere.Autoformer, a library for creating GUI forms and tools automatically.
brick verify --against checks that a stub still matches the real brick, and brick stub lets others build on unfinished work. Installed bricks are read-only; customers change them through variants and import overrides.
Every breaking change goes in a migration note.
Versions are never deleted or replaced. A yanked version stays available to projects whose lock pins it and is never chosen again. brick diff and brick rebase handle the forks, and publishing is a scoped token to a signed registry: releases, yank, deprecate.

Still owed

The extension surface documented as a versioned API with a stated compatibility promise for each engine version, and the engine, attributes and SDK as packages a plugin can reference.
An API reference site, generated and versioned, so a plugin author does not grep the source for a signature.
The public storefront on top of the registry: publisher scopes, an approval flow, release advisories and provenance, and per-target variants of the same package.

Success Signal: Extensions and plugins published by people outside the core team.

Behind the audit: eight aspects and the board

Every engine decision I make ends up in one of eight aspects:

Aspect	What counts inside it
Art	Rendering, shaders, 2D, 3D, audio, authoring tools
Automation	CI/CD, testing, packaging, headless and reproducible builds
Business	Price, tiers, terms, rights, services, support
Code	Code-first workflows, APIs, hardcore control, packages, performance
Ecosystem	Extensions, helper tools, asset store, integrations, data import/export
Editor	Ease of use, drag-and-drop, visual "programming" tools, scene composition
Learning	Tutorials, docs, community, videos, chat rooms, translations
Platforms	Mobile, VR, consoles, server, multiplayer

The board below is my reading of what each of the ten personas needs from each aspect. Each persona is four styles, and the strongest of the four gives the cell's default. It is a living opinion and it might move.

Aspect/Persona	A	B	C	D	E	F	G	I	J	M
Art	◐	○	◐	●	●	○	○	◐	○	○
Automation	○	●	◐	○	○	○	●	◐	●	◐
Business	◐	●	◐	○	○	○	◐	●	●	●
Code	○	●	●	○	○	○	●	○	○	●
Ecosystem	●	○	●	◐	●	◐	◐	◐	◐	●
Editor	●	○	●	●	●	◐	○	○	○	●
Learning	●	◐	◐	◐	◐	◐	◐	◐	◐	●
Platforms	◐	●	●	○	○	○	●	●	●	◐

A filled dot is a gate: if the aspect is missing or broken, that persona walks away whatever else is good. A half dot matters but does not gate. An empty dot gets done when it falls out of other work.

What the board says

The Editor is the gate for the people who live inside the tool: Ana, Carlos, Daniela, Eduardo and Mariana. Everyone else puts their gates elsewhere.
Art is a gate for exactly two people. They make the game's look; the rest consume it or never touch it.
Ecosystem is a gate for the makers who shop. Benjamin's cell is empty on purpose, because a code-first user gets his libraries as code, not from a store. For the four it does gate, the store is not a feature. It is half the product.
The pipeline people cluster. Benjamin, Gabriel and Julio all carry gates in Automation, Code or Platforms, and Isabela joins them on Platforms. They will never agree on an editor, but they agree on a pipeline.
Learning is a gate for the beginner and the toolmaker. Everyone else can read a manual, or the source.
Business is a gate for the people who pay, sign, sell or supply. The rest simply work.

How MASS4 uses these personas

The board is the bridge between the people and the work:

Labeling issues. Some issues carry a persona:* label. When a label appears, it signals that that persona cares about the subject.
Housekeeping says its name. A feature that serves no audience is either housekeeping or a mistake. Both are fine, but both must say so.
Claims must move a signal. Every persona above ends with one signal, the observable that says whether Turian is actually winning them. If an item says it serves a persona, it can name the signal it moves. If it cannot, it is decoration.
The veto rule travels. Shipping something that breaks a served persona's gate fails that persona entirely, and the board says exactly who.

The ecosystem, not just the engine, is what serves all ten.

The asset store is the clearest seat: Ana shops there for templates and kits, Carlos for bricks that save a jam, Eduardo for props, and Mariana publishes there, so the store's customer and its supplier both have a chair.
The libraries are another: Graph, Guinevere, OAP, KTX2 and others live outside the engine, serve Benjamin and Mariana first, and would keep their names and releases if the engine changed under them.
Services and community places are the third: Isabela's hiring market, Julio's support line, and Ana's first question answered in her own language.
The Business and Ecosystem columns of the board are not filled by the engine at all; they are filled by everything around it, and that everything is the point of MASS4.

One last thing. These ten people do not exist. They are my reading of what a tool like Turian must answer, and every dot on the board is an opinion, which means it can be wrong. You do exist. If you make games, or build tools for people who make games, you are the client this whole text is about, and your loves, your hates and your disagreements count more than mine. The personas are the map; you are the territory. Where the map is wrong, say so, in a comment, an issue or a post wherever you found this. The next audit will be better for it.