# 蒂姆·斯威尼：堡垒之夜、虚幻引擎与游戏的未来

> Epic 创始人回顾虚幻引擎与堡垒之夜的历程，谈游戏技术演进、平台生态与行业的下一步。

- 原标题：#467 – Tim Sweeney: Fortnite, Unreal Engine, and the Future of Gaming
- 期数：第 467 期
- 发布日期：2025-04-30
- 嘉宾 / 主题：蒂姆·斯威尼
- 网页版：https://lex.qiaomu.ai/ep/tim-sweeney/
- 官方页面：https://lexfridman.com/tim-sweeney/
- 精读字数：约 19252 字（阅读约 43 分钟）

> 本文为 lex.qiaomu.ai 基于原始访谈的 AI 改写中文精读，非官方翻译；引用请注明出处并链接网页版。

1991 年，一个刚从马里兰大学毕业的年轻人把自己做的游戏刻进软盘，上传到本地几个公告板系统（BBS）。几天后，支票从全美各地寄来，一天三四张，每张 30 美元。再过一个多月，订单来自世界各地。

这个人叫蒂姆·斯威尼（Tim Sweeney），这家公司后来叫 Epic Games。那款游戏叫 ZZT，它最初的原型，是一个他嫌无聊、顺手改成游戏的文本编辑器。

三十多年后，Epic 的旗舰产品《堡垒之夜》（Fortnite）月活用户达到 1.1 亿，年收入以十亿美元计。Epic 在法庭上和苹果、谷歌打了五年官司，争议围绕一句话展开：30% 的抽成到底合不合理。

这场对话覆盖了斯威尼从 11 岁第一次摸到 IBM PC 到今天的全部主线：虚幻引擎五代演进、《堡垒之夜》四周成型、Verse 语言为什么敢重写编程语言的地基、苹果为什么是错的，以及一个他反复回到的问题：游戏靠什么让人留下来。

## 一万五千小时，和一个被改造成游戏的文本编辑器

斯威尼有个比他大 16 岁的哥哥，在加州一家科技公司上班，买了最早一批 IBM PC。他 11 岁那年暑假飞去加州找哥哥玩，几天之内学会了 BASIC。“我对当时电脑能做的事情感到震撼，从那一刻就被钩住了。”

他说自己对人的名字记得很差，代码却记得极清楚。第一次学编程的每一步、每个卡壳的地方，到现在都历历在目。回头看，其中一部分源自编程语言设计的缺陷，跟学习一门新手艺的难度无关。

这个判断影响了他此后三十年的工作：他后来自己写编程语言、写编译器，最近还在主导 Verse 的设计。

10 岁到 20 岁之间，他在完全独自的状态下写了大概 1 万到 1.5 万小时代码，然后才第一次把软件发布给外面的世界。第一款游戏是在 Apple II 上做的：屏幕上飞过一串星号，右边有个括号像棒球手套，你要接住星号。做了几个小时。

他还做过数据库、写过一门类似 Pascal 的语言和一整套编译器，因为当时不知道去哪买一个。也花了很多时间做 BBS 程序，处理数据库、用户界面、多用户并发。每个镇上都有几百个这样的公告板，各有各的站长和主题。

关于这段经历的价值，他的说法很直接。小时数只是一个数字，真正起作用的是他在不断做实验、做项目，搞清楚自己会什么、不会什么。1991 年发布第一款游戏，十年后做到第一代虚幻引擎，中间全靠这十年业余项目积累的知识。没有那段时间，后面的事一件都做不成。

## 工程师学位没白读，只是用处来得很晚

斯威尼在马里兰大学读机械工程。他说那所学校对某些专业来说像个派对学校，工程院系却把学生往死里练。向量微积分、矩阵、物理、应力和应变，学的时候完全不知道工程师实际会怎么用这些东西。

直到他开始写第一代虚幻引擎，处理 3D 数学的时候，才反应过来：这些我学过。

> “就像《龙威小子》里那样，你先去刷篱笆、给车打蜡，然后突然之间，所有碎片拼成了一个 3D 引擎。”（蒂姆·斯威尼）

他后来回去翻工程教材，一路看下去都是“这个我用过、这个我用过”，直到翻到特征值那一章，完全不认识。特征值和特征向量恰恰是 Google 搜索引擎技术的关键突破：把全网所有链接关系放进一个巨大的矩阵，求出主特征值，对应的特征向量就描述了最佳搜索结果。

他对上大学的看法很锋利。很多人以为上大学的目的是拿高分、拿文凭、向雇主证明自己的价值。那只是学校这套系统的记账方式。真正有价值的是学到的东西，尤其对创业者来说，管用的是你真会什么，你手里有没有那张证书反而次要。

他还提到一个正在消失的东西：童年的自由时间。他小时候母亲管早饭，邻居家的妈妈管邻居孩子的早饭，然后一句“天黑前回来”，就放出去了。一帮小孩在树林里探险、造卡丁车、拆旧电器拼成假飞船的控制面板。那种大量的、无人管束的时间里，有人看电视浪费掉了，有人搞出了正经项目。

他觉得美国社会越来越保护孩子、越来越结构化，正在把这种经验挤掉。

## 玩游戏的目的是为了学会怎么做游戏

斯威尼对游戏的感情很特别。他真正的志向一直是写很酷的程序，编程给他带来的快乐超过世界上任何事。

他最早沉迷的两款游戏，一个是 Atari 2600 上的《Adventure》，一个光点在屏幕上移动，捡剑、打龙、攻城堡、解谜，极其简单但极具标志性；另一个是文字冒险游戏《Zork》，没有画面，全靠打字，“往北走”“捡起剑”“开门”，但脑子里会生成一幅极其精细的画面。

这两款游戏把他推向了编程。他学会了怎么让角色在屏幕上移动，怎么做一个关卡编辑器，把城堡建好、保存、再放进游戏里玩。他很早就意识到工具和游戏是两件事，工具越强，自己能释放的创造力、别人能释放的创造力就越大。

> “在《堡垒之夜》出来之前，我玩游戏主要是为了搞清楚他们在做什么，然后自己去做一遍。”（蒂姆·斯威尼）

《德军总部 3D》（Wolfenstein 3D）出来他逐像素看，《毁灭战士》（Doom）出来他轻轻挪动鼠标，看屏幕上到底发生了什么变化，反推用的是什么技术。他把这形容成一场规模宏大的解谜。

## 被 Doom 打击到停写代码半年

《德军总部 3D》让 Epic 意识到游戏的未来是 3D。真正让斯威尼崩溃的是《毁灭战士》。

> “一开始我非常沮丧。Doom 的巫术太惊人了，我半年没写代码。我觉得我永远比不过这个。”（蒂姆·斯威尼）

他说卡马克（John Carmack）做到的，是十几个创新同时发生、互相咬合，你根本没法把它们拆成零件来看，单点领先反倒谈不上。

转折点是 Michael Abrash。这位图形学老将写了一本书讲 3D 图形和纹理映射的技术，还在当时的编程杂志上发文章，附上做纹理映射的汇编代码。斯威尼一看，其实很简单，“哦，这个我能做”。

Epic 内部几个人各自去写自己的 3D 图形代码，后来发现有好多人在分头啃不同的部分，于是决定 all in。他们把最好的 2D 团队抽出来组成一个 3D 团队，谁也没做过 3D 游戏，边学边干。

分工的细节很有意思。斯威尼最初自愿做 3D 编辑器。James Schmalz 做过《Epic Pinball》，那款游戏是他在大学期间做的，每月版税三万美金，代码是三万行汇编。Schmalz 本来要写 3D 引擎、斯威尼写编辑器，Schmalz 把自己的代码发过来准备对接，斯威尼看了一眼那堆汇编，说，算了，还是我自己写吧。Schmalz 转去做 3D 模型和动画。Cliff Bleszinski（就是后来《战争机器》的设计者）成了编辑器的第一个用户，开始学着搭关卡。

《虚幻》（Unreal）开发高峰期大约 20 人，在当时是超大团队，把 Epic 的财务拉到了断裂边缘，好几次差点没钱。

这个项目做了三年半，而他们始终觉得“还有六个月就能发”。三年半里大部分人每周工作 70 到 80 小时，而且因为完全陷在眼前的问题里，根本不知道下一个要解决的问题是什么。

## 30 小时不睡，把 CSG 做进实时引擎

虚幻引擎第一代在技术上走得比 Quake 远的地方之一，是用构造实体几何（CSG）在实时编辑器里搭场景。

逻辑很朴素：如果你只能往世界里加物体，想开一扇门就得拼十几块门框和墙，还得对齐。但如果能从一堵墙上减掉一扇门，就简单太多了。加几何、减几何，引擎负责算。

这个想法他想了很久，真正动手时，花了连续 30 个小时把所有的特殊情况处理完。

做完第二天他拿给 Schmalz 看：先建一个巨大的圆环，再加一个交错的圆环，然后减掉一个圆柱，三次操作做出一个非常复杂的复合物体。Schmalz 说，你这是作弊吧。

> “那大概是第一次有人在实时环境里做构造实体几何。”（蒂姆·斯威尼）

关于那 30 小时，他给了一个挺有意思的解释。人的大脑算力远超我们直接调用“下一行代码写什么”时的水平。长时间工作之后进入睡眠剥夺状态，短期记忆受损，反而失去了对自己刚写完的代码的快速回想能力，于是大脑被腾出来去想别的问题。

技术底子是二叉空间分割树（BSP tree）。这个数据结构由图形学研究者 Bruce Naylor 提出，卡马克在 Doom 里用出了极好的效果。斯威尼想到的是：有了 BSP 树，就有一种非常高效的做 CSG 的方法。他把几何体之间可能的组合拆成 14 种情况，大部分很简单，直接写。难的是共面多边形：同一个平面上、朝向相同和朝向相反的情况，什么时候该保留、什么时候该剔除。主要靠推导，也有一部分是试出来的。

他说写一个 99% 正确的软件很容易，难的是那 1%。

## 体积雾：从机械工程课本里翻出来的积分

光照是另一个坎。物理定律是已知的，所以计算机图形学里“做对”很容易，“做快”才是全部难点。直接求解物理定律慢得离谱，需要的是快上百万倍的近似。

当时 CPU 上每个像素的纹理映射已经压到 6 个时钟周期，再花 30 个周期算光照根本不可能。卡马克在 Quake 里用的是光照贴图（lightmapping）：不逐像素算光照，改成每隔一英尺算一个光照值，再线性插值。

虚幻引擎在这个基础上做了彩色光源。因为光照贴图按空间采样，不按像素采样，每个点其实有几百个周期的预算可以挥霍。于是火把闪烁、水面反射的焦散、脉冲光、闪烁光，全都做了出来，还写了一套把任意数量光源合成起来的系统。

然后他实现了阴影：从光源向表面上的点发射线，看是否被其他几何体挡住。实时版本跑起来是每秒半帧。他顶着半帧的速度到处跑、发射光弹、看动态光照，心想，总有一天电脑会快到能实时跑这个，但不是今天。于是做了预计算版本，发现只要光源不动，阴影可以预计算、光照仍然可以动态施加，火把闪烁带阴影就成了。

体积雾的来历更戏剧。芬兰一家图形硬件公司放出一张截图，一个充满雾气的房间里有几个光源，光把周围的雾照亮，形成光晕，随距离衰减。那种效果极其迷人，像雾夜路灯下的街道。

斯威尼看到的第一反应是：他们做出了实时体积雾，我得自己搞明白。又一个 30 小时。

核心是：光的强度随距离平方反比衰减，这是牛顿那套。雾与光的相互作用，是沿着从眼睛到表面上某点的视线累积雾中被照亮的量。线积分，就是这个。

> “我在机械工程里学过这个，当时完全不知道学它有什么用。”（蒂姆·斯威尼）

他推了一通数学，然后去翻积分表，发现这种形式除以 R 平方的积分，解是 R 的反正切。根据眼睛位置和表面点位置算出几个参数，就能精确算出这段路径上累积了多少雾。当然不能逐像素算，那是几百个周期。他们把体积雾按每平方米一个值来算，性能刚好够，然后交给美术。

很多年后他跟那家硬件公司的一位工程师聊起这事，说你们的体积雾启发了我在实时里把它做出来。对方说：哦，我们作弊了，那个是 3ds Max 渲染出来的。

## 卡马克身上值得学的一件事

斯威尼对卡马克的评价集中在一点：对“从自己代码里榨出最好结果”的极度执着，以及对旧代码毫无感情。

> “他那些传奇成果，都不是第一次尝试。是第七次、第八次。做一遍，发现更好的方法，把旧的扔掉，重写，一直重写到找到最优解。”（蒂姆·斯威尼）

他把这当成给所有程序员的教训：当某件事的性能、质量或能力对产品真的至关重要时，就一直迭代到完美，别满足于第一个或第二个够用的方案。

## 三十年，GPU 性能涨了一千万倍

从虚幻引擎 1 到 5，硬件性能涨了大约十万倍的 CPU 算力（多核加高频加并行），GPU 可用性能涨了大约一千万倍。斯威尼的比方是：航空业如果有这个增速，我们已经在去隔壁恒星的路上了。

有意思的是引擎内部各模块的演进速度差异极大。渲染代码几乎每一代都被重写大半，团队里不断有人做出为新硬件彻底重新设计的系统。有些部分从 1998 年那个版本一直沿用至今：文件管理系统优化过很多次却始终没被彻底重想，网络系统里客户端和服务器协商游戏状态的机制还是当年那套的演化版。

> “你在《堡垒之夜》里还能看到网络 bug，比如观战时某些参数不更新，那就是这套网络模型丢包特性造成的。”（蒂姆·斯威尼）

最大的历史包袱是游戏模拟的单线程。16 核 CPU 里，游戏逻辑只用一核。原因很实在：单线程编程比多线程简单几个数量级，他们不想把多线程的复杂度压给自己、合作方和社区。这个限制随着时间越来越痛，虚幻引擎 6 的核心目标之一就是解决它。

## Nanite 为什么要绕过 GPU 的三角形光栅化硬件

今天的艺术工具很容易就能做出几十亿个多边形的场景，难的是怎么高效渲染。目标是渲染出一张和全精度渲染无法区分的图像，成本要低到实时。

理论基础是奈奎斯特采样定理：重建一个信号时，采样数存在上限。渲染一个物体时，每像素两个三角形就足够和每像素几千个三角形无法区分；低于两个，就开始出现可见的失真。

问题出在 GPU 的三角形光栅化硬件是为“比较大的三角形”设计的。一个三角形覆盖 10 个像素时效率不错，只覆盖 1 个像素时效率极差。而近景细节恰恰需要大量微小三角形。

Brian Karis 的突破是：设计一整套管线绕开光栅化硬件，直接用像素着色器，通过光线求交计算每个像素该是什么，走像素管线，绕开三角形管线，结果反而更好。

另一个难题是“跳变”（popping）。早期算法跑着跑着切换三角形密度，画面会像被抖了一下，非常干扰。Nanite 的关键取舍之一，就是把切换压到统计上存在、人眼基本感知不到的程度。

斯威尼在这里插了一句关于“失去的手艺”的感慨。90 年代一个程序员能完全理解 CPU 底下在发生什么，能精确针对它写代码，把纹理映射压到 6 个周期、11 条指令。现在 CPU 的乱序执行太复杂，你只能管理代码的整体性能，没法逐指令微操。不过他说这门手艺在 GPU 和 ASIC 上还活着，Nanite 就是一次持续多年的、从最高层到最底层的优化工程。

## Lumen：让光在每一个尺度上都不出现接缝

Lumen 做的是全局光照，也就是模拟光在整个场景里的多次弹射。第一代引擎的做法是：光源照到的地方亮，没照到的地方黑。现实里光会到处弹：红光打在红墙上，红墙把红光弹到白地板上，地板就泛红。

物理定律在 1950 年代就已经写清楚了，难点在算力。Daniel Wright 做了十年，提出一个当时颇有争议的判断：只要光照计算的层级足够多，就能让全局光照在所有尺度上同时成立，从建筑投影这种大尺度，到泥土表面这种细节，层级之间看不出接缝。

实机演示里有一段是冰面与泥土之间极其细致的阴影互相作用。斯威尼解释，其中一部分是屏幕空间的技术：阴影计算基于屏幕上的像素，世界坐标派不上用场，那是唯一能在像素着色器上算得足够快的方法。他第一次听人解释这个原理时的反应是“这很聪明，但我觉得不会 work”，然而它确实 work，因为根据入射光的位置和屏幕上不同像素的深度，可以推断出这块几何体大概会遮挡哪些其他几何体。只是近似，对 iPhone 用户的 CG 眼来说也许不够，可人眼完全买账。

演示里还有材质分层系统：泥土、雪、其他东西一层层叠上去，引擎处理过渡。还有艺术家专门加进去的雾气，有热物体在冒烟，这些都不是自动生成的。

> “这个画面真正的英雄在于那些艺术家和技术美术。我们在 GDC 上展示它，是因为它远远超出了我们以为这套系统能做到的程度。”（蒂姆·斯威尼）

他也承认这里有个尚未解决的问题：这类场景没法靠几个按钮变出来。换一个没下过功夫的新手来搭同样的场景，效果会差很多。让这种品质变得更容易、更自动，是接下来的挑战。

那个燃烧的垃圾桶的演示也一样。底下是强大的粒子系统，为什么这次看起来终于不像电子游戏了，斯威尼的答案是艺术家的成熟度占了非常大的一部分。烟雾遮挡光线、光线穿过烟雾如何衰减，这些算得都对，让它看起来像真的在烧，靠的还是人。

## 人脸是计算机图形学里最难的部分

原因写在进化史里。几百万年的演化给了人类专门识别面部模式、推断情绪和意图的脑区，因为穴居人看见陌生人，必须瞬间判断对方是友善的还是来杀他的。所以人对一张脸有极其精细的预期，能注意到任何一点不完美，尤其是由图形学局限造成的那种不完美。

MetaHuman 的工作分几块。数据侧是一台专门的捕捉设备：把人放进一个布满几十台相机的球体里，用高分辨率、高帧率拍下他做各种动作的过程。捕捉一张脸要几小时，后续处理要几千小时。一个人的脸难在形状，也难在全部可能出现的动作范围，还有肌肉、筋膜、脂肪如何协同产生表情。

更有意思的是另一个目标：捕捉成千上万个人，构成一个覆盖全人类所有文化、所有大陆、所有年龄段、所有脸型多样性的数据集，然后把它们组合、融合，从而重建出一张系统从未见过的任意面孔。理想状态下，你拿 iPhone 拍一张照片，系统不在那台设备上现场合成，而是调用已知的人类面部全部细节，给出最准确的还原。

渲染侧的难点一个接一个。头发：物理定律是已知的，逐根渲染很容易，只是慢十亿倍，所以需要能捕捉头发对像素的净效果、而不计算每根头发与每束光每一次交互的近似方法。皮肤：我们以为人是实心的，其实光会穿过皮肤，次表面散射对人的外观影响巨大。这就是为什么你没法把一个假人模特涂成一个真人，它只是个实心表面，永远不会有那种细节。

> “把脸做对，需要几十个不同的系统和图形学侧面协同工作。其中任何一个错了，你的眼睛就会被完全吸过去，然后你就掉到了恐怖谷的错误一侧。”（蒂姆·斯威尼）

他对精度的要求差异说得很清楚：建筑的阴影稍微不对，大脑其实不太在意。人脸上任何一点不对，都会让人极其不适。

工具上有两个：MetaHuman Creator 用来捏脸，一大堆参数调出一张独特的面孔，然后进引擎加布料模拟、调头发；MetaHuman Animator 用 iPhone 级别的设备做面部捕捉，再把捕捉到的表演迁移到你想要的角色上。这个迁移其实非常不平凡：演员的脸型和角色的脸型不同，直接照搬在视觉上会完全错。

他特意强调这件事远没做完：这个项目做了三十年，总共可能需要五十年才能达到绝对的照片级真实和完全可控。现在给艺术家的是生产力和质量上的倍增器，远未到终点。

## 关于 AI：一致性才是真问题

斯威尼认为业内对 AI 生成视频的进展速度过于乐观。核心问题是连贯性：单张图可以极其惊艳，视频在不同地点之间切换时，各家 AI 方案都有一致性问题，他不认为这些能被轻易修好。

根本原因在于，AI 对“整个场景”“整部电影的情节弧线”“周围世界的全貌以及它会如何影响这场戏”没有类似的理解，而游戏引擎恰好在这个位置上有精确的表示。

他把未来分成两种世界模型。一种是场景图（scene graph）：引擎维护的、包含世界里所有物体及其海量数据的精确表示，可以从任意视角、任意设置渲染，完全可复现，同一个场景跑十遍结果完全一样，不会出现“这个角色的脸怎么中途变了”这种事。代价是全部要手工搭建，昂贵、耗时、需要专业能力。

另一种是 AI 脑子里的世界：海量关于世界、关于图形、关于人、关于一切的知识，存在人类无法理解的参数里，只能通过提示词查询出来。问题是这团数据非常“糊”，你不知道怎么下一条指令得到精确结果，提示词稍微一改，输出可能天翻地覆，完全无法做美术指导。这件工具彻底未被驯服。

他的判断是：把两者接起来。AI 增强传统场景的内容生产流程，场景表示也共享给 AI，让 AI 不只看到提示词，还看到“这个世界的全部物体清单及其属性”。引擎和 AI 之间形成持续的反馈回路，就能同时得到稳定的场景和高生产力，美术指导的结果也能固化进永久的场景表示里。

关于岗位焦虑，他给的历史类比是合成器。早年用电子合成器做的歌一度不被某些音乐奖项接受，被判定不算真音乐；后来大家明白了，那只是乐器，人在演奏、在控制。Photoshop 做的算不算艺术，也经历过同样的质疑。他判断 AI 最终会成为艺术家工具箱里的又一件工具，而且会越来越可被精确指挥。

> “很多疏离感来自：提示词强大到能给你一整个作品，却完全不肯让你控制其中的细节。你说把这个东西换成那个、把那个物体变绿，它做不到，用多少词都说服不了它。这让人感觉电脑在夺走控制权，还有自己的想法，像个竞争对手。”（蒂姆·斯威尼）

他对 AI 写代码的判断也很克制。AI 很擅长输出那种“GitHub 上一百万个仓库已经做过”的代码，模式它学过了；让它做没做过的新东西、尤其是复杂任务，出了名的难。你要的代码量越大，它越容易给你一堆“勉强能跑”的烂摊子。代码的问题在于 99% 能跑，剩下那 1% 用 AI 修到 100%，可能比手写还难。他建议所有关注这个话题的人，拿真正的难题去试试编程助手。

他顺手抛出的另一个观点：样板代码的存在本身就是编程语言和软件模块化设计的失败。你让 AI 生成一个排序函数，好，现在你多了一个可能有 bug 的排序函数，和另外一百万个别人写的并排放着。更好的做法是有一个写过、测过、优化过、所有人都在用的排序函数。

## 模拟现实还差多远

斯威尼的估计是：不到 20 年，我们会逼近到一个令人震惊的程度，而且肯定在我们有生之年能看到。

分领域看，非人类的交互已经很接近了。走过一片丛林、穿过一座城市、所有的光照，可能只差几年。所有涉及人的部分标准要高得多，要骗过人脑，需要跨越的门槛完全不同。未来十年图形和模拟的主要挑战就在这里。

他提到十年前有人问过同样的问题，他当时的回答是：就算给你无限算力，我们也模拟不出真实的人，因为我们根本没有算法，完全不知道如何模拟人类智能。这句话在当时是对的，现在不完全对了。生成式文本 AI 至少在文字层面已经能相当好地模拟一个人。

> “我不是说这是个好主意，但技术演进的弧线正不可阻挡地朝那个方向走，而且速度快得吓人。”（蒂姆·斯威尼）

关于“我们是否生活在模拟中”，他没有直接给答案，只提了两个角度。这个问题最终会归结为：如果我们在模拟里，那他们又在什么里？总得有个基础现实。有一种被严肃提出过的哲学理论认为根本不需要物理现实：如果你有一套方程（比如物理定律），那么这些方程下所有可能的动力学演化本身就具有物理实在性，我们只是数学定律的一种显现。

他还认为这最终是个神学问题，而神学作为科学的一部分已经不时髦了，在正经物理期刊上发不了这类结果，所以被搁置了。量子力学本身给“外部输入”留了位置：量子波函数坍缩时，当我们去观测一个处于完美叠加态的系统，我们只看到某一个特定结果，那个随机数每秒钟被注入周围一切事物万亿亿亿次。如果你想挂一个外部输入，那里有个接口。

> “在这个领域，我们知道的并不比穴居人多。我们知道量子力学的定律，我们可能有很快比我们更先进的计算机，但对生命、宇宙以及一切的根本问题，我们没有任何答案。”（蒂姆·斯威尼）

关于“会不会造出让人不想回到现实的游戏”，他的态度很明确：技术正在到来，剩下的是人类的问题，我们该走多远，界限划在哪。他说 Epic 自己不追求这个，他们做好玩的游戏，让人在工作和其他现实生活之间玩得开心。

莱克斯在这里补了一句判断：如果真造出足够真实、能感知痛苦的人类模拟，那就该有法律禁止。一旦真实到能受苦，就意味着这个模拟体可能被折磨。这在游戏里开枪没人在意，那条线在哪，会是很长一段时间里最高法院要处理的问题。斯威尼的回应是，游戏开发者总体上一直是善意的，今天流行游戏里最坏的事也就是 GTA 里抢个银行，显然虚构、明显夸张。随着越来越真实，问题必须回答。

## 堡垒之夜：四周做出来的东西，改写了整个公司

起点是 2011 年。Epic 当时正在收尾一款《战争机器》，想探索新东西，于是给全公司一周时间自由组队，用虚幻引擎做一款游戏。一个团队做出了《堡垒之夜》最早的版本：白天用建造系统搭堡垒，晚上抵御僵尸，撑得越久堡垒越精巧、波次越难。

这款游戏在开发中待了很多年。建造这件事本身极其好玩，潜力一直在，方向却调了好几次。有一次他们把美术风格从偏写实转向现在这种皮克斯式的、更讨喜的卡通风格。

关于这个转向，斯威尼的解释很有意思：Epic 的人来这儿是想和世界上最好的人一起工作，很多美术在写实内容和高度风格化内容上都很强，《堡垒之夜》最好的那批美术，很多也是《战争机器》最好的那批美术。他们判断《堡垒之夜》可以做成一个很大众、能玩很久的游戏，所以需要一个视觉上舒服、不像《使命召唤》那样让人时刻紧绷着在暗处找对方瞄准镜的美术风格。

中间还试过类似《命运》那种带复杂 RPG 和数值系统的轻度 MMO，又演化成类似塔防的 MMO，最后留下的是物品和数值的持久化，做成了 2017 年初上线的《堡垒之夜：拯救世界》，成绩中等，收回了预算还略有盈余。

与此同时吃鸡品类爆发，PUBG 刚出，Epic 一堆人在玩，有人说这要是能加上《堡垒之夜》的建造该多好。于是他们把一个 30 人的团队关进一间大屋子，四周之内做出大逃杀模式并上线。

能这么快，是因为过去七年的内容库已经在了。麻烦的是玩法和系统，四周内全部造完。之后 Epic 从 300 人涨到几千人，收入从一亿美元级涨到十亿美元级。

## 从四万到一千五百万并发

技术侧的底子其实从 2012 年就开始打了：账号、登录、多人在线所需的所有后端系统，一直按可扩展的思路在做。上线后的一年里，在线团队把并发从 4 万做到 1500 万。

架构是微服务：没有一台大服务器处理所有交互，而是游戏服务器跑 100 人一局的实例，账号服务器多个实例共享一个数据库，几百种微服务互相通信。扩展的工作就是找出瓶颈、保证每一环都能横向扩、都有足够冗余。

他特意点出了云的作用：Epic 做到 1500 万并发，没有买过一台服务器硬件。有一周巴西的服务器在周末高峰期被打爆，下一周玩的人更多，服务器已经就位了。亚马逊有人在不声不响中往巴西扔了几百万美元的硬件，正好赶上《堡垒之夜》需要。

> “这个故事里有很多无名英雄，其中很多我们从来没听说过。”（蒂姆·斯威尼）

## 为什么现在的游戏生态是个烂摊子

斯威尼的这个开场是整段访谈里最直接的一段。

> “让我从游戏的现状讲起，以及它为什么糟糕。”（蒂姆·斯威尼）

他在《堡垒之夜》里有 1 亿月活，你的一大堆朋友都在，你可以在应用内无缝从一个体验切到另一个，有十万个岛可以玩，不断有新的出来。你想玩 Roblox，你得退出《堡垒之夜》，启动 Roblox，不同的程序、不同的好友系统、不同的账号名，你得重新加一遍朋友，操作手感也不一样，得重新学摇杆、鼠标、键盘怎么用。你在《堡垒之夜》买的东西很好看、在《堡垒之夜》哪儿都能用，到 Roblox 就没有了，得买另一套，而且只能在 Roblox 里用。《使命召唤》是另一个孤岛，《魔兽世界》是另一个，《英雄联盟》是另一个。

主机厂商很久以前试图解决这个问题，做了平台级的好友和账号系统，但你 PlayStation 上的朋友只能在 PlayStation 上跨游戏，到 Xbox 就看不见。世界被切成两套互相垂直的领地：平台及其社交服务，和一个个不同的游戏。谁都不是出于恶意这么干的，这是历史演化的产物。结果就是人没法带着朋友和物品在游戏之间自由移动。

他的解法是联邦化：把所有系统连起来。所有平台上的玩家都能靠名字互相识别，加个 @ 前缀，Xbox 的名字、《堡垒之夜》/Epic 的名字、Steam 的名字可以共存在同一个空间里，互通。这是第一层，统一社交生态。

第二层更难，统一经济。他说你在《魔兽世界》里的剑不该在《堡垒之夜》里能用，每个游戏有自己的玩法规则，很多东西本来就只能在自家用。但有一大类游戏共享同一个概念：不影响数值、纯粹外观的皮肤系统。市面上大多数主流多人游戏都有。他说把这些游戏拢一拢，大概 70% 可以归为“相似到足以互通”，你在《堡垒之夜》有一身衣服，在 Roblox 有一身，可能还有一二百个游戏里也是同一身，而且真的能通用。

他还讲了《堡垒之夜》创作者经济的关键设计：营收和参与度分开。游戏模式（大逃杀、各种玩家自制玩法）是参与度来源，不直接赚钱，因为玩法不能付费取胜。钱全部来自物品商店，而物品商店的营收完全由参与度驱动。按参与度分配收入的办法是：你花掉的这笔钱，如果你 40% 的时间在大逃杀、60% 的时间在某个玩家自制模式里，那么这笔消费里可分离出的利润部分，会按比例分给参与这个经济的各个创作者。这套机制让《堡垒之夜》的创作者经济做到了 4 亿美元规模，而且还在涨。

下一步是把这套东西标准化到能跨公司、跨生态。他举的例子很具体：如果有一个标准组织定义了“可携带的游戏皮肤”是什么规格、有什么能力、能做什么不能做什么，那就可以有一个经济体系，每个游戏承诺尊重彼此这类物品的购买，收入在生态之间也分成。

还有一个数据上的怪现象：有个叫《Only Up》的模式，就是一直往上爬，纯粹的好玩，所有人都喜欢，玩这个模式时大家却不太买皮肤。原因其实很直觉：你看不到别的玩家，你能看到的只有前面那个人的屁股。所以你可以量化出一个游戏模式和消费之间的经济相关性。

关于元宇宙的定义，他清了一堆混淆。大规模多人在线社交游戏，每月有六到八亿人在玩，这是真实的、正在发生的。VR 用户群小得多，他不认为做这件事需要 VR，VR 是可能增强某些场景体验的硬件。至于 NFT，那只是标记金钱或价值交换的一种方式，你用什么都能做，这件事本质上不需要加密货币，需要的是互操作性，而互操作性可以通过区块链、可以通过数据库、可以通过标准组织和协议来实现。铁路标准化之后我们已经干了几百年了。

## Verse：为了几百万个业余程序员，重新设计并发

目前已经有成功的底层标准。2D 图像有 PNG，音频有 MP3，3D 有皮克斯的 USD（通用场景描述），描述整个场景图、所有物体及其参数，任何支持这些特性的引擎都能导入并渲染出同样的场景。纹理和几何有 glTF。一个《堡垒之夜》角色的静态外观、身体形状、动画、姿势、表情音效，都能用这些格式存下来。

> “最大的缺失是那个处在标准化元宇宙中心的编程语言。”（蒂姆·斯威尼）

他的类比是 Web：HTML 描述 2D 场景图，是静态数据；JavaScript 用来操作它，实现任何能用代码实现的东西。元宇宙需要类似的东西，却要远比 JavaScript 强大、安全、可扩展。网页是“一家公司准备好一坨代码和内容，发布出去，然后它就一直是那样，直到他们发新版本”，元宇宙是几百万人构建的代码和内容的复合体，可能组成一个无缝的世界。

规模感：一次《堡垒之夜》大版本更新大概是 60 GB 数据，这只是《堡垒之夜》创意生态的一小部分。十年后以 EB 计，完全可能。

Verse 的设计目标里有几条值得单独拎出来。

第一是简单和强大可以并存。他引用 Pascal 的作者 Niklaus Wirth 的原则：编程语言不该靠堆特性获得强大，该靠少量特性任意组合。他提到 1956 年那场几乎没人知道的会议，现代编程语言的所有主要基础都是在那定下来的，C 系语言全部继承自它。那批人把函数、变量、递归都定对了，也定错了几件事，Verse 想修的就是那几件。

第二是函数式逻辑语言（functional logic）。在传统语言里，一个表达式产生一个值。在函数式逻辑语言里，一个表达式可以产生零个、一个或多个值。零个叫失败，一个叫成功，多个就是一组可以迭代的值。

落到具体语法上，传统语言的 if 是拿布尔变量或布尔表达式做条件，求值过程中产生的任何计算结果都丢掉了。Verse 的条件要么成功并产出一个值，要么失败：成功就走 then 分支，then 分支可以直接访问在条件里成功绑定的那些变量。这带来的可靠性提升很实在，你可以写一个条件，只有一堆变量都成功绑定之后才能进入内部。

for 循环也一样。传统语言的 for 是一堆命令式代码编织在一起迭代，复杂逻辑写起来很别扭，于是你不得不造出迭代器之类的复杂结构来绕开它。函数式逻辑语言的思路是：for 循环直接产生多个值。产生零个值就是零次迭代，产生一组值就是依次迭代。你可以在条件里或 for 循环里写类似 SQL 查询那样的东西，绑定一堆变量、做一堆测试、产生一串有序结果，然后统一处理。等于把数据库的能力和普通编程的能力用同一种更均匀的方式合到了一起。

他还提到一个观察：从 C++ 转过来的 Epic 程序员，头几个月写 Verse 会写成“用 Verse 语法写的 C++”，比好 C++ 和好 Verse 都差；几个月之后就写出更紧凑的代码。完全没编过程、直接在《堡垒之夜》里学编程的用户，把这些当成直觉，写出的循环和条件比 Epic 内部很多人还高级。

## 编译器能拦住多少错，就能省下多少代价

元宇宙对语言的要求，第一条是代码在持续演化、作者成千上万。你可能每秒都看到某个模块被更新。在一个永不关停、持续运行的模拟里，所有东西都得原地热升级。所以一个关键能力是：发布一个更新之后，能确定它和上一版向后兼容。这本质上是个类型检查问题，取决于语言的类型系统。

他举的例子很具体：一个函数承诺返回整数，将来你改成返回自然数，这是向后兼容的，因为每个自然数都是整数；你改成返回有理数就不行，因为有些有理数不是整数。系统应该拒绝这种改动。Java 和 C# 早期定过一套很严格的这类规则，后来放弃了。

然后他讲到了更狠的一层：1930 年代有人发现，如果类型系统按某种特定方式设计，类型就不只是“变量 X 是整数”这种标注，还可以表达数学定理。比如“这个函数接收一个整数数组，返回一个同样的整数数组，且结果是排好序的”，把它写成定理，就能要求写这个排序函数的人证明它真的排好了。类型就是定理，按特定方式构造的值就是定理的证明。

这在数学界已经在发生。今天数学家说“用计算机证明了一个定理”，实际意思是他们用一种证明语言（Lean、Coq 等）写了机械可验证的证明，计算机检查过，没法撒谎。

> “我们的目标是让 Verse 成为第一个全面采用这套方法的 mainstream 编程语言，而且采用的方式要足够友好，友好到你不需要自己去写证明。”（蒂姆·斯威尼）

他要的性质是：如果编译器接受了你的程序、没报错，程序就应该能正常工作。人总会犯错，这个理想永远达不到，可以靠越来越多的语言特性让编译器抓到越来越多的错误。

为什么这在元宇宙里格外重要？bug 逃到运行时、到了用户手里之后，修复成本是几百倍。在自己机器上，改一行就好了。上线之后，你要发补丁、写补丁说明、测补丁、检查有没有引入新 bug。Verse 的核心目标就是把错误尽量拦在编译期，让元宇宙成为一个可靠的地方。

莱克斯问到是否能在编译期证明程序的正确性。斯威尼的回答很清醒：证明的难度是组合爆炸式增长的，能渐进采用、用在你真正需要的地方才是重点。写密码学算法、写一个被整个生态使用的解压器（证明它不越界），这类地方值得证明。今天大量安全漏洞的根源，就是别的语言里编译器能拦、而 C 拦不住的东西。

他还有一句安抚：所有用带类型语言的人其实一直在证明定理。你写一个整数变量并赋值，你就向编译器证明了那个值是整数，否则它会被拒绝。不必觉得可怕，随着更高级的证明加入，可组合的性质会自然长出来。

莱克斯提到斯威尼给他发过关于 Curry-Howard 对应（柯里-霍华德对应）的材料。斯威尼说这是 1930 年代计算机科学最重要的成果之一，却几乎没人知道。它建立了数学逻辑和类型系统之间的严格对应：你能在数学逻辑里证明的，在具备某些特性的类型系统里也能证明。

拆开看“什么是证明”就很直观：证明整数存在的东西，就是一个整数，比如 5 就是“整数存在”的证明。写 *var X int* 然后 *X = 5*，你就在向编译器证明 5 是整数。要证明 A 和 B 同时成立，你得提供一对值，一个证明 A，一个证明 B，这是合取律。还有析取律。还有蕴含律，而它恰好由函数满足：你写一个函数说“给我这种东西，我还你那种东西”，你就在证明一个蕴含。只用大约七条定律，就能在一个类型系统里构造出全部数学逻辑。

他还区分了主观和客观。命名、书写形式这类是主观的，Guido van Rossum 决定 Python 用缩进，这类东西永远有主观层。类型系统不是主观的：有一种做法能给你数学证明，其他做法得不到，那些都是更差的，最终应该被淘汰。他认为计算科学的一项工作，就是分辨出过去哪些做对了、哪些做错了，然后把做错的重做一遍，否则系统终将被自己积累的复杂度压垮。

## 并发：把一百万人的痛苦，转移给少数人

斯威尼说这是这一代要解决的最大技术问题：驯服并发，让普通程序员写普通代码就能实现它。

单线程编程已经够难，它完全可预测。引入多线程或数据中心多节点之后，每个线程都要读写不同的数据、改变世界状态，今天几乎所有真实程序里的并发都是手工实现的：程序员极其小心地写可能在多线程里跑的代码，让各线程协商着访问数据，以获得可预测的结果。

> “这太难了。难到虚幻引擎五代，每一代都决定不去把游戏逻辑代码手工扩展到多线程。对自己、对每一家拿虚幻引擎做游戏的合作方来说，这都是一把巨大的枪，太容易走火。”（蒂姆·斯威尼）

现有的替代方案都不理想。一种是干脆不解决，把程序拆成微服务，像亚马逊那样几百个微服务互相发消息，靠程序员极其小心地写，最后能可靠地处理你的订单不出乱子。这套办法没法扩展到元宇宙，因为那里有几百万程序员，多数没受过计算机科学的训练，是爱好者、是第一次编程、是为了好玩。他们永远不可能预见到自己并行跑的各种计算之间的全部依赖关系。

真正的出处在 1980 年代的基础工作，被一篇关于 Haskell 并发的论文《Composable Memory Transactions》变得非常现实。核心概念是事务（transaction）：一块代码，做一堆内存操作，可能读、可能写、可能处理订单、可能接受或拒绝、可能从一个账户转钱到另一个账户、可能做条件判断。

不用事务会怎样？所有人随机地加加减减彼此的银行余额，某人读出余额、减一百、写回去，这中间别人又写了别的东西，于是余额不一致。事务就是把整个程序切分成一个个自包含的更新，每个更新可以做任意量的计算，必须以单线程方式运行。

放到游戏引擎里，一个事务就是一次游戏对象更新。你玩《堡垒之夜》看到的每个东西：其他玩家、敌人、火箭、抛射物、车，都是独立的对象，每个以每帧一次的频率更新，60 帧每秒。一局大逃杀 100 人，每帧有几万个对象更新。

问题在于，这现在是在单个游戏会话里单线程做的。这就是《堡垒之夜》100 人上限的来源。你把一台服务器榨干，今天也许能到 140，到不了几千、几百万、几十亿。

事务内存的思路是：让程序员写完全普通的代码，用完全普通的方式读写变量，完全不用操心并发。系统在底层这么干：既然有一大堆操作要施加，就让它们并发地跑，每个都不直接读写全局内存（那样会互相争用同一份数据、做出互相矛盾的事），改成把所有写操作记录在本地，只存在这一个事务自己的缓冲区里。对这段代码来说，看起来就像在全局系统上运行、在影响全局游戏状态，实际是隔离的。这些更新被暂存起来，稍后再考虑。

然后同时跑几十、几百、几千个更新，找出哪些发生了读写冲突。如果两个事务没有读写任何相同的数据，那它们以任何顺序跑、或者同时跑，结果都不会变。

> “所以你可能更新一万个对象，发现其中九千个无冲突，那就把这九千个更新应用到内存，它们本来以任何顺序跑结果都一样。”（蒂姆·斯威尼）

剩下那一千个，把它们的计算全部丢掉，重新跑，也许换个交错方式，直到最终能提交。这样就把这件事从程序员要处理的编程问题，变成了语言设计者要处理的语言问题。本该压给一百万人的巨量痛苦，转移给少数几个人去真正把它做出来。

## 虚幻引擎 6 的时间线

Verse 目前的状态是两条线并行。一条是终极版本的语言规格，包含他们想要的全部特性；另一条是陆续发布的、更朴素的版本，一年半里发了几十次更新，每次都和旧版本保持向后兼容，逐步逼近终极版本。

这场实验目前完全在 UEFN（《堡垒之夜》虚幻编辑器）里进行。他们想先在元宇宙这个用例上，和《堡垒之夜》创作者一起测试、迭代，再开放给所有用虚幻引擎做项目的合作方。现在 UEFN 的编程特性还很少，需要补很多，今年内每隔几个月就会加一大批新 API。

虚幻引擎的授权方要独立做游戏，通过 C++ 已经能用上完整引擎，他们对 API 的期待量极大，在把必要特性补齐之前没法开放给他们。

两条线的汇合点是虚幻引擎 6，还有几年。没有确切时间表，可能两三年后能看到预览版。UE6 的目标是把两边最好的东西合起来：对《堡垒之夜》社区和授权方都更简单的玩法编程、更强的可扩展性、更好的易用性，以及一次开发、随处发布。终极形态是开发者可以做一个任意类型的游戏，同时作为《堡垒之夜》岛发布（玩家带着自己的物品和皮肤进来、正常互通），或者作为独立游戏发布，或者两者都做，独立发布也不会被排除在开放经济之外。

关于独立开发者，斯威尼提到莱克斯举的例子：Gavin Eisenbeisz 一个人做出了《Choo-Choo Charles》，据说没用 C++，用的是可视化脚本蓝图。斯威尼说核心是生产力：要成功必须有出色的游戏；如果做的是没人做过的类型，可以做得更小更简单；如果挤进一个期待值极高的大品类，就很难。工具的生产力是其中一环，内容市场也是，货架上摆着一堆现成内容，有些免费有些付费，由其他创作者做，能让小团队做出大游戏，把精力集中在游戏真正独特的部分，不用自己造每一棵树、每一块石头。

他还提到劳动的细分：1980 年代基本是一个人做一款游戏；后来美术、程序、玩法程序、引擎程序分开；现在有技术美术，一款 3A 游戏有几十种专业分工。把内容模块化得越彻底，创作者能越快越成功地做出东西。

## 为什么只有 Epic 敢和苹果正面打

斯威尼从计算机史的基本事实讲起。他的第一台电脑是沃兹尼亚克设计、苹果销售的 Apple II Plus，然后是 IBM PC。那时候任何人都能写代码，电脑开机就是一个编程语言的提示符，你得主动做点事才能不写程序、去跑别人的程序。任何人都能写程序、拷到软盘上、分享给朋友、复制、放进商店卖、围绕它做生意，完全不需要任何大科技公司的许可。哪怕 IBM 是当时地球上最强势的电脑公司，它发布 IBM PC 时选的是开放平台。

> “那是一个对技术而言经济增长空前绝后的时代，这件事牢牢刻在我脑子里。”（蒂姆·斯威尼）

后来大公司意识到，他们可以关掉这一切，阻止软件作者自己发布软件、阻止他们直接和客户做生意。他始终认为这种做法极其恶劣：你花钱买了手机，手机就是你的，苹果没有任何理由阻止你直接从别的开发者那里装应用、去他们网页、或者写自己的应用自己跑，不需要开发者账号，不需要过他们的官僚流程。

消费者买了应用，也没有任何理由不能直接和开发者做生意。你已经买了那台手机，苹果凭什么在你所有交易上加 30% 的“垃圾费”，而且还挑挑拣拣，对某些东西收、对某些东西不收？

他说这关掉了曾经驱动应用和软件经济的竞争引擎。Windows 和互联网上这个引擎还很活跃，移动应用上没有了。这些商店对用户没有提供任何有用的价值。它们确实有搜索功能，没理由别的公司不能做得更好。他赌 Steam for iPhone 会是一个比 iOS App Store 好得多的应用商店，很多人会用，苹果会被迫在竞争里做出更好的商店。

他还指出一个后果：移动应用的性质被重塑成了对玩家品味极其冒犯的样子。主机商店里卖得最好的是性价比极高的、投入了巨大工作量的作品；iPhone 上排名靠前的几乎总是那些极其贪婪、重度变现的鲸鱼游戏，充满付费取胜和抽卡开箱，是一种合法化的赌博，驱动力来自操纵玩家，跟好玩没多大关系。基于好玩的游戏很难在那里成功。

算一笔账就明白了：运营一款在线游戏的成本已经极高。一个靠好玩的游戏要把 30% 收入交给苹果才能上平台，而 30% 远超现在大多数游戏公司的利润率。当这笔费用超过正常公司的利润，就只能靠涨价活下去。这 30% 在推高所有数字商品的价格，本身就是一股通胀力量。

而且这只是第一层。要在苹果平台上被用户找到，用户搜索某款游戏时，第一个结果总是被广告顶上去的竞品（在《堡垒之夜》被下架之前，用户搜 Fortnite，第一个结果总是某个完全反用户的竞品）。想拿到搜索第一位，你实际要付的可能是 45%；想在社交媒体触达用户，再付 20%。

> “你的游戏收入里，大概 70% 只是作为垃圾费去获客。剩下的钱只够支撑那些有相当恶劣做法的游戏，它们在正常玩家眼里基本不像游戏。”（蒂姆·斯威尼）

关于为什么只有 Epic 敢打，他的回答很直接：所有公司都怕苹果，因为苹果能毁掉他们的生意。Epic 的特殊之处在于，开打时《堡垒之夜》是当时世界上最大的游戏，而且大多数用户在 PC 和主机上，就算打官司期间失去 iOS 用户，公司还能活。Spotify、Facebook，你数得上的前十大移动应用，他判断没有一个能承受苹果封杀，生意会被直接摧毁。

苹果极其明确地告诉开发者：他们愿意在和某人打架时剥夺所有用户使用某个应用的权利。他们对付 Epic 时，除了为赢官司做法律动作，还在向全世界所有开发者传递一个信号：你敢打，我们就尽最大努力毁掉你的生意。只有极少数敢发声的开发者，在没违反苹果政策时，苹果克制住了没去碾碎他们的生意。这需要一点克制，也是苹果的一种算计：他们承受不起被看作“批评我就碾碎你”的公司。

苹果还有一手随时可以对任何开发者用的软权力：审核。他们抽 30%，广告又那么贵，苹果批准你的更新快一点、或者把你所有更新拖慢几周，就能显著影响你的竞争力。苹果有很长的和开发者玩猫鼠游戏的历史，某开发者不在苹果的恩典里，就把更新放慢。他们已经拖慢过好几家大科技公司的更新，有时几周有时几个月，全都悄无声息，因为所有人都怕公开挑战他们。这种软权力足以把一个公司的经济状况恶化到吓退几乎任何一家上市公司。

Epic 打这场仗的理由，是他坚信元宇宙只能在一个前提下诞生：苹果和谷歌的守门人垄断被解除。这不只是 30% 的问题。苹果禁止 iOS 上所有浏览器实现比苹果更好的 Web 标准，把 iOS Web API 的数据存储能力和 3D 图形能力卡得很死，就是为了故意削弱 Web 应用，让它们不可能和原生应用竞争。如果苹果用对待 Web 的方式对待元宇宙，他们会说：你只能用苹果的元宇宙引擎，虚幻引擎不许用。然后他们可以施加自己的一整套限制，把所有交易强行导流给苹果，或者把它弄得毫无竞争力。

他用了一个苏联式的说法：纵深防御。他们建了一整套巨大的壁垒阵列，每一道都足以致命，即使一道被突破，其他道仍然能把整个方案掐死。这在欧洲已经上演：苹果允许 Epic 上线 Epic 游戏商店，把它做得对 Epic 和对想合作的客户都极其困难、毫无竞争力，除非欧盟开始真正执行 DMA 并施加严厉处罚，否则它没有成功的机会。

莱克斯的表态是：他喜欢苹果，认为这件事上苹果就是错的，这对苹果自己也不好。公司都有封闭、控制、碾碎竞争的冲动，苹果有一堆才华横溢的工程师，开放了去赢，竞争会让苹果商店变得更好。斯威尼补充说，垄断被迫竞争之后，产品会突然变好，对消费者的供给会变好。他等不及新一代领导层进来，画出通往未来的明亮路径。

> “Epic 和苹果做过十多年很棒的伙伴，一起做演示、一起合作、一起用技术，做过很多了不起的事。我最想要的就是回到那个苹果。回到沃兹尼亚克最初的想法。Apple II 是一台完全开放的平台，它的说明书里印着所有 ROM 的源码清单，你能完全看懂那里在发生什么、能从中学习；还印着整台电脑的硬件原理图，你能学会怎么做外设、插进一个开放的生态。那才是了不起的苹果。那家公司会重新成为世界上最好的公司。现在这家站在了历史的错误一侧，需要改变。”（蒂姆·斯威尼）

## Epic 游戏商店：12% 和两桩批评

莱克斯先给了肯定：Epic 几年前推出 Epic 游戏商店，用 12% 抽成对抗 Steam 的 30%，创造竞争压力，这个想法很妙。

斯威尼对第一个批评（启动器臃肿、功能少）承认得毫不含糊：Epic 游戏启动器确实臃肿，这需要改进。有很多工作在做。他后悔没把体验类功能放在更高优先级，而是先做了商业化功能，比如商品陈列、同一游戏的多个版本、普通版到豪华版的升级等等，这些是合作方要的。Steam 有 15 年的积累，是行业里最好的一批程序员、更大的团队、更长的时间做出来的。他们经历过多次重构，这确实让用户和他们自己都失望。

他还提到一个之前没意识到的点：体验并不均匀，取决于你离 CDN 的远近和游戏库的大小，有人觉得很好，有人觉得很卡，觉得卡的人恰恰是最爱发声的那部分。

第二个批评是独占协议。他先把原则讲清楚：苹果强迫别人用它的支付服务，是强制；如果苹果靠提供好处、更好的条件、资金或其他正向激励说服开发者用它的支付服务，那完全没问题。一个是阻止竞争，一个是真正的竞争。

Epic 从来没有强迫任何开发者签独占。他们