逐一审视这十个人：2026 年 10 月的 Turian

在 10 个用户画像：Turian 为谁而造中，我介绍了 Turian 面向的十个人，以及他们各自最喜欢和最讨厌的事。本文是配套篇：坦诚审视现状。

下文会逐个说明，今天的 Turian 能为每个人提供什么、还欠缺什么，以及哪一项成功指标能让我判断，我们确实正在赢得这个人的认可。评判依据仍是上一篇中的那些喜恶。已有功能与计划明确分开；某项喜好如果只满足了一半，文章也会直说。假装一切都已完成的功能列表，对谁都没有帮助。

这是 2026 年 10 月的分析。当现实与本页不符时，以现实为准，再由下一次分析取代这一篇。

Ana

把游戏制作当作爱好的高中生

P·S·I·J：原型型（Prototyper）、选购型（Shopper）、集成型（Integrator）、实干型（Journeyman）。

今天的 Turian

Turian Studio 可以创建带有初始场景的项目，Play（F5）能在 Studio 内运行它。停止后会丢弃运行副本，因此出错也不会破坏正在编辑的场景。
网站上有面向初学者编写、提供四种语言的手册，Studio 本身也使用同一套系统进行本地化。
资产商店已经上架一些 brick：摄像机控制器（Free Fly、FPS、Orbit、Follow）和游戏内 UI 可以直接安装，不必重做。
输入 actions：控制操作是一个具名动作，而不是原始按键。
通过变体制作 Mod。预制体变体或数据资产变体由原件和覆盖的值组成，原件变化后仍会继续跟随。

还欠缺什么

循序渐进的教程。目前没有。手册是参考资料，而初学者需要一条从零走到第一个游戏的路。
资产商店里可供选购、下载的第三方资产。
2D 制作功能。初学者往往先选 2D，而今天的 Turian 是 3D 编辑器。
打磨完善的展示项目，每个聚焦一个领域，打开就能编辑、运行，附带 README 和所需的引擎版本。
通过资产商店提供的项目模板和完整套件。

**成功指标：**首次使用结束时，做出了可运行、可导出作品的会话占比。

Benjamin

代码优先、单人制作的独立开发者

C·P·A·J：交付型（Closer）、纯粹型（Purist）、架构型（Architect）、实干型（Journeyman）。

今天的 Turian

turian-cli 使用与 Studio 相同的编译器、导入器、导出器和渲染器，提供 new、compile、export、play、scene、screenshot、playmode、pick。失败时退出码非零，脚本可以据此可靠地判断结果。
项目就是一个普通文件目录。脚本是常规 C#，由以数据形式保存的程序集定义组织；包在 Bricks/manifest.json 中声明，因此没有什么必须打开编辑器才能做。
即使机器没有 GPU，也能无头渲染为 avif；turian-cli ui 甚至不需要场景就能渲染 UI 文档。
引擎采用 MPL 2.0，源码可读，因此任何实现都可以自己检查，而不必只凭信任。
Graph 和 Guinevere 等可复用库独立于引擎，也能脱离引擎使用，拥有自己的名称和版本发布。
可配置的固定 tick 模拟，支持暂停、单步和命令回放，使无头测试能逐 tick 驱动游戏。

还欠缺什么

将引擎及其特性作为 NuGet 包提供，让普通 C# 项目无需安装 Studio 就能引用 Turian。
一个完全用代码制作、从不打开编辑器也能构建运行的展示项目。
纯代码数据资产：不经过编辑器，直接用常规 C# 创建、读取和使用数据资产。
性能分析器。目前还没有。

**成功指标：**从未打开过编辑器的项目占比。

Carlos

诞生于 Game Jam 的小工作室成员

I·W·I·C：迭代型（Iterator）、世界构建型（Worldbuilder）、集成型（Integrator）、统筹型（Conductor）。

今天的 Turian

Studio 中的 Play、Pause 和 Step Frame（F5、F6、F10）运行当前场景的副本。脚本编译失败时，最后一个可用构建会保持加载，因此一个拼写错误不会结束会话。
brick 同时也是插件系统，资产商店负责提供它们：Game Jam 需要的功能可以安装，不必自己写。
Studio 支持多对象编辑：选中多个对象，一次修改共享字段，再用一次撤销回退整批操作。
对 Game Jam 中途很有用的缓存：重新打开项目时，只要没有变化，就复用导入文件和编译代码；File → New Scene 则打开一个用于实验的临时场景。

还欠缺什么

基于 Fernando 使用的数据资产，让设计师在游戏运行时修改值和监听器。组件已经存在（见 Fernando 一节），实时编辑循环还没有。
保留 Play Mode 中修改的值。目前停止时总会丢弃运行副本，以及其中调整过的一切。

**成功指标：**活跃项目中，从编辑到试玩的循环耗时中位数。

Daniela

游戏美术

A·P·I·J：炼金型（Alchemist）、纯粹型（Purist）、集成型（Integrator）、实干型（Journeyman）。

今天的 Turian

用于导入模型的 FBX 和 OBJ 插件。
Studio 的可停靠布局：她布置好的工作区可以保持下来。
Studio 的 Scene 和 Game 视图、无头截图以及导出的游戏，都由同一个渲染器绘制，使用 PBR 金属度／粗糙度材质。Daniela 看到的就是最终交付的画面。
每个实例化模型都可以带有一个色调和四个自定义值，而不打断批处理。
预制体和预制体变体，配合资产浏览器、撤销与重做，让套件保持一致。

还欠缺什么

带有曲线编辑和时间轴的动画系统。
2D 精灵。Turian 渲染 3D，尚无 2D 工作流。
粒子。
目前还没有音频系统。
阴影、基于图像的光照、天空盒、后期处理，以及由项目代码提供的自定义渲染通道；之后是节点式着色器编辑器。

**成功指标：**在制作工具与引擎之间往返后，无需返工的资产导入占比。

Eduardo

关卡设计师

I·W·C·J：迭代型（Iterator）、世界构建型（Worldbuilder）、策展型（Curator）、实干型（Journeyman）。

今天的 Turian

开箱即用的 Bepu 物理。
失败不会影响正在编辑的场景：Play Mode 运行副本，停止时丢弃。预制体、变体、资产浏览器、撤销和重做，让内容繁多的场景保持一致。
GPU 实例化会把连续使用相同网格和材质的对象合并为一次绘制。在一个测试场景中，10,000 个相同道具从 8,791 次绘制调用降为一次，像素完全一致。视锥剔除会跳过摄像机看不见的内容。
标签、独立的层分类空间、可见性与选择锁定、矩形选择、旋转操纵器和朝向控件：这些小工具让复杂场景也能顺利编辑。

还欠缺什么

粒子。目前还没有粒子系统。
补间和动画时间轴。Turian 目前还没有动画系统。
后期处理。
拖放：直接从文件管理器把模型文件拖进场景。
吸附，不只吸附世界网格，也能吸附其他模型。
散布和地形等世界构建工具，安排在动画和渲染缺口之后。

**成功指标：**从不打开代码文件的用户中，无崩溃会话的比例。

Fernando

游戏经济设计师

I·H·I·J：迭代型（Iterator）、独立型（Hermit）、集成型（Integrator）、实干型（Journeyman）。

今天的 Turian

游戏数据保存在数据资产中，即可通过 Inspector 表单编辑的普通 JSON 文件。程序员用 [CreateAssetMenu] 暴露一个新类型后，设计师就能自行创建和编辑。数据资产变体只覆盖变化的内容。
Studio 的文件监视器会重新导入外部修改：在编辑器外修改数据文件，系统会自动发现。
标签和层也是资产，因此重命名或重新排序不会破坏任何场景或预制体引用。
数据资产驱动设计的第一版：事件、变量、运行时集合和状态机都是由设计师连接的资产，以 brick 的形式随引擎提供。
数据交换通道：每种区域设置对应一张 .strings 表，保存稳定键、原文、译文、注释和状态；支持不会抛异常的回退、替换、复数和选择块；可以用 --locale 为一次会话或截图强制指定语言；编辑器库能读写 XLIFF 1.2 和 CSV，同时保留键、原文、译文、注释和状态。

还欠缺什么

Studio 中显示“谁监听谁”的总览，以及游戏运行时的实时值和手动触发按钮。
带验证和撤销的数据资产表格导入导出。字符串表已经能通过 CSV 往返，游戏平衡表还不能。
围绕库建立完整的 XLIFF 工作流：从 Studio 和命令行导出、导入，经过测试的往返，导出之间的变更报告，XLIFF 2.x，键和占位符验证，以及从右向左书写的文字体系支持。
分析功能，让平衡调整能够根据玩家的实际行为来评估。
云服务。今天的 Turian 不假定必须有后端，也不提供帮助运营后端的功能。

**成功指标：**无需程序员介入就进入游戏的内容修改占比。

Gabriel

DevOps 工程师

C·P·A·C：交付型（Closer）、纯粹型（Purist）、架构型（Architect）、统筹型（Conductor）。

今天的 Turian

官方容器镜像包含 SDK 和软件 Vulkan 驱动。turian-cli export 可以在任何 CI 服务中运行，手册还为其中两种服务提供了现成工作流。
固定输入。当 CI=true 时，brick 还原自动使用 --locked；锁文件记录版本、哈希、注册服务和签名密钥，签名使用普通的 OpenSSH ed25519 密钥。brick 缓存目录可以在多次运行之间共享。
turian-cli oap validate 检查包头和每个资产的 CRC-32，失败时以非零退出码结束。
模拟检查点在每个 tick 都有状态哈希，并在 30、60、144 Hz 渲染，以及保存后恢复的情况下进行比较。对无头测试场景，玩法的可复现性是已经验证的结果，而不只是承诺。

还欠缺什么

每个 brick 和每个包的大小与构建耗时报告，让补丁发布前就能知道体积。
构建两次并比较字节的 CI 检查。今天的 Turian 能承诺相同输入，还不能承诺相同输出。
构建时的图资产分析。
面向发行的资产打包；目前导出会按原样分发导入后的目录树。
性能分析器。
iOS、Android 和主机目标；目前导出面向桌面平台（Windows／Linux）。
无头 NativeAOT 服务器；早期示例已经能在没有裁剪警告的情况下导出。跨平台物理确定性仍是未来工作。

**成功指标：**在 CI 中运行 CLI 的不同组织数量。

Isabela

AA 工作室负责人

C·H·A·D：交付型（Closer）、独立型（Hermit）、架构型（Architect）、导演型（Director）。

今天的 Turian

用直白的语言说明条款：MPL 2.0、无版税，游戏的许可证由工作室选择。发布规模小而频繁；主版本更新意味着变更可能破坏项目；每个主版本都在手册中附带迁移指南。
发布说明会引用实测数字，也会说明它们不能证明什么，例如一次绘制调用渲染 10,000 个实例化道具、10,000 个彩色立方体约占用 0.6 毫秒 CPU 时间，或者“跨平台物理确定性仍是未来工作”。
Studio 和运行时都有统计显示，报告绘制调用、实例数和剔除数量。无头截图报告同样的计数器，因此任何人都能复现数字。

还欠缺什么

一款已发布的游戏。什么游戏、谁做的、在哪家商店都可以。目前数量是零，我不会假装不是。
有说服力的演示：工作室可以在新人入职第一天交给他的那种，而不是只有数字的发布说明。
官方支持，免费或付费均可。目前支持就是我自己。
公开、可复现的基准测试套件：固定场景、资产、摄像机和质量设置，公开硬件、驱动、精确版本与日期，报告平均和最坏情况帧时间、峰值内存、首帧延迟和导出大小。
基于已发布版本制作的展示项目，以及附带公开验收清单的移动端导出。

**成功指标：**在制作人员名单中注明使用这款工具的商业游戏。

Julio

AAA 制作人

C·H·A·C：交付型（Closer）、独立型（Hermit）、架构型（Architect）、统筹型（Conductor）。

今天的 Turian

每个团队的内容都是一个 brick，包含 ID、版本、声明的依赖关系和引擎兼容范围。使用不在商店自动批准名单中的名称发布版本，需要等待审批；版本永不删除或替换；撤回（yank）或弃用版本必须显式操作，并给出原因。
程序集定义：团队脚本以带有显式引用的单元编译，因此可以拆分工作，不必所有人都编译一切。
预编译 brick：brick pack --precast 分发已经编译的程序集，因此还原 brick 不意味着重新编译。
资产包（OAP）可以要求一个基础包，并按 ID 覆盖资产而不重写引用，这是只分发变更内容的基础。
重新打开项目和运行 Build & Run 时，会复用导入文件和编译代码，只复制变更，让构建耗时成为可以逐周追踪的指标。

还欠缺什么

每个 brick 和每个包的大小与构建耗时报告，让补丁发布前就能知道体积。
系统性地检查构建、导入和脚本的警告及错误信息，让它们准确指出问题。有些已经做到了，但还不能作出全面承诺。
能把响应时间写进进度表的支持服务。
可选的多人游戏 brick，支持专用服务器构建。

**成功指标：**主动询问打包和补丁分发能力的咨询。

Mariana

工具开发者

C·S·T·I：交付型（Closer）、选购型（Shopper）、工具匠型（Toolsmith）、传播型（Influencer）。

今天的 Turian

Studio 本身就是插件平台上的一个插件。面板、命令、菜单、快捷键、设置页面和主题，都使用与第三方插件相同的注册机制。
扩展来自项目中的 C# 代码，通过特性声明，无需引用任何编辑器程序集：[MenuItem]、[Panel]、[CreateAssetMenu]、[ComponentContextMenu] 等，以及 [Button]、[Range]、[ReadOnly] 这样的 Inspector 特性。
brick 清单包含 ID、版本、兼容的引擎范围、依赖、NuGet 需求和 SPDX 许可证。每个脚本和资产都带有 .meta 文件，其他项目引用其中的 ID，因此重命名和移动文件不会破坏使用方。
Guinevere.Autoformer，用于自动创建 GUI 表单和工具的库。
brick verify --against 检查存根是否仍与实际 brick 匹配，brick stub 则让其他人可以基于尚未完成的工作继续开发。已安装的 brick 为只读，客户通过变体和导入覆盖进行修改。
每项破坏性变更都会写入迁移说明。
版本永不删除或替换。被撤回的版本仍向锁文件固定了它的项目提供，但不会再被新选中。brick diff 和 brick rebase 处理分支副本；向带签名的注册服务发布时，使用限定作用域的令牌：releases、yank、deprecate。

还欠缺什么

将扩展接口文档化为版本化 API，明确每个引擎版本的兼容性承诺，并把引擎、特性和 SDK 作为插件可引用的包提供。
自动生成、按版本提供的 API 参考网站，让插件作者不必到源码中搜索签名。
注册服务之上的公开商店：发布者作用域、审批流程、版本公告与来源信息，以及同一包面向不同目标的变体。

**成功指标：**核心团队之外的人发布的扩展和插件。

审视背后：八个方面和一张矩阵

我作出的每个引擎决策，最终都会落到八个方面之一：

方面	包含什么
艺术	渲染、着色器、2D、3D、音频、制作工具
自动化	CI/CD、测试、打包、无头构建、可复现构建
商业	价格、套餐、条款、权利、服务、支持
代码	代码优先工作流、API、深度控制、包、性能
生态	扩展、辅助工具、资产商店、集成、数据导入导出
编辑器	易用性、拖放、可视化“编程”工具、场景组合
学习	教程、文档、社区、视频、聊天室、翻译
平台	移动端、VR、主机、服务器、多人游戏

下表是我对十个用户画像在各方面需求的理解。每个画像包含四种风格，每一格以其中要求最强的风格作为默认判断。这些看法会随着认识而变化。

方面／用户画像	A	B	C	D	E	F	G	I	J	M
艺术	◐	○	◐	●	●	○	○	◐	○	○
自动化	○	●	◐	○	○	○	●	◐	●	◐
商业	◐	●	◐	○	○	○	◐	●	●	●
代码	○	●	●	○	○	○	●	○	○	●
生态	●	○	●	◐	●	◐	◐	◐	◐	●
编辑器	●	○	●	●	●	◐	○	○	○	●
学习	●	◐	◐	◐	◐	◐	◐	◐	◐	●
平台	◐	●	●	○	○	○	●	●	●	◐

实心圆表示必备条件：这一方面如果缺失或失效，其他地方再好，这个人也会离开。半圆表示重要，但不是采用工具的必要条件。空心圆表示，可以等其他工作顺带实现。

矩阵说明了什么

编辑器是整天在工具里工作的人的必备条件：Ana、Carlos、Daniela、Eduardo 和 Mariana。其余人的必备条件在别处。
艺术恰好是两个人的必备条件。 他们制作游戏的视觉表现，其余人使用这些成果，或根本不接触。
生态是依赖选购资产的创作者的必备条件。 Benjamin 那格有意留空，因为代码优先的用户以代码的形式获取库，而不是从商店获取。对视之为必备条件的四个人而言，商店不是一个普通功能，而是产品的一半。
重视流水线的人聚在一起。 Benjamin、Gabriel 和 Julio 都在自动化、代码或平台方面有必备条件，Isabela 也加入了平台这一项。他们对编辑器不会达成一致，但对流水线可以。
学习是初学者和工具开发者的必备条件。 其他人可以读手册，或者读源码。
商业是付款、签约、销售或供货的人的必备条件。 其余人只管工作。

MASS4 如何使用这些用户画像

矩阵把人和工作连接起来：

为 Issue 加标签。 有些 Issue 带有 persona:* 标签。出现这个标签，就表示相应的人物关心这个主题。
内部维护要明说。 不服务任何用户的功能，要么是内部维护，要么是判断失误。两者都可以存在，但都必须说清楚。
主张必须推动指标。 每个画像最后都有一项指标，用来观察 Turian 是否真的正在赢得这个人的认可。如果某个条目声称服务某个画像，就应该能指出它会推动哪项指标。说不出，就只是装饰。
否决规则也适用于具体交付。 如果交付的东西破坏了所服务画像的必备条件，对这个人而言就是彻底失败。矩阵会明确指出受影响的是谁。

服务这十个人的是整个生态，而不只是引擎。

资产商店最直观：Ana 选购模板和套件，Carlos 寻找能救下 Game Jam 的 brick，Eduardo 找场景道具，Mariana 则在那里发布。因此，商店的客户和供应者都有自己的位置。
库是另一个例子：Graph、Guinevere、OAP、KTX2 等独立于引擎存在，首先服务 Benjamin 和 Mariana。即使底下的引擎变了，它们也会保留自己的名称和版本发布。
第三类是服务和社区空间：Isabela 所需的人才市场、Julio 的支持渠道，以及用 Ana 自己的语言回答她第一个问题的地方。
矩阵中的商业和生态方面，根本不是由引擎填满的，而是由它周围的一切填满。这一切，正是 MASS4 的意义。

最后再说一件事。这十个人并不存在。他们是我对 Turian 这样的工具应当满足什么需求的理解，矩阵里的每个圆都是一种意见，也就可能是错的。但你是真实存在的。如果你制作游戏，或者为制作游戏的人开发工具，你就是整篇文章所说的用户。你喜欢什么、讨厌什么、不同意什么，比我的看法更重要。用户画像是地图，你才是真实的土地。地图哪里画错了，请说出来：评论、Issue，或者在你看到这篇文章的地方发帖都可以。下一次审视会因此变得更好。