# 蒂姆·斯威尼：堡壘之夜、虛幻引擎與遊戲的未來 > Epic 創始人回顧虛幻引擎與堡壘之夜的歷程，談遊戲技術演進、平臺生態與行業的下一步。 - 原標題：#467 – Tim Sweeney: Fortnite, Unreal Engine, and the Future of Gaming - 期數：第 467 期 - 釋出日期：2025-04-30 - 嘉賓 / 主題：蒂姆·斯威尼 - 網頁版：https://lex.qiaomu.ai/tw/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 從來沒有強迫任何開發者籤獨佔。他們