瀏覽器裡跑 Half-Life 2：WebGPU + WASM 把 2004 年的 Source 引擎搬上 Chrome

編按：本文綜合整理自 Hacker News 討論串、ModDB Lambda Complex 介紹、Xash3D FWGS 引擎說明、DEV.to 上 CS:GO 瀏覽器移植技術紀錄，並加入 Siami 編輯部觀點與分析。

開發者 slqnt 在 6 月 24 日公開展示了一個仍在進行中的專案：hl2.slqnt.dev，把 2004 年問世的 Valve 經典射擊遊戲 Half-Life 2 直接搬進瀏覽器。這個專案週末在 Hacker News 衝到 257 分、96 則留言，許多測試者第一時間的反應是「不敢相信這居然跑得起來」。

這次的關鍵技術不再是當年常用的 Emscripten + asm.js 路線，而是 WebGPU + WebAssembly（WASM） 的組合。整套移植以 Xash3D FWGS 開源引擎為基礎，這是一個由社群維護、對 Source 引擎（Half-Life 2 採用的引擎）進行逆向工程的 GPL 開源版本，再用 Emscripten 編譯成 WASM 模組，最終透過 WebGPU 的現代 GPU API 接管原本 DirectX 9 處理不了的渲染工作。

技術堆疊：為什麼這次跟以前不一樣

要理解這個專案的難度，必須先理解 Source 引擎當年是多麼吃資源：它是 2004 年頂級 NVIDIA GeForce 6800 與 ATI Radeon X800 才能順跑的工作站等級引擎，shader 用了當年 DirectX 9 才剛成熟的 SM 2.0/3.0 路徑。十幾年後的瀏覽器要在沒安裝、零外掛的環境下重現這套管線，靠的是三層技術堆疊：

• Xash3D FWGS 引擎（GPL）：FWGS 是「Flying With Gauss」的縮寫，是目前 Source 引擎社群最活躍的分支，相容 Half-Life、Half-Life 2、Counter-Strike 1.6 與其模組。Xash3D 提供完整的客戶端渲染、聲音、輸入與檔案系統抽象。
• Emscripten → WebAssembly：這條路徑在 CS:GO 瀏覽器移植（vbspexe 在 DEV.to 的紀錄）已經驗證可行——nillerusr/source-engine 倉庫曾在 2023 年開過 Emscripten 編譯支援的 issue，後來原作者刪號，但這條路徑一直有人在繼續走。
• WebGPU：相較於 WebGL，WebGPU 提供更接近原生 Vulkan / Metal / DirectX 12 的低階 API，能處理 Source 引擎那種大量 draw call、shader 常數緩衝、多重 render target 的工作負載。Chrome 113+、Firefox 141+ 已經預設開啟 WebGPU，這是這次移植能成立的最後一塊拼圖。

slqnt 的專案在 Hacker News 上線時，留言區有人馬上把手機打開實測——結果是「直接載入、在手機上跑得起來」。這代表 WebGPU 的行動裝置支援已經足以支撐 2004 年遊戲等級的渲染管線。

為什麼這件事重要：瀏覽器正在吃掉 PC 平台

這個 demo 的意義遠超過「把一個老遊戲搬上網路」這麼單純。Siami 認為它至少證明了三件事：

**第一，WebGPU + WASM 的組合已經能撐起「真正的遊戲」工作負載。**過去十年瀏覽器遊戲的天花板大約是休閒小品的等級，Source 引擎是當年單機遊戲的標竿，能在瀏覽器裡跑起來意味著技術堆疊突破了關卡。對 Unity、Unreal、Godot 三大遊戲引擎而言，這是一個明確的訊號——它們各自的 WebGPU/WASM 輸出目標，會在 2026-2027 年變得越來越實用。

**第二，整套 PC 平台正在被瀏覽器吞噬。**Linux 桌面、WASM、雲端遊戲（GeForce Now、Xbox Cloud Gaming）這些趨勢都指向同一個方向：本地作業系統的差異性正在降低，「應用」與「網頁」的界線正在消失。Steam Machine（Valve 自家遊戲 PC）也在同一天上市，這兩件事擺在一起不是巧合——Valve 對「遊戲跑在哪裡」這件事的想像，從來不限於某一個作業系統。

**第三，開源引擎移植的可行性再次被驗證。**Xash3D FWGS 的存在讓社群可以在沒有 Valve 授權的情況下重新編譯 Source 引擎——這跟 Valve 早年的態度有關，他們並未對非商業性質的引擎移植積極追訴。這次的瀏覽器版本延續了 OpenXcom（X-COM 開源重製）、Dolphin（GameCube/Wii 模擬器）等專案的脈絡——遊戲的「文化保存」價值，正在被開源社群以瀏覽器為媒介重新建立起來。

數據解讀與質疑：版權、效能、長路漫漫

讀者需要保留三個合理的質疑空間：

1. 版權灰色地帶。Hacker News 留言區第一則熱門回應就直指：「技術上看起來很酷，但這也有可能是違法的——除非作者有 Valve 的重新散布授權，否則這就是把 Valve 的資產搬上網路。」Xash3D 引擎本身是 GPL，但遊戲資源（.gcf 檔、貼圖、模型、劇本）是 Valve 的版權。目前這個 demo 的運作方式是「使用者自行上傳 Half-Life 2 的原始檔案」，引擎本身並未內建遊戲內容——這跟早期 DOSBox / ScummVM 的策略一致，但仍要看 Valve 是否動用 DMCA。

2. 效能數字目前沒有官方基準。雖然有讀者回報手機上「跑得起來」，但官方尚未公布幀率、記憶體峰值或相容性矩陣。WebGPU 在不同瀏覽器（Chrome、Edge、Firefox、Safari）的實作差異仍然很大，Firefox 141 才剛補上 Windows 版，Safari 26 才有比較穩定的支援。要說「所有人都能順跑」目前言之過早。

3. 從 demo 到「完整遊戲」還很遠。這次展示的是一個技術里程碑，但從「能載入關卡」到「完整 Half-Life 2 故事模式 12 章全部可玩」中間還有儲存系統、音樂授權、過場動畫、模組相容性、Source Engine 特有的物理引擎（VPhysics、Havok 相容層）等大量工作。這是 6 個月後可能會變得有趣的事，不是現在就能取代 Steam 安裝的事。

不過從產業訊號來看，即使這個專案最終只完成關卡編輯器或第一章，它對 WebGPU 遊戲生態系的推進效果仍然不可忽視——它給了整個社群一個具體的、可量測的目標：要是 2004 年的遊戲都能在瀏覽器裡跑，2026 年的遊戲為什麼不行？

業界反應：WASM 老兵、WebGPU 信仰者、Valve 法務

這個專案在 Hacker News 與社群論壇激起三種典型反應：

• 「WASM 老兵」：從 2017 年 WebAssembly MVP 上線就在等這一天的開發者，現在看到 Source 引擎等級的東西能跑，激動程度不亞於看到 Doom 在微波爐上跑。noclip.website（遊戲關卡瀏覽器展示）維護者 Jannik 應該是這個陣營的代表。
• 「WebGPU 信仰者」：長期推動瀏覽器原生 GPU API 的人，這次證明 WebGPU 不是「Chrome 玩票」而是「真的能跑 production 工作負載」。Mozilla 在 2024 年裁掉一部分 WebGPU 團隊時，曾引發「WebGPU 是不是要死」的疑慮，現在這個疑慮被這個 demo 直接打臉。
• 「Valve 法務」：這是潛在的烏雲。Valve 對遊戲資產的散布授權一向嚴格，但他們自家也有 Source 1 遊戲倉庫，對 Linux 玩家的相容性向來有點傲嬌。這次的瀏覽器移植能不能活下來，最終還是要看 Valve 的態度。

社群媒體上，Half-Life Lambda Generation 粉絲專頁 把 slqnt 的 YouTube 預告與這個 demo 串連起來報導，ModDB 的 Lambda Complex: Source 頁面也提到這個專案的目標是「開源、跨平台（含 WebAssembly）的 Source 引擎移植」。

接下來值得追蹤的三件事

對長期關注瀏覽器、遊戲引擎與開源移植的讀者，這個專案接下來有三個觀察重點：

1. Valve 的態度：Valve 會不會在幾個月內發出 DMCA 下架通知？還是維持過往對非商業移植的容忍？這個判斷會決定整個生態系能不能擴大。
2. WebGPU 的相容性收斂：Safari 26、Firefox 141、Chrome 113+ 三家瀏覽器的 WebGPU 實作如果能在 2026 年底前收斂到 90% 以上相容，這類移植才有可能成為「一般使用者也能用」的東西。
3. Valve 自家 Steam Machine 的定位：Steam Machine 在同一天上市，Valve 對「PC 遊戲在哪裡跑」的態度從 SteamOS 延伸到 Steam Deck，現在又延伸到瀏覽器移植。這個三角關係（SteamOS + Steam Deck + 瀏覽器）會決定 Valve 在 2027 年的戰略位置。