云端的幻象

旧金山，GDC特别活动的圆形剧场。环形屏幕环绕着观众席，每一块屏幕都在播放同一个画面：一台Chromebook、一部Pixel手机、一台连接了Chromecast的电视，三块屏幕上运行着同一个《刺客信条：奥德赛》的存档。Google副总裁Phil Harrison走向舞台中心，背后的环形屏幕切换成一组数字——10.7 teraflops。这个数字超过了当时PS4 Pro和Xbox One X的算力总和。Harrison随后描述了Stadia的技术承诺：玩家在任何屏幕上点击“Play”按钮后五秒内即可进入游戏，无需下载，无需安装，无需等待补丁更新。他的措辞指向一个明确的结论——数据中心将取代游戏主机，成为玩家的下一台游戏机。三年零两个月后，2023年1月18日，同一家公司、同一位高管在Google官方博客上发表了一篇题为《关于Stadia的消息》的声明。

全文不到五百字，核心段落说明Stadia的技术基础虽然强大，但未能获得预期的用户吸引力，因此公司做出了关闭流媒体服务的决定。Google承诺退还所有硬件和软件购买费用，Stadia服务器于当天午夜正式关闭。没有发布会，没有告别活动，只有一篇博客文章。这两个场景之间的张力，构成了2019至2024年间云游戏实验的核心戏剧。Stadia试图将游戏引擎完全封装在云端，切断与本地硬件的所有联系，从而也切断了与既有游戏生态的所有兼容性。

这一模式的失败，迫使整个引擎产业开始面对一个此前被忽视的问题：当渲染与逻辑在云端完成、只有视频流抵达终端时，引擎的架构本身会发生什么变化？要理解Stadia的技术雄心，需要回到Google启动这个项目的时间点。2018年，Google在内部测试了代号为“Project Stream”的技术验证项目，允许测试用户在Chrome浏览器中串流游玩《刺客信条：奥德赛》。

测试期间收集的数据让Google的工程师们相信，他们已经解决了云游戏的核心技术难题——延迟。Google的解决方案依赖于两个基础架构：一是遍布全球的边缘节点网络，二是专门为游戏串流设计的视频编码管线。传统的视频串流存在一个结构性矛盾：编码器为了压缩视频流需要缓存若干帧画面，但这会增加延迟；

如果减少缓存以提高响应速度，压缩效率就会下降，画质随之劣化。Google的工程师们设计了一套自适应编码系统，可以根据网络状况动态调整缓存帧数和压缩参数，在延迟和画质之间寻找实时最优解。这套系统在测试阶段表现良好。参与Project Stream测试的玩家反馈，在稳定网络环境下，《刺客信条：奥德赛》的串流体验与本地运行几乎没有可感知的差异。Google据此判断，云游戏的技术条件已经成熟。

2019年3月，Google在GDC上正式宣布了Stadia平台，并公布了更多技术细节：Stadia的服务器节点配备了定制GPU，每个实例提供10.7 teraflops的浮点运算能力；Google的全球边缘网络拥有超过七千个节点，可以确保大部分用户与服务器的物理距离在光纤传输的合理范围内；Stadia控制器通过Wi-Fi直接连接到Google服务器，而非连接到本地设备，从而绕过了蓝牙或USB的额外延迟。从纯技术角度看，Stadia的架构设计是自洽的。

问题出在技术之外。第一个致命误判是对延迟物理极限的低估。光在光纤中的传播速度约为每秒二十万公里，这意味着一千公里的物理距离本身就意味着至少五毫秒的单向延迟，来回就是十毫秒。加上路由跳转、编码解码、输入处理，即使在最优条件下，Stadia的总延迟也很难降到七十毫秒以下。对于回合制游戏或叙事驱动游戏，这个延迟水平是完全可以接受的。

但对于第一人称射击游戏、格斗游戏或竞速游戏——这些恰恰是游戏产业中用户基数最大的品类——七十毫秒的延迟意味着玩家在按下扳机后，画面需要额外一帧以上的时间才能反映这个动作。职业玩家和硬核玩家对这类延迟极度敏感，而他们恰恰是早期采用者和口碑传播的关键群体。Stadia发布后，Digital Foundry等专业评测机构的数据很快揭示了这个问题：在同一款《命运2》中，Stadia的输入延迟比Xbox One X高出约四十到五十毫秒，比高端PC也是高出六十毫秒以上。这些数字在Reddit和游戏论坛上被反复引用，成为Stadia难以摆脱的技术标签。第二个误判是对玩家心理的误读。Google假设玩家愿意为“即时可玩”的便利性放弃对游戏文件的物理拥有。

但这个假设忽略了一个深层事实：在过去四十年里，游戏产业已经培育出一种特定的消费文化——玩家购买游戏，游戏文件存储在本地硬盘上，这是一种所有权的象征，即使这种所有权在数字分发时代已经变得越来越虚幻。Steam的用户协议早已明确告知玩家，他们购买的不是游戏本身，而是一份不可转让的使用许可。但在心理层面，看到游戏文件躺在自己的硬盘里，与仅仅拥有一个云端串流的入口，是两种截然不同的体验。Stadia要求玩家为每一款游戏单独付费——这与Netflix式的订阅制不同——但付费后玩家获得的只是一个串流权限，无法下载，无法离线游玩，无法转售。

当Google关闭Stadia时，玩家的游戏库将彻底消失，连一个可执行文件都不会留下。这种“购买即租赁”的模式在音乐和影视行业已经通过Spotify和Netflix被广泛接受，但游戏产业的消费文化与音乐影视存在显著差异：游戏玩家平均每款游戏的投入时间远超一部电影，他们对游戏库的情感依附也更为强烈。

第三个误判——从引擎产业的角度看，这是最致命的一个——是对开发者移植成本的严重低估。Stadia运行在基于Linux的定制操作系统上，使用Vulkan作为图形API。这意味着任何想要登陆Stadia的游戏都需要进行专门的移植工作，而不能直接使用现有的Windows版本。Google为吸引开发者加入，投入了大量资金购买独占内容和首发权——据称，Google为《荒野大镖客：救赎2》等大作的Stadia版本支付了数千万美元的移植和授权费用。但这种方式是不可持续的。

对于中小型开发商而言，为一个用户基数尚未建立的新平台投入移植资源，是一笔难以承受的赌注。而大型发行商虽然有能力进行移植，但他们在Stadia上的游戏销量远不足以覆盖成本。Stadia陷入了典型的平台冷启动困境：没有足够的游戏内容吸引用户，没有足够的用户基数吸引开发者。Stadia的这一困境与游戏引擎产业的既有格局产生了直接冲突。

自2010年代以来，Unreal Engine和Unity已经建立了一套高效的跨平台部署管线：开发者在同一个引擎中构建游戏，然后一键导出到PlayStation、Xbox、Switch、PC、iOS和Android。这套管线的核心价值在于让开发者只需构建一次，就能将游戏部署到各个平台——虽然实践中每个平台都需要适配工作，但引擎承担了大部分的抽象层工作。Stadia要求开发者在现有的跨平台管线之外，额外维护一个Linux/Vulkan版本，这在经济上等同于回到了平台割裂的旧时代。Google试图通过将Stadia定位为引擎跨平台支持列表中的又一个目标平台来融入现有体系，但引擎厂商的反应是冷淡的。Unreal Engine在4.24版本中加入了Stadia支持，Unity也提供了Stadia构建选项，但这些集成的深度和优化程度远不及引擎对PlayStation或Xbox的支持。

引擎厂商在观望：他们不会为一个尚未证明市场价值的平台投入大量工程资源。2021年2月，Google宣布关闭Stadia的第一方游戏开发工作室——Stadia Games and Entertainment。这个工作室由前育碧和EA高管Jade Raymond领导，原本负责为Stadia开发独占游戏，以弥补平台内容的不足。关闭的消息在游戏开发者圈内引发了震动：如果Google自己都不愿意继续投资Stadia的独占内容，第三方开发商为什么要投入移植资源？从这一刻起，Stadia的死亡进入了倒计时，尽管平台本身又继续运营了近两年。当Stadia在2023年1月正式关闭时，产业界的反应不是震惊，而是一种早有预感的平静。但Stadia的失败并非云游戏的失败——这是一个关键区别，也是本章论证的核心关节。

与Stadia的“全云端”模式形成对照的，是NVIDIA GeForce Now的“薄客户端”路线，后者在Stadia关闭后继续稳步增长，证明了云游戏的另一种可能性。GeForce Now最初于2015年以NVIDIA Grid的名义推出，2017年更名为GeForce Now，2020年正式结束测试进入商业运营。与Stadia的根本区别在于：GeForce Now不试图创造一个新的游戏平台。它不卖游戏，不经营自己的数字商店，不要求开发者进行任何移植工作。GeForce Now的工作方式是将玩家已有的Steam、Epic Games Store和Ubisoft Connect游戏库流式传输到任意屏幕上。玩家在GeForce Now中登录自己的Steam账户，看到的是自己已经拥有的游戏列表，点击即可开始串流。

引擎仍然运行在标准PC架构上——Windows操作系统、DirectX或Vulkan图形API、NVIDIA GPU——只是物理位置从玩家桌下的机箱移到了数据中心里的机架上。这条路线解决了Stadia面临的三个核心问题。延迟问题虽然依然存在，但GeForce Now通过将服务器节点部署在更靠近用户的位置来压缩物理距离——NVIDIA在全球部署了超过三十个数据中心区域，每个区域覆盖的地理范围远小于Google的通用边缘节点。平台冷启动问题被巧妙地绕过了：GeForce Now不需要说服开发者为新平台移植游戏，因为游戏本来就是PC版本。

玩家所有权的问题也得到了缓解：玩家购买的游戏仍然存在于他们的Steam库中，GeForce Now只是一个访问工具，即使NVIDIA明天关闭服务，玩家的游戏库不会消失。但GeForce Now的生存——如果“稳步增长但远未成为主流”可以称为生存的话——恰恰凸显了Stadia失败的深层原因。

Stadia试图改变的不只是引擎运行的位置，而是整个游戏产业的生态结构。它试图成为游戏界的Netflix——一个全新的分发平台，有自己的商店、自己的社交系统、自己的独占内容。这个野心的代价是必须同时解决技术问题、内容问题和用户习惯问题，而这三个问题中的任何一个都足以让一家公司耗尽资源。GeForce Now放弃了平台野心，只专注于解决技术问题——如何高效地将渲染画面从数据中心传输到终端设备——而将内容和用户关系留给已有的Steam生态。微软的Xbox Cloud Gaming则采取了介于Stadia和GeForce Now之间的第三条路线。它有自己的内容库——Xbox Game Pass Ultimate订阅服务包含的游戏——但这些游戏不需要单独移植，因为它们本来就是Xbox版本，运行在微软数据中心的Xbox Series X硬件上。

2020年9月正式上线后，Xbox Cloud Gaming逐步扩展了支持设备范围，从Android到iOS到PC到Xbox主机本身。微软的策略是将云游戏定位为Game Pass订阅的附加功能，而非独立的平台。玩家订阅Game Pass是为了游戏库，云串流只是访问这个库的多种方式之一。这种定位使得Xbox Cloud Gaming不需要单独证明自己的商业可行性——它的成本被分摊到整个Game Pass生态中。当Stadia关闭的消息传来时，Xbox Cloud Gaming负责人Sarah Bond在接受采访时将云游戏描述为一种分发方式，而非一种商业模式。这句话精准地概括了Stadia失败的根源：Google试图将云游戏本身作为一种商业模式，而成功的玩家——NVIDIA和微软——将云游戏视为已有商业模式的一种补充分发渠道。

但这三条路线——Stadia的全平台模式、GeForce Now的薄客户端模式、Xbox Cloud Gaming的生态附加模式——在2023年之后都不再是产业讨论的焦点。Stadia的关闭引发了一个更深层的问题，这个问题不再关乎谁赢得了云游戏的订阅用户，而是关乎引擎架构本身。当渲染与逻辑在云端完成、只有视频流抵达终端时，引擎的架构会发生什么？

这个问题在Stadia存续期间几乎没有人认真思考过。Stadia和GeForce Now运行的都是标准版本的引擎——Unreal Engine、Unity、或各发行商的自研引擎——这些引擎在设计时假设渲染和输入处理发生在同一台设备上。但在云游戏场景下，渲染发生在数据中心，输入发生在终端设备，两者之间隔着一条延迟不可预测的网络链路。现有的引擎架构通过将整个游戏循环放在云端、终端只负责解码视频流和上传输入信号来适应这种分离，但这是一种粗暴的适应，而非架构级别的重新设计。

2023年，Stadia关闭后，一些引擎工程师开始在GDC演讲和技术博客中讨论一个此前被忽视的概念：“云原生引擎”。这个概念的出发点是一个简单但深刻的观察：如果引擎明确知道自己运行在云端、渲染结果通过视频流传输到终端，那么引擎的架构可以裂变为两层——云端负责重渲染，终端负责轻交互。在传统的本地引擎架构中，渲染线程和游戏逻辑线程紧密耦合在同一台设备上，共享同一块内存空间。引擎每一帧的工作流程是：处理输入、更新游戏状态、提交渲染指令、GPU执行渲染、输出到显示器。这个流程假设了从输入到显示的全链路延迟不超过一帧的时间——在六十帧每秒的游戏中，这个预算大约是十六毫秒。

但在云游戏场景中，输入信号需要先传输到数据中心，渲染完成后再将视频流传输回来，全链路延迟轻松超过五十毫秒。这意味着引擎在云端渲染的画面，对应的是玩家在五十毫秒前发出的输入——而在这五十毫秒内，玩家可能已经发出了新的输入，游戏状态可能已经发生了变化。

解决这个问题的一种思路是让终端设备承担部分轻量级的交互渲染。如果引擎可以将某些对延迟敏感的渲染任务——例如UI指针的移动、菜单的高亮反馈、准星的微调——下放到终端设备上执行，而将重度的场景渲染留在云端，那么玩家感知到的交互延迟将大幅降低，因为终端渲染的UI元素可以直接响应本地输入，无需等待云端往返。这种架构裂变要求引擎将渲染管线拆分为两个可以异步协作的部分：云端管线负责场景、角色、特效的渲染，终端管线负责UI层和输入反馈的渲染。两者通过视频流合成在终端屏幕上呈现为一帧完整的画面。

这种思路在2023年还停留在概念验证阶段，但它指向了一个根本性的变化：如果引擎架构真的裂变为云端和终端两层，那么引擎与硬件之间的契约将被彻底改写。自引擎产业诞生以来，引擎与硬件的关系建立在一条默认规则之上：渲染发生的设备与输入接收的设备是同一台设备。引擎的性能优化、内存管理、线程调度都围绕这条规则展开。

云游戏裂变了这条规则——渲染设备与输入设备不再同一，它们之间隔着网络。GPU不再是一块插在玩家桌下机箱里的显卡，而是数据中心里一个可弹性调度的计算资源池。这个变化如果实现，将是引擎产业三重契约中最深刻的一次断裂。在本书此前追踪的历史中，引擎与硬件的契约经历过多次调整：从id Tech时代针对特定显卡的深度优化，到UE3时代面向多核处理器的线程重构，到Unity在移动GPU瓦片架构上的底层层重写。但这些调整始终没有改变一个基本前提：引擎运行在玩家的设备上。

云游戏实验——包括Stadia的失败——将这个前提本身变成了一个可选项。而引擎厂商的商业模式也将随之面临压力。如果引擎不再以二进制库的形式分发到开发者的工作站和玩家的设备上，而是以服务的形式运行在云端，那么传统的授权模式将变得不再适用。Unreal Engine向游戏开发者收取的版税，Unity按订阅层级收取的引擎授权费，都建立在引擎运行在每一台玩家设备上这个前提之上。

在云游戏场景中，引擎的一份实例可以同时服务多个玩家——通过多用户共享GPU资源池——或者反过来，一个玩家可以按需调用多个引擎实例——通过分布式渲染处理超出单GPU能力的场景。无论哪种情况，引擎的使用计量单位都将从安装量或运行时实例转变为渲染计算时长或GPU占用时间。引擎厂商的商业模式将从卖工具授权转向卖渲染计算服务。

这个转向的轮廓在2023年已经隐约可见。Epic Games在2020年收购了实时渲染服务公司Cubic Motion和3Lateral，随后推出了MetaHuman Creator——一个运行在云端的数字人类创建工具，用户通过浏览器访问，渲染在Epic的服务器上完成。Unity在2022年推出了Unity Gaming Services，其中包括云构建、云托管和多人游戏服务。这些举措虽然在当时被解读为引擎厂商向服务化转型的商业策略，但在Stadia关闭后，它们被重新审视：这些云端服务是否构成了某种云原生引擎的雏形？

引擎厂商是否已经在为架构裂变做准备？这些问题的答案在2024年仍然悬而未决。Stadia的幻灭留下了一个真问题：当引擎不再运行在本地设备上时，引擎产业将如何重组？这个问题不会随着Stadia的关闭而消失，因为云游戏本身并没有消失——GeForce Now和Xbox Cloud Gaming的用户基数在持续增长，网络基础设施在持续改善，玩家对“即时可玩”的需求在持续累积。

Stadia的失败只是证明了一种特定的云游戏模式行不通——试图用封闭平台取代开放生态的模式。但云游戏作为一种技术可能性，已经不可逆转地进入了引擎产业的视野。从引擎产业的历史视角回看，Stadia的幻灭与GeForce Now的生存构成了一对镜像：前者试图用云端的算力碾压本地硬件的局限，却低估了生态兼容性的引力；后者放弃了算力碾压的野心，转而将云端作为本地生态的延伸。

这对镜像共同揭示了一个事实：在引擎产业中，技术突破从来不足以单独定义“下一代”——它必须与开发者的移植成本、玩家的心理习惯、以及既有的生态结构达成某种妥协，才能从实验室走进市场。Stadia的技术没有失败，失败的是它对产业生态的误读。当Phil Harrison在2023年1月的那篇博客文章中写下“艰难决定”这个词时，他代表的不仅是Google的一次战略撤退，也是一种技术理想主义的退潮——那种认为数据中心可以取代一切本地设备的乐观主义，在延迟的物理极限和生态的惯性面前撞上了边界。

但这个理想主义退潮后留下的滩涂上，出现了一个更冷静、也更棘手的问题：如果引擎不再是一台设备上的软件，而是一种分布在云端和终端之间的计算服务，那么引擎产业的三重契约——渲染范式、工具哲学、硬件契约——将如何被重新谈判？这个问题不会随着Stadia的关闭而消失，因为计算位置的分配——在云端还是本地——正在成为引擎产业面临的结构性选择。