不重寫引擎，改跑一個x86 VM：網頁版紅警2這條技術路線，算的是維護成本的帳

2026年9月15日晚間，一名V2EX用戶以ID「asset」發布了一個開源專案：網頁版《紅色警戒2》，支援尤裏的復仇、共輝等Mod，支援聯機對戰。專案網址為ra2.games，原始碼放在GitHub的ra2-games帳號下。貼文發布約23小時累積超過1,500次瀏覽。這則消息值得注意的地方，不在於又多了一個網頁版老遊戲，而在於它選了一條與既有方案完全不同的工程路線，而這條路線直接改寫了專案的長期維護成本結構。

兩條路線：重寫引擎，還是搬走整臺機器

網頁上跑一款2000年發行的Windows遊戲，目前社羣裡存在兩種做法。第一種以Chrono Divide為代表：用現代技術從零重寫遊戲引擎，在瀏覽器裡重新實作原作的邏輯。這條路的好處是程式碼乾淨、性能可控；代價是工程量巨大。原發者自己在回覆中給出了具體例子：他玩Chrono Divide多年，發現按Z鍵設定的路徑無法循環等細節至今沒有實作，要把原版全部細節補齊，成本極高。值得注意的是，Chrono Divide本身並未開源，另一個基於其逆向工程的作品ra2web.com走的是同一脈絡。

第二種就是這次專案的路線：不做引擎重寫，而是在瀏覽器裡提供一個x86虛擬機，再往上疊一層ABI相容層，讓原版遊戲的二進位邏輯直接執行。發布者宣稱的實測結果有兩項：冷啟動更快、戰場更流暢；聯機方面，多名玩家透過30毫秒延遲的relay連線時可以流暢對戰。對一款以每幀tick同步為核心的即時戰略遊戲而言，30毫秒是能支撐流暢體驗的量級。

把這個取捨放到工具鏈的脈絡裡看，與先前分析的Rslib 1.0前端工具替代成本屬於同一類問題：替代一項既有軟體時，重寫的邊際成本何時超過相容層的維護成本。Rslib選的是在既有工具生態上壓縮構建時間，這次專案選的是不動遊戲邏輯、只搬執行環境，兩者都是用工程手段繞開「完整重寫」這個無底洞。

相容層路線的成本帳：前期重，後期輕

相容層路線的成本曲線和重寫路線正好相反。重寫引擎的投入是線性疊加的：每一個遊戲細節、每一個Mod的行為差異，都要人工逐一實作，而且沒有收斂點。原版的《紅警2》加上尤裏的復仇資料片，再加共輝等民間Mod，行為細節的總量以千計。相容層路線則是把成本前置：x86 VM與ABI相容層一旦建好，原版邏輯與所有依賴原版二進位介面的Mod，理論上以接近零的邊際成本繼承。

發布者對專案定位的表述也印證了這一點：為社羣提供一個「維護成本小、完整實作原版功能、完全開源」的版本。這三個條件裡，前兩個是相容層路線的直接產物，第三個則是對Chrono Divide閉源缺口的填補。開源在這裡不只是許可證選擇，它決定了專案能否把長尾的Mod相容工作分包給社羣，進一步壓低單一維護者的負擔。

性能數字目前只有發布者自述的「冷啟動更快、戰場更流暢」，缺乏獨立基準測試，這一點需要保留。x86指令集翻譯在瀏覽器環境的開銷，取決於VM的實作品質，WebAssembly版本的x86模擬器在同類專案中曾有明顯的性能落差，這條路線的上限還要等更多實測。

誰受惠，誰承壓

受惠方先是Mod社羣。《紅警2》在中國玩家市場的長壽，很大程度建立在共輝等Mod之上，一個直接執行原版二進位邏輯的網頁環境，讓Mod作者不必為每個平臺重新打包發行，分發成本趨近於零。其次是內容創作者與直播場景，瀏覽器即點即玩降低了觀眾轉化的摩擦，這與GTA6駕駛手感的需求分層反映的是同一件事：老IP的價值愈來愈取決於觸達成本，而非畫面規格。

承壓方則是閉源重寫路線的既有項目。Chrono Divide多年累積的品質優勢仍然存在，但當一個開源方案在功能完整度上以結構性方式追平，閉源項目的護城河就從「功能領先」收縮到「體驗打磨」。這種收縮在開源競爭史上反覆出現，收斂速度取決於開源方案的社羣活躍度。目前該專案的GitHub星標與貢獻者規模尚在起點，判斷勝負為時過早。

發布過程本身也暴露了一個基礎設施問題：多名用戶回報遊戲資源下載返回403，排查後發現是使用了境外代理的網路環境觸發了資源伺服器的攔截。資源分發鏈的穩定性，會是這類瀏覽器遊戲比程式碼品質更早碰到的瓶頸。

收束判斷

這個專案真正的變數不在技術。x86 VM加ABI相容層是被反覆驗證過的路線，從遊戲模擬器到Windows相容層都有成熟先例，工程風險可估。真正的帳在社羣端：Mod相容的長尾、聯機服務的營運成本、資源分發的穩定性，這三項都靠持續投入而非一次性工程解決。開源降低了這些投入的門檻，但沒有消除投入本身。一年後這個專案是成為網頁紅警的事實標準，還是又一個停更的技術展示，看的會是維護帳，不是技術帳。