Unity 的二十年：从降低游戏开发门槛，到重建开发者信任

Unity 的历史里，有一个让人感慨的变化：它曾经让许多人第一次觉得，自己也能做出一款游戏；后来，它的一次收费政策调整，又让许多人第一次认真考虑，要不要离开这套已经用了多年的工具。

从创业团队制作的小球游戏，到移动游戏开发的重要工具，再到影视、工业、广告和 AI，Unity 不断扩大自己的边界。引擎内部也在扩张：运行时、渲染管线、编辑器工作流，一层层新技术叠加在旧基础上。

这些变化有各自的理由。但站在开发者的位置，一个问题始终没有变：我选择这套工具，是为了更顺利地把游戏做出来。公司的增长与技术的更新，最后有没有帮助我做到这一点？

一、起点：三个开发者与 GooBall

2004 年，David Helgason、Nicholas Francis 和 Joachim Ante 在哥本哈根创办了 Unity 的前身 Over the Edge Entertainment。次年，他们推出 Mac 游戏 GooBall，并在苹果开发者大会上展示 Unity 引擎。GooBall 没有获得商业成功，开发工具却逐渐找到自己的用户。¹

这段经历常被讲成“游戏失败，于是改卖引擎”。真实过程要更连续一些：Unity 官方回顾提到，团队制作 GooBall 所用的引擎时，就已经有将它授权给其他开发者的打算。游戏与工具的探索原本就有交集。¹

理解这个起点，需要把自己放回当时的小团队处境。制作一款游戏，需要把图形、物理、声音、资源导入、场景编辑和平台适配连接起来。自研意味着投入大量基础建设；购买成熟工具，又可能面对不适合小团队的成本与工作方式。Unity 早期瞄准的，正是独立开发者在这两者之间的空缺。¹

“让游戏开发大众化”之所以有吸引力，是因为它对应了非常具体的愿望：先把一个场景搭起来，让角色动起来，尽快验证脑子里的玩法。一个只有几个人的团队，也应该能够开始制作，而不必先成立一支引擎团队。

二、崛起：把工具、价格与时代机会接在一起

Unity 的成功，很难归结为某一个技术特性。更有解释力的，是几件事碰到了一起。

首先是移动平台。Unity 在 2008 年就宣布了 iPhone 支持方向，较早进入这个新兴市场。对于需要快速制作和发布游戏的小团队，已有的编辑工作流能延伸到新设备，显然很有吸引力。²

其次是价格。Unity 并非从诞生起就免费：2009 年发布 Unity 2.6 时，公司把原来售价 199 美元的 Unity Indie 改为免费提供的 Unity。这里说的是当时的基础版本，不意味着全部平台与专业功能从此都没有费用。³

再往后，2010 年 11 月上线的 Asset Store，把开发者之间的复用变成了一个市场。它不仅提供模型与贴图，也容纳脚本、编辑器扩展和其他工具。⁴

这些因素连在一起，形成了一种很实用的吸引力：开始尝试的成本低，做出原型的路径短，缺少的能力还能从现成资源里补足。

我认为，Unity 对小团队最重要的贡献，是缩短了“想到一个玩法”和“看到它运行”之间的距离。技术人员可以写逻辑，美术可以在场景里摆放资源，设计者可以调参数。大家围绕同一个可运行的项目工作，想法更容易变成可以讨论、测试和推翻的东西。

这也解释了生态为什么重要。一个工具越常用，围绕它的经验就越容易积累；已有教程与插件又会降低下一批人的学习成本。选择引擎时，开发者选择的也包括这套遇到问题后能找到帮助的环境。

三、技术底座：C#、Mono、IL2CPP 与 CoreCLR

从组件开始理解 Unity

Unity 的常见开发方式围绕 GameObject 与 Component 展开。GameObject 承载场景中的对象，组件提供具体能力；自定义的 MonoBehaviour 脚本，也可以作为组件附着到对象上。⁵

例如，一个角色可以同时拥有位置与旋转信息、渲染组件、碰撞组件，以及处理移动输入的脚本。开发者将这些能力组合起来，再通过编辑器调整参数与引用。

这套工作方式容易上手，也让“写程序”和“编辑场景”能够互相配合。不过，项目长大以后，组件之间的依赖、对象生命周期和资源管理，仍然需要认真设计。容易开始，并不会自动解决大型项目的组织问题。

写 C#，不意味着整个引擎都是 C#

Unity 中存在托管与原生两侧。一个直观例子是 UnityEngine.Object：它的 C# 对象与原生 C++ 对象存在对应关系。游戏脚本通过托管 API 使用引擎能力，并不意味着渲染、物理等底层工作全部由这些脚本完成。⁶

早期 Unity 采用 Mono 作为托管技术基础。在微软现代跨平台 .NET 尚未形成的年代，Mono 为 Unity 提供了重要的跨平台支撑。此后 Unity 长期维护自己的 Mono 分支，也逐渐背上了与现代 .NET 生态同步的负担。⁷

理解后续变化，可以先区分三个名字：

Mono 与 IL2CPP 的执行路径见 Unity 的脚本后端文档；CoreCLR 则是另一条迁移线，正在逐步接替 Mono 的角色。它的适用范围要看具体版本，不能把一个实验后端的出现理解成所有平台同时切换。⁸⁹

为什么 CoreCLR 登场，不等于 IL2CPP 退场

Unity 的 .NET 现代化，主线是 Mono 逐步让位给 CoreCLR——接回现代运行时、库生态和工具链。IL2CPP 走的却是另一条路：把 IL 转成 C++，再经平台编译器做 AOT 构建。前者解决“用什么运行时跑托管代码”，后者解决“哪些平台必须用 AOT 发布”。⁸⁷

IL2CPP 的名字就是 Intermediate Language to C++。开发者仍然写 C#，构建时转换的是编译后的 IL；它不会把你的源码工程变成一个需要手动维护的 C++ 游戏工程。⁸

它的一项重要价值是支持 AOT 发布，帮助 Unity 覆盖 iOS 和部分主机等目标。Unity 在说明 .NET 现代化方向时，也同时讨论了 IL2CPP 与其他编译技术的演进，并没有把它写成 CoreCLR 的过渡品。⁷

所以，不能把它们排成“Mono 被 IL2CPP 淘汰，IL2CPP 再被 CoreCLR 淘汰”的直线。编辑时用什么运行脚本、发布到什么平台、采用 JIT 还是 AOT，是相关但不同的问题。 同样，选择 IL2CPP 构建 Player，也不代表编辑器里的 Play Mode 已经改用 IL2CPP。

这是一张概念图。实际可选后端受 Unity 版本、编辑器与 Player 的区别，以及目标平台限制约束。⁸⁹

四、扩张：游戏引擎之外的 Unity

2014 年 10 月，曾担任 Electronic Arts CEO 的 John Riccitiello 接替联合创始人 David Helgason 出任 Unity CEO。随后，Unity 于 2020 年走向公开资本市场。¹⁰¹¹

管理层更替和上市，本身不能证明公司偏离了开发者。它们提供的背景是：Unity 的目标越来越大，公司需要解释的不只有“工具是否好用”，还有收入如何增长、业务怎样扩展。

影视、广告与 AI，各自有不同的商业逻辑

2021 年，Unity 宣布以约 16.25 亿美元的现金与股票收购 Weta Digital 的工具、技术及相关工程团队，尝试把专业影视制作能力带向更广泛的创作者与云端工作流。这里尤其要区分：交易并不等于买下整家影视特效制作公司，视觉特效业务以 Wētā FX 的形式独立运行。¹²

2022 年，Unity 完成与 ironSource 的合并。这个方向更接近移动应用的广告、用户增长和商业化：Unity 希望同时参与产品的制作、运营与增长，而不只提供编辑器。¹³

AI 则又是另一组问题。到 2024 年初，Unity 的股东信仍在讨论 Muse、Sentis 和编辑器内的 AI 工作流，也明确保留非游戏行业的发展目标。¹⁴

从公司的角度看，这些方向有可以解释的联系：既然已经有实时 3D 技术和开发者生态，就尝试覆盖更多生产环节和市场。

但开发者衡量它们的方式会更直接：我的项目能否更稳定？构建是否更快？旧问题有没有得到修复？如果这些体验没有同步改善，新的业务故事就很难被感受为进步。

这里需要保留一个界限：不能仅凭发生了收购，就断言某个引擎问题必然因此延期。没有内部资源分配证据，我们能讨论的是战略取舍和可见的产品结果。我的判断是，扩张越广，Unity 就越需要证明这些投入最终能够回到创作流程中。

五、技术扩张：为什么渲染管线越来越多

商业路线在扩张，技术路线也在分叉。许多开发者最直观的感受，就是新建项目时要先决定使用哪套渲染管线。

这件事并非从 Unity 6 开始。Unity 2018.1 已经带来了 SRP 相关能力，以及处于预览阶段的 LWRP、HDRP；2019.3 中，LWRP 又更名、演进为 URP。¹⁵¹⁶

SRP 与 URP、HDRP 不在同一个层级：前者是架构，后两者是基于它构建的具体管线。LWRP 和 URP 也不应算作两条长期并存、互不相关的路线。¹⁷¹⁶

分开的理由，和分开以后的成本

面向移动设备的轻量渲染，与面向高性能硬件的高保真渲染，需求确实不同。让一套固定方案覆盖所有项目，并不容易。

问题在于，差异会传递到内容制作。不同管线的 Shader、光照模型和功能支持并不完全相同；Unity 官方文档也提醒，项目深入开发以后再切换管线，可能十分耗时，URP 与 HDRP 不能在同一个渲染设置中同时使用。¹⁷

于是，选择管线成了一个很早就必须作出的长期决定。素材是否兼容，教程适用于哪一套，插件作者要维护几个版本，都随之成为项目成本。

我理解这种分化的技术动机，也认为它暴露了工具平台的一种矛盾：底层越灵活，平台越需要替用户管理复杂性。否则，可选项增加的同时，开始制作游戏之前必须理解的知识也在增加。

六、Runtime Fee：一次定价决策如何伤到信任

2023 年 9 月，Unity 宣布 Runtime Fee，争议随即爆发。理解这件事，必须分清初版、修订版与最终取消，不能把不同阶段的条款拼成一个从未存在过的方案。

初版方案与随后的媒体解释见 Axios 报道；修订与取消则有 Unity 官方公告。¹⁸¹⁹²⁰

安装次数，为什么会成为如此敏感的计费单位

初版消息传出后，重装、免费分发、慈善包和订阅服务等情形立即引发质疑。Unity 随后的解释也发生过变化：关于重复安装是否再次计费，公司在发布当天就调整了对媒体的说法。¹⁸

这些争议背后，是一个很容易理解的问题：安装与收入之间并不存在固定比例。

假设一个游戏卖得很便宜，或者通过低收入的分发渠道获得大量用户，开发者获得的收入与触发的使用次数，就可能是两回事。再假设安装统计来自一个开发者无法独立核验的系统，那么预算、对账和争议处理都会变得困难。这里举的是计费模型的风险，不是在断言最终取消前的政策实际产生了某种账单。

对制作周期较长的游戏来说，还有更深一层的不安：项目已经选择引擎，人员、插件和技术都围绕它投入了几年。如果商业条件在途中发生重大变化，“换一套工具”往往意味着难以承受的额外工作。

开发者需要知道，今天作出的工具选择，在游戏完成时仍然能够放进原来的经营计划。 我认为，这正是 Runtime Fee 比普通涨价更伤信任的原因。

管理层为何走向安装量计费

我们能够核对的，是当时管理层如何解释政策，而不是某位高管的私人动机。Unity Create 负责人 Marc Whitten 在修订公开信中表示，政策的目标是支持持续投入引擎，同时承认公布之前没有充分听取开发者反馈。¹⁹

结合 Unity 从编辑工具向运营、增长服务扩展的路线，我的理解是：管理层希望公司收入能更多地随客户产品的使用规模增长，而不只取决于购买了多少编辑器席位。

这能解释商业上的诉求，却不能替安装量计费的具体设计辩护。收入增长目标与开发者的风险承受能力，需要通过清晰、可核验、可预期的规则连接起来。

Riccitiello 作为时任 CEO，应当为其任内重大经营决策承担管理责任。但公开材料不足以证明整个方案由他一人提出。与其把历史写成“一个坏 CEO 突然想出坏主意”，我更在意：为什么一家依赖开发者生态的公司，会在推出这样的政策之前，低估它对合作关系的影响？

七、换帅与收缩：哪些事情改变了

2023 年 10 月 9 日，Unity 宣布 Riccitiello 离任，Jim Whitehurst 出任临时 CEO。2024 年 5 月 15 日，Matt Bromberg 正式接任。中间存在一个重要的过渡阶段。²¹²²

业务重整，早于新任 CEO 到来

Unity 的 2023 年第四季度股东信记录了已经启动的业务重整：缩小专业服务范围、退出多人业务中的硬件部分、停止独立开发专业艺术工具，并把相关能力整合进编辑器与 AI 工具。与 Wētā FX 的服务协议也被终止，改为相关内部工具的永久许可安排。¹⁴

这些动作不能全部归到 Bromberg 上任之后。同样，股东信仍把引擎、云与商业化列为核心，并保留工业领域投资。因此，“Unity 把影视、AI、工业全砍了，只做游戏引擎”并不符合当时公开的重整方向。¹⁴

更准确的描述是，Unity 开始收缩部分独立业务，重新安排投入的边界。至于收缩是否改善了引擎研发，还需要看后续交付；裁掉一个团队和修好一个长期问题之间，并没有自动成立的等号。

取消 Runtime Fee，是一项明确的政策修复

2024 年 9 月 12 日，Bromberg 宣布立即取消面向游戏客户的 Runtime Fee，并重新强调与开发者之间的信任。公告同时公布了订阅价格调整与 Unity Personal 的变化。它意味着收费方式回到另一条路径，并不意味着 Unity 从此停止商业化。²⁰

那个启动画面，究竟什么时候可以关掉

这里说的是玩家启动游戏时看到的 Made with Unity 品牌画面。

Unity 在 2023 年 9 月 22 日的修订公开信里，就已经承诺取消 Personal 版的强制品牌启动画面；这发生在 Riccitiello 离任之前。2024 年公告确认，这一变化随 Unity 6 向 Personal 用户提供。Unity 6 随后于 2024 年 10 月 17 日正式发布。¹⁹²⁰²³

这项变化的意义，在于免费版开发者获得了更多作品呈现上的控制权。准确地写出承诺与落地的时间，也能避免把不同管理阶段发生的事情，全部压缩成“新 CEO 来了以后就好了”。

八、Unity 6 与 Unity 7：修复底座，也修复预期

管理变化可以很快公布，运行时和渲染架构的调整却需要较长时间。Unity 接下来的方向，恰好又回到了前文的两条技术线。

CoreCLR：接回现代 .NET 生态

Unity 早在 2022 年的《Unity and .NET, what’s next?》中，就公开讨论了从 Mono 向 CoreCLR 迁移的方向。这是一项跨越多个版本和管理阶段的工程，不能理解成换帅之后才开始。⁷ 若希望更细地看 JIT、AOT 与迁移动机，可参阅 Unity 的 C# 运行时：从 Mono、IL2CPP 到 CoreCLR。

截至本文整理时，Unity 6.7 文档中的 CoreCLR 桌面 Player 后端仍标为实验性功能，用于 Windows、macOS 和 Linux 的测试验证；该文档同时说明，编辑器自身仍使用 Mono。因此，“Unity 6 支持 CoreCLR”必须附带具体版本与实验状态。⁹

2026 年 6 月的官方更新，把完整的 CoreCLR 编辑器和桌面 Player 支持列入 Unity 7 的目标，并提出接入更新的 .NET 与 C#。这些属于路线图承诺；不能据此宣称所有开发者已经获得了完整的新运行时，更不能假定每个项目都会立刻大幅提速。²⁴

我更看重的，是这次更新能否降低 Unity 与通用 .NET 工具之间的距离：让运行时、库生态和开发工作流的进步，更持续地传递到游戏项目里。能否做到，最终仍要看兼容性、迁移成本和真实项目表现。

Unified Rendering：怎样理解“重新统一”

“统一渲染”的方向很容易被听成：以后会有一套叫 Unified RP 的全新管线，直接把所有旧管线合在一起。

但 Unity 公布的 2026 年渲染管线战略，描述的是更具体、渐进的调整：重点发展 URP；HDRP 以维护稳定性及特定平台支持为主；Built-in 从 Unity 6.5 开始进入弃用流程，并继续在后续支持期内保留。弃用不等于当场移除。²⁵

因此，本文将这一阶段称为“向 URP 集中、减少渲染分化”。URP 中的 U 仍然是 Universal；不能把收敛目标写成所有管线已经无缝合并的既成事实。

对开发者而言，真正有价值的统一，应当体现在素材和工具更容易复用、功能选择更清楚，以及迁移时少做重复劳动。只改变名字，并不能解决这些问题。

回归引擎，也仍然包含 AI 与商业服务

2026 年 7 月公布的 Unity 7 路线图，除了 CoreCLR 与图形技术，也列出了 CLI、面向编码 Agent 的连接能力，以及广告与商业增长功能。公告计划在 2026 年 12 月进入早期 Beta、2027 年第一季度正式发布；截至本文日期，这些仍是未来安排。²⁶

这说明“回归引擎”需要一个更实际的判断标准。AI 能不能减少机械操作？新工具能不能接入已有生产流程？技术更新能不能在可接受的迁移成本下交付？这些比公司是否再次提到某个热门词更有意义。

对 Unity，我愿意保留期待，也认为期待应该建立在持续交付上。过去的贡献不会因为一次错误决策消失；一次政策撤回，也不足以保证以后永远不会再发生类似问题。

Unity 最早打动人的地方，是让创作者觉得，自己离做出一款游戏更近了。接下来的版本若要重新赢得信任，就需要让这种感受持续成立：今天可以顺利开始，几年后也能够安心完成。

注释

1. Unity Learn，What is Unity?。其中 The Unity Story 一节回顾创始人背景、GooBall 与引擎授权方向的早期思路。 ↩ ↩² ↩³

2. Unity，2008，Unity is Coming to the iPhone。支撑正文关于 Unity 较早进入 iPhone 平台的叙述。 ↩

3. Unity，2009，Unity 2.6 Released And Now Free!。说明 Unity Indie 改为免费提供的 2009 年政策变化。 ↩

4. Unity，2014，Asset Store 四周年公告。回顾 Asset Store 于 2010 年 11 月上线。 ↩

5. Unity Manual，Introduction to components、GameObject。支撑 GameObject 与 Component 工作方式的说明。 ↩

6. Unity 6.0 Manual，Object。说明托管 C# 对象与原生 C++ 对象的对应关系。 ↩

7. Unity，2022，Unity and .NET, what’s next?。官方阐述 Mono 向 CoreCLR 迁移方向，以及 IL2CPP 等编译技术的并行演进。 ↩ ↩² ↩³ ↩⁴

8. Unity 6.0 Manual，Scripting backends。区分 Mono、IL2CPP 与 CoreCLR 各自承担的脚本后端角色。 ↩ ↩² ↩³ ↩⁴

9. Unity 6.7 Manual，CoreCLR scripting back end (Experimental)。说明 CoreCLR 桌面 Player 后端的实验性状态，以及编辑器仍使用 Mono。 ↩ ↩² ↩³

10. Unity，2014-10-22，Unity Technologies Appoints John Riccitiello as CEO。支撑 Riccitiello 接替 Helgason 出任 CEO 的时间点。 ↩

11. Unity，2020，Unity Announces Pricing of Initial Public Offering。支撑 Unity 于 2020 年 IPO 的叙述。 ↩

12. Unity，2021，Unity Announces Intent to Acquire Weta Digital。支撑约 16.25 亿美元收购 Weta Digital 工具与技术团队的公告内容。 ↩

13. Unity，2022-11-07，Unity Completes Merger with ironSource。支撑 Unity 与 ironSource 合并完成的官方记录。 ↩

14. Unity，2024-02-26，Q4 2023 Shareholder Letter（第 2–4 页）。支撑 2023 年第四季度业务重整、Wētā FX 协议变更及 AI 方向等公开表述。 ↩ ↩² ↩³

15. Unity，2018，2018.1 is now available。支撑 Unity 2018.1 引入 SRP、LWRP 与 HDRP 预览的发布时间。 ↩

16. Unity，2019，Lightweight Render Pipeline is Evolving!。支撑 LWRP 更名并演进为 URP 的官方说明。 ↩ ↩²

17. Unity Manual，Choose a render pipeline。支撑管线切换成本、URP 与 HDRP 不可共存等文档表述。 ↩ ↩²

18. Stephen Totilo，Axios，2023-09-13，Unity rushes to clarify price increase plan, as game developers fume。第三方报道，记录初版 Runtime Fee 争议及 Unity 对安装计费说法的调整。 ↩ ↩²

19. Marc Whitten，Unity，2023-09-22，An open letter to our community。修订方案、取消 Personal 强制启动画面承诺，以及 Whitten 对政策目标的解释。 ↩ ↩² ↩³

20. Matt Bromberg，Unity，2024-09-12，Unity is canceling the Runtime Fee。宣布取消面向游戏客户的 Runtime Fee，并说明订阅价格与 Unity Personal 变化。 ↩ ↩² ↩³

21. Unity，2023-10-09，Unity Announces Leadership Transition。支撑 Riccitiello 离任、Whitehurst 出任临时 CEO 的时间点。 ↩

22. Unity，2024-05-01，Unity Appoints Matthew Bromberg as New CEO。支撑 Bromberg 正式接任 CEO 的日期。 ↩

23. Matt Bromberg，Unity，2024-10-17，Unity 6 launches today!。支撑 Unity 6 于 2024 年 10 月 17 日正式发布。 ↩

24. Unity，2026-06-16，CoreCLR, Scripting, and Serialization Update – June 2026。官方进度更新，列出 Unity 7 完整 CoreCLR 编辑器与桌面 Player 支持目标。 ↩

25. Unity，2026，Render Pipelines strategy for 2026。支撑 URP 集中发展、HDRP 维护为主、Built-in 弃用流程等 2026 年渲染战略。 ↩

26. Unity，2026-07-20，Unity 7 Roadmap Revealed At Unite Seoul。支撑 Unity 7 路线图、Beta 与正式发布时间窗口，以及 AI 与商业服务并列列出的安排。 ↩