民主化的宣言

把时钟拨回2005年6月6日，旧金山莫斯康展览中心西厅的空气中弥漫着那种只有苹果发布会才会有的特殊气味——臭氧发生器掩盖不住上千台PowerBook散热风扇吹出来的微热电子气息。苹果全球开发者大会的主会场刚刚结束了一场关于Mac OS X Tiger的冗长技术讲座，与会者三三两两地涌向展区，手里攥着刚领到的瓶装水和印有苹果标志的笔记本。他们大多是Mac平台的忠实开发者，习惯了在这个生态系统中接受一种不言自明的等级秩序：苹果提供优雅的平台，开发者在这个平台上建造精致的应用，而游戏——真正的三维游戏——通常属于另一个世界，那个由DirectX、NVIDIA显卡和Windows XP组成的PC游戏世界。

在展区边缘的一张不起眼的展示台上，一个年轻人正在做一件在那个年代看来几乎不合时宜的事。他打开一台PowerBook，桌面上躺着一个名为“Unity”的应用程序图标。没有安装向导，没有命令行配置，没有让人望而生畏的SDK文档。

他做的第一个动作简单到让路过的人以为这是一个普通的图像浏览器：他从桌面上选中一张纹理贴图，用鼠标拖住它，越过屏幕上的空间，把它丢进了Unity编辑器的一个面板里。然后三维模型出现了。不是线框，不是需要编译后才能预览的工程文件，而是一个完整渲染的、带材质的三维物体，实时地出现在编辑器的场景视图中。

几个刚走过来准备领取宣传册的开发者停下了脚步。他们看到的是这样一幅画面：一个三维空间里的茶壶模型，表面覆盖着刚才拖进去的那张纹理，在屏幕上的实时预览窗口中安静地旋转着，光照正确，阴影柔和，帧率流畅。没有加载进度条，没有编译提示，没有任何打断操作连续性的技术噪音。拖进去，就出现了。

这个做演示的年轻人是Joachim Ante，Unity的联合创始人和首席架构师。他接下来打开了一个文本编辑器——不是Visual Studio，不是Xcode，而是一个轻量级的脚本编辑窗口。

他敲了几行代码，语法看起来像C，但更简洁，不需要手动管理内存，不需要声明头文件，不需要处理指针。那几行代码绑定到场景中的茶壶模型上：每帧绕Y轴旋转一度。他点击播放按钮。茶壶开始旋转。从拖入纹理到模型旋转，整个过程不到两分钟。围观的人群中有人问这是什么语言。Ante回答了。又问需要什么运行时环境。回答是引擎内置了。再问支持哪些文件格式。Ante把一张宣传单推过去，上面列着一串格式名：FBX、OBJ、3DS、Maya、Blender——不是通过复杂的预处理管线，而是直接拖入。

这一刻，在莫斯康展览中心那个不起眼的角落里，一份关于谁能制造三维世界的激进宣言被无声地递交了。它不是以白皮书的形式，不是以行业联盟的协议，而是以一个动作——拖拽——重新划定了三维内容创作的门槛。Unity 1.0的首次公开亮相，由苹果公司软件工程高级副总裁斯科特·福斯托通过Mac OS X系统进行展示，其明确的目标是使游戏开发大众化。

这个目标在那个年代听起来像是营销修辞，但Ante在展示台上完成的那个拖拽动作，把它变成了一份可操作的技术承诺。要理解这份承诺的激进性，需要把时钟往回拨几年，回到Unity诞生的那个边缘地带。在2003年左右的哥本哈根，三个丹麦年轻人——Joachim Ante、David Helgason和Nicholas Francis——正在经营一家名为Over the Edge Entertainment的小公司。他们做的事情和AAA游戏开发几乎没有任何关系：为Mac平台开发着色器工具，客户是建筑设计师、工业产品展示商和零星的独立创作者。在那个年代，选择Mac作为三维图形开发平台本身就是一种边缘化的姿态。游戏行业的主流在Windows上，id Software的引擎在OpenGL上，Epic的虚幻引擎在Direct3D上，而Mac的三维图形生态几乎是一片荒地。

苹果公司自己的图形API还在从QuickDraw 3D向OpenGL过渡的痛苦中挣扎，Mac平台的游戏数量少到可以用一只手数完。

但这种边缘性恰恰塑造了Unity的技术基因。Ante、Helgason和Francis不是在为一家拥有技术美术团队的大型工作室开发内部工具，而是在为那些可能只有一个人、一台电脑、没有任何图形工程背景的建筑师和设计师开发软件。他们的用户不会写着色器代码，不关心渲染管线的可编程阶段，不理解什么是顶点缓冲对象。

他们只知道一件事：他们有一张纹理，一个模型，一个想法，他们需要尽快在屏幕上看到结果。这种用户画像在当时的引擎产业中是完全不可见的。id Tech的典型用户是像约翰·卡马克那样的程序员——他们阅读源码，修改渲染管线，用C语言直接和GPU对话。Unreal的典型用户是像Epic自己那样的AAA工作室——他们拥有分工明确的团队，技术美术负责材质，关卡设计师负责场景，程序员负责扩展引擎功能。

这两种范式的共同前提是：使用引擎的人具备相当程度的技术能力，并且愿意投入时间来学习复杂的工具链。但Ante、Helgason和Francis看到的是一群完全不同的人。这些人不会花三个月学习引擎架构，不会编写自定义着色器，不会配置资产预处理管线。他们需要的是：把文件拖进来，在屏幕上看到结果，然后开始工作。这个需求不是市场调研得出的结论，而是三位创始人在哥本哈根接到的客户电话中反复听到的同一个问题——能不能让它更简单一点。

所以当Unity 1.0在2005年6月正式发布时，它所体现的设计哲学不是在AAA引擎的基础上做减法，而是从零开始建立了一套完全不同的工具逻辑。这套逻辑的核心可以概括为三个关键设计决策，每一个决策都对应着一个关于用户是谁的激进假设。第一个决策：以Mono脚本替代C++作为逻辑层语言。在2005年的引擎产业中，这是一个近乎异端的选择。id Tech的整个逻辑层是用C写的，后来过渡到C++，源码直接暴露给授权用户。

Unreal Engine从第一代开始就用C++构建，并且发展出了一套复杂的宏系统和反射机制来管理游戏对象。C++在游戏开发中的统治地位不是偶然的——它提供对内存的直接控制，性能开销极低，编译后的代码在目标平台上运行效率最高。对于一个追求极致帧率的AAA射击游戏来说，选择C++不是偏好问题，而是生存问题。

但C++的代价同样巨大。编译周期——从修改代码到在引擎中看到结果——可能长达几分钟甚至十几分钟。内存管理错误——野指针、双重释放、缓冲区溢出——是游戏开发中最常见的崩溃来源，追踪这些错误需要深厚的调试经验。更根本的是，C++的语法复杂性和概念密度形成了一道天然的技术屏障，将那些没有计算机科学背景的创作者挡在门外。

Ante选择Mono的决定不是来自某种语言宗教战争，而是来自一个非常具体的工程观察：他们的目标用户不需要在每帧中管理百万个多边形的内存分配，他们需要的是让一个茶壶模型旋转起来，响应键盘输入，触发简单的碰撞检测。

对于这类任务，C++的性能优势是过剩的，而它的使用成本却是致命的。Mono——一个开源的.NET运行时实现——提供了另一种可能：脚本语言级别的开发速度，自动内存管理，即时编译，以及与C#这种语法简洁的现代语言的绑定。

这个选择征收了第一笔通用化税。托管语言在运行时的垃圾回收机制会导致不可预测的帧率波动，当回收器触发时，游戏画面会突然停顿几帧——这在AAA射击游戏中是不可接受的，但对于一个建筑可视化项目或独立小游戏来说，这种偶发的停顿远不如能够快速迭代来得重要。

Ante的赌注是：对于他们定义的目标用户群，迭代速度的价值高于运行时性能的稳定性。

第二笔税是平台依赖性。Mono是Novell公司维护的项目，它的跨平台能力在2005年还远未成熟。

将Mono运行时嵌入Unity引擎意味着Unity的命运与Mono项目的健康状况绑定在一起——如果Mono停止维护，如果某个目标平台不被Mono支持，如果Mono的许可协议发生变化，Unity都需要承担相应的风险。这是一个技术决策，但也是一个生态赌注。

第三笔税最为微妙：脚本层与引擎运行时的绑定方式。Unity 1.0的Mono集成架构采用了一种在当时看来相当激进的设计——Mono运行时作为引擎进程内的一个托管环境运行，脚本代码通过一组精心封装的桥接接口与引擎的C++核心通信。游戏对象的Transform组件、Rigidbody物理属性、碰撞检测回调——所有这些底层功能都被包装成Mono可以调用的托管对象。这意味着脚本开发者永远不需要接触引擎的C++源码，但也意味着他们永远无法修改引擎的核心行为。当他们遇到桥接接口没有暴露的功能时，他们只能等待Unity的下一个版本。这是一种用控制权换取接入性的交易。

id Tech的源码交付模式意味着：这是全部代码，你可以修改任何东西，但你需要理解全部。Unity的Mono桥接模式意味着：你不需要理解底层，但你不能修改底层。两种哲学各自定义了自由的含义——一种是深入的自由，一种是上手的自由。

第二个决策：将资产导入流程简化为拖拽操作。在2005年的游戏开发管线中，资产导入是一个被严重低估的痛点。一个典型的工作流程是这样的：美术在Maya或3ds Max中创建模型和纹理，导出为FBX或其他中间格式，运行一个命令行工具或引擎插件将中间格式转换为引擎专有的资产格式，这个转换过程可能涉及材质重映射、纹理压缩、网格优化、碰撞体生成等十几个步骤，每一步都可能因为参数设置错误而失败。大型工作室有专门的技术美术来管理这条管线，编写导出脚本，调试格式兼容性问题。但对于一个独立开发者来说，这条管线本身就是一堵墙。Unity 1.0的资产导入设计用了一种近乎粗暴的方式推倒了这堵墙。

支持的文件格式——FBX、OBJ、3DS、Maya原生文件、Blender文件——被硬编码进引擎的导入模块。当用户将文件拖入编辑器时，导入模块自动检测格式，调用对应的解析器，生成引擎内部使用的元数据，将纹理转换为目标平台的压缩格式，将网格数据重新组织为适合渲染的顶点缓冲布局。所有这些步骤在后台自动完成，用户看到的就是：拖进去，出现了。

这个设计的激进之处不在于技术实现——格式解析器和转换工具在2005年已经相当成熟——而在于它抹去了资产管线的可见性。在Unreal和id Tech的工作流中，资产导入是一个需要理解的过程：你需要知道FBX导出的参数设置，需要理解纹理的Mipmap层级，需要手动指定碰撞网格的精度。这个过程提供了控制力，但也要求相应的知识。Unity的选择是：放弃控制力，换取零知识启动。代价是显而易见的。

自动导入意味着引擎必须对导入参数做出假设——纹理压缩格式、网格法线方向、动画帧率、材质属性映射——而这些假设在某些情况下是错误的。当一个建筑设计师拖入一个精确建模的CAD文件时，自动导入可能会错误地翻转法线方向，导致模型在引擎中看起来像是内外翻转的。当一个独立游戏开发者拖入一个角色模型时，自动绑定可能会丢失骨骼层级信息。这些问题在Unity 1.0中没有一个优雅的解决方案——用户要么接受自动导入的结果，要么回到手动配置的管线中，而Unity 1.0的手动配置选项远不如Unreal的资产管线和id Tech的源码级控制来得强大。

但Ante的赌注是：对于大多数目标用户来说，接受自动导入的偶尔错误比学习复杂的资产管线要容易得多。一个建筑师可以容忍模型在引擎中看起来不太完美，只要他能快速看到大致效果。一个独立开发者可以手动调整几个参数，只要他不需要写导出脚本。

这种足够好的哲学在专业引擎开发者看来是粗糙的，但它精确地匹配了目标用户的实际需求——他们不是在做需要像素级精确度的AAA产品，他们是在做需要快速迭代的小型项目。

第三个决策：将编辑器布局设计为面向非技术用户的窗口系统。要理解这个决策的意义，需要对比一下同一时期的Unreal Editor和id Software的开发环境。UnrealEd是一个全屏的集成环境，它的设计假设是：用户会在这个单一窗口中完成所有工作，从关卡编辑到材质设置到脚本编写。这种设计源于AAA工作流程的需要——当一个关卡设计师在构建场景时，他需要同时看到所有相关面板，并且这些面板的位置和大小是固定的，以确保不同团队成员之间的工作环境一致性。Unity 1.0的编辑器走了完全相反的路线。它的窗口系统更像是Photoshop或After Effects——面板可以自由浮动、停靠、调整大小，用户可以根据自己的偏好保存和加载窗口布局配置。

场景视图、游戏视图、层级面板、项目面板、检视器——每一个都是独立的窗口，可以被拖到不同的显示器上，可以被最小化，可以被关闭后重新打开。这个设计决策背后的用户假设是：Unity的目标用户不需要一个为特定工作流程优化的固定环境，他们需要一个可以适应各种不同工作流程的灵活环境。一个建筑设计师可能习惯于在Photoshop中处理纹理，在Maya中处理模型，然后在一个轻量级的查看器中预览结果——他的工作习惯是窗口式的、多任务切换的。一个独立游戏开发者可能同时开着浏览器查找文档、开着代码编辑器写脚本、开着图像编辑器修改素材——他需要引擎编辑器能够融入这个多窗口的工作生态，而不是独占整个屏幕。

但窗口系统征收了它自己的通用化税：深度功能的隐藏。在UnrealEd中，所有功能都暴露在固定的面板和菜单中，用户可以一层一层地深入查找。在Unity的浮动窗口系统中，功能可能被隐藏在某个被关闭的面板后面，或者被挤压到屏幕边缘的停靠标签里。

当一个用户需要调整物理材质的摩擦系数时，他需要知道这个设置在项目面板中选中物理材质后才会出现在检视器中——如果检视器窗口恰好被关闭了，这个功能就是不可见的。这种设计哲学反映了一个更深层的取舍：Unity 1.0不是为了服务那些需要引擎全部功能的高级用户而设计的，它是为了服务那些只需要引擎一小部分功能、但需要尽快找到并使用那一小部分功能的普通用户而设计的。功能的可见性被牺牲了，但常用操作的触达速度被提升了。

一个建筑师不需要知道引擎有物理材质系统，他只需要看到他的建筑模型在场景中正确渲染。当他有一天需要物理材质时，他可以去文档中查找如何打开检视器面板——但在他需要之前，那些功能安静地隐藏在幕后，不构成认知负担。

这三个设计决策——Mono脚本、拖拽导入、浮动窗口——共同构成了一套Ante、Helgason和Francis可能当时还没有明确命名的工具哲学。这不是事后追加的市场策略，而是从哥本哈根那些客户电话中生长出来的技术基因。

这套哲学的核心命题是：工具的力量不取决于它能服务的最复杂项目，而取决于能使用它的最普通的人。在引擎产业的发展史上，这套哲学代表了一次根本性的范式断裂。id Tech代表的是一种可以概括为源码精英范式的工具哲学——引擎是程序员写给程序员的，源码是最终的文档，修改引擎的能力是授权的核心价值。Unreal代表的是一种可以概括为中间件集成范式的工具哲学——引擎是一个集成好的生产管线，每个环节都有专业工具，授权方购买的是管线能力而非源码自由。

而Unity代表的，是一种可以概括为接入性范式的工具哲学——引擎是一个被设计用来降低准入门槛的创作环境，它的核心指标不是功能完备性，而是从零到第一个可运行结果的时间。这三种范式在2005年同时存在于引擎产业中，各自服务着不同的用户群，各自定义着不同的价值标准，各自承担着不同的技术代价。id Tech的代价是用户群狭窄——只有拥有顶级程序员的团队才能充分发挥源码授权的价值。

Unreal的代价是授权费用高昂——集成管线的开发和维护成本需要大规模的授权费来支撑。Unity的代价是性能和功能深度的妥协——Mono的托管运行时、自动导入的参数假设、浮动窗口的功能隐藏，每一项都在征收通用化税。这种税收在Unity 1.0中表现为一系列具体的功能缺失。不支持动态阴影——所有阴影都是烘焙到纹理上的，这意味着场景中的移动物体不会在地面上投射实时阴影。没有地形编辑器——创建室外场景需要手动放置平面模型，然后在上面贴纹理。网络功能极其简陋——多人游戏的同步逻辑需要开发者自己从底层实现。这些缺失在AAA引擎的评估标准下是不可接受的缺陷，但在Unity定义的目标用户群中，它们是可以被容忍的妥协。

一个建筑可视化项目不需要动态阴影——太阳的位置是固定的，阴影可以预先计算。一个独立小游戏可能根本不需要地形编辑器——它的场景是室内的，或者由简单的几何体构成。网络功能？大多数Unity 1.0的用户根本没想过要做多人游戏。

这就是接入性范式的完整面貌：它不是通过增加功能来服务更多用户，而是通过减少功能来降低准入门槛。这是一种在引擎产业历史上从未被认真尝试过的策略。之前的引擎竞争都是向着更强大、更完备、更专业的方向演进——更多的渲染特性、更复杂的物理模拟、更精细的动画系统。Unity 1.0逆着这个方向走了一步，然后问了一个问题：如果一个人只需要引擎百分之一的功能，他是否应该为了那百分之一而学习百分之百的工具链？在莫斯康展览中心那个不起眼的展台上，Ante用两分钟完成的演示给出了一个肯定的答案。

那个旋转的茶壶不是一个技术演示，它是一份关于工具哲学的政治宣言。它说：三维世界的创造权不应该只属于那些能够理解渲染管线、管理内存分配、编写着色器代码的人。它应该属于任何一个有想法的人，无论他是否知道什么是顶点缓冲，无论他是否能够解释Mipmap的原理，无论他是否理解垃圾回收机制对帧率的影响。这份宣言的载体不是文字，而是一个软件的价格标签和下载按钮。

Unity 1.0的授权费用被设定在一个让AAA引擎销售代表感到荒谬的低位——几百美元，而不是几十万美元。独立版的价格更低，几乎接近于消费级软件的定价。这不是一个临时的促销策略，而是接入性范式的经济表达：如果引擎的目标是让尽可能多的人能够使用它，那么价格本身就不能成为另一道门槛。Epic和id Software的授权模式——无论是管线费还是源码费——都建立在客户是专业游戏工作室的前提上，这些工作室有预算来支付高昂的授权费用，并且会将这笔费用计入项目开发成本。

Unity的定价建立在完全不同的前提上：客户可能是一个个人开发者，一个三人小团队，一个建筑事务所的视觉部门——他们不会将引擎授权费计入一个七位数预算的项目成本，因为他们的整个预算可能只有四位数。在WWDC演示结束后的几个月里，Unity 1.0的下载量开始以一种缓慢但稳定的速度增长。

下载者不是来自传统游戏开发中心的工程师——不是圣莫尼卡、不是达拉斯、不是伦敦的游戏工作室聚集区。他们来自斯德哥尔摩的小型设计公司，来自墨尔本的独立建筑事务所，来自东京的互动媒体学生，来自圣保罗的网页设计师。这些人之前从未出现在任何引擎厂商的客户画像中，因为他们根本不在游戏产业的版图上。他们不会参加游戏开发者大会，不会订阅游戏开发者杂志，不会在游戏引擎的论坛上发帖。他们只是需要一种工具，能够让他们把三维内容放到屏幕上，然后让这些内容动起来。

Unity 1.0进入了这些人的电脑，然后发生了一件在引擎产业历史上从未有过的事情：这些非传统用户开始制作游戏。不是因为他们突然学会了游戏开发，而是因为Unity 1.0没有要求他们学会游戏开发。拖入模型，写几行Mono脚本让东西动起来，调整摄像机角度，添加简单的碰撞检测——这些操作的门槛低到足以让一个没有任何游戏开发经验的人在几天内做出一个可以运行的原型。

然后他们把这个原型发给朋友看，朋友觉得有点意思，然后他们也下载了Unity。这是一种完全不同的扩散模式。id Tech的扩散依赖于技术声誉——卡马克写了一个新的渲染算法，整个行业都在讨论，然后那些拥有顶级程序员的团队决定购买授权。Unreal的扩散依赖于商业渠道——Epic的销售团队拜访工作室，展示引擎的功能清单，谈判授权条款。

Unity的扩散依赖于一种可以被称为可操作性感染的机制：一个人看到另一个人用Unity做出了东西，然后意识到自己也能做到，然后下载，然后做出东西，然后被下一个人看到。这种扩散模式在2005年看起来是缓慢而边缘的。Unity 1.0的用户基数在最初的几个月里以千为单位计算，而Unreal和id Tech的授权客户以工作室为单位计算——数量少但单笔交易金额巨大。

如果只比较营收数字，Unity在2005年几乎不构成竞争威胁。但接入性范式的真正力量不在于单笔交易的价值，而在于它打开的潜在用户池的规模。

在id Tech和Unreal争夺的那几百家专业游戏工作室之外，存在着数以万计——最终是数以百万计——的潜在三维内容创作者。他们不需要引擎提供最先进的渲染特性，他们只需要引擎让他们能够开始。这就是2005年6月在莫斯康展览中心发生的真正事件。它不是一个新产品发布，而是一个新用户群的发现。这个用户群一直被引擎产业忽视，不是因为产业傲慢，而是因为产业的基本经济模型建立在服务专业客户的前提上。Unity的三位创始人来自边缘地带，服务边缘客户，用边缘技术——Mac平台、Mono脚本、拖拽导入——构建了一个边缘产品。

但在这个边缘产品中，埋藏着一种即将在接下来十年中重塑整个引擎产业的力量：降低准入门槛本身，就是一种技术革命。

Unity 1.0发布时的支持平台列表精确地反映了它的边缘性：Mac OS X。只有Mac。在那个Windows占据游戏开发绝对主流的年代，选择Mac作为首发平台是一个看起来近乎自毁的决定。

但这不是选择，而是出身——Unity最初就是一个Mac平台的着色器工具，它的代码库从一开始就是为Mac OS X的OpenGL实现和Cocoa框架编写的。支持Windows需要重写整个渲染后端和窗口系统，这在Unity 1.0的资源约束下是不可能的。

但这个看似限制性的出身，意外地赋予了Unity一个独特的战略位置。在2005年，Mac平台的游戏开发工具几乎是一片空白。苹果公司对游戏的态度一直是矛盾的——它希望Mac上有好游戏，但不愿意投入资源构建游戏开发生态。这意味着Unity在Mac平台上几乎没有竞争对手。当一个Mac用户想要开发三维内容时，他的选择极其有限：要么使用价格昂贵的专业软件如Maya，要么使用功能简陋的开源工具，要么——在2005年6月之后——下载Unity。这个独特的战略位置让Unity在Mac开发者社区中迅速积累了一批忠实用户。

2006年，Unity在苹果设计奖中获得了最佳Mac OS X图形应用的亚军——这个奖项在技术圈的意义远大于在游戏圈的意义，但它精确地标记了Unity的用户群所在的位置。他们不是游戏开发者大会的参会者，他们是苹果全球开发者大会的参会者。他们关心的不是三角形吞吐量，而是用户体验设计。他们衡量工具的标准不是功能列表的长度，而是从安装到第一个产出的时间。

当Unity在2009年3月通过2.5版本加入对Windows的支持时，它在Mac平台上已经积累了将近四年的用户基础和口碑。这四年的边缘生存期——在产业主流视野之外，在AAA引擎的竞争雷达之下——让Unity完成了一件不可能在正面竞争中完成的事情：它验证了接入性范式的市场可行性。当它最终进入Windows平台时，它带来的不是一个功能更强大的引擎，而是一种已经被验证的工具哲学和一个已经成型的用户社区。而产业的主流正在第七世代的熔炉中燃烧。

Xbox 360已经在2005年11月发布，PlayStation 3即将到来，AAA游戏开发的预算正在突破两千万美元的门槛。在那个世界里，引擎的选择是关于生存的计算——用金钱换时间，用管线换确定性，用授权费换技术支持。

Unity不在那个世界里。它在另一个世界里，一个由独立开发者、学生、设计师和梦想家组成的世界。在那个世界里，引擎的选择是关于可能性的计算——用简单换取开始，用限制换取理解，用边缘换取自由。这两个世界在2005年还几乎没有交集。但它们已经同时存在了。

引擎产业的版图已经被永久地改写——不是由一场正面的技术对决，而是由一份来自边缘地带的宣言。这份宣言没有宣布任何技术突破，没有展示任何前所未有的渲染效果，没有声称任何性能记录。它只是做了一个拖拽动作，让一个茶壶旋转起来。

然后它留下了一个问题。这个问题不是关于技术路线或市场份额的预测，而是一个更根本的追问：当制造三维世界的工具变得足够简单时，谁来制造三维世界？

2005年6月的Unity 1.0没有回答这个问题。它的下载量还在以千为单位缓慢增长，它的功能列表上还排列着一长串缺失项，它的三位创始人还在哥本哈根的一间小办公室里处理客户支持邮件。但这个问题的提出本身，已经改变了引擎产业的基本参数。从此以后，任何关于下一代引擎的讨论都不能仅仅考虑它能让顶尖团队做什么——还必须考虑它能让一个从未写过游戏代码的人做什么。这个新参数将在接下来的岁月里持续发酵，直到它从边缘地带涌入产业的核心。