編按：本文綜合整理自 Phoronix、Lore 官方網站、EpicGames/lore GitHub 專案、Anchorpoint 官方部落格 與 Unreal Engine 官方 YouTube，並加入 Siami 編輯部觀點與分析。
Epic Games 在 6 月 17 日於芝加哥舉辦的 Unreal Fest Chicago 2026 開幕日，正式發表開源版本控制系統 Lore，並同步於 GitHub 以 MIT 授權開源釋出（github.com/EpicGames/lore）。這套系統最初以「Unreal Revision Control」（URC）為名，已在 Unreal Editor for Fortnite（UEFN） 內部運行多年，累積了大量開發者實戰經驗；此次開源，等於直接挑戰 Perforce Helix Core 統治遊戲產業近 20 年的霸主地位。
Lore 是什麼？核心架構一次看懂
根據 GitHub 上的 Lore 專案 README 與官方文件，Lore 並非「另一個 Git」，而是一套**中心化、內容定址（content-addressed）**的版本控制系統，專為「程式碼 + 大型二進位素材」混合的工作流程而設計。
幾個關鍵設計重點：
- Merkle Tree + 不可變的 revision chain：每個 repo 狀態都以 Merkle Tree 表示，並串成一條不可變的 revision 鏈。這讓系統能在不下載完整歷史的情況下，驗證任何檔案或整個 revision 是否被竄改。
- 內容定址儲存 + chunked 去重：檔案被切成 chunk 並以內容雜湊定址。編輯 5 GB 紋理中的 5 KB，只會重新上傳那 5 KB；無論是純文字還是上 GB 的二進位素材，重複資料自動去重。
- Sparse / on-demand hydration：工作目錄只下載「這次任務需要」的那幾個檔案，而不是整個資產庫。新人入職第一天不必再花數小時下載「這個專案有史以來生產過的所有素材」。
- 完整 API 表面：C/C++ 是主要 ABI，CLI、伺服器、所有 SDK（Rust、Python、JS、C#、Go）都是薄薄一層封裝。檔案格式與 wire protocol 都是版本化、MIT 授權的 spec — 任何人可以重新實作 client、server 或 backend。
「Lore 從一開始就設計成開放且可重新實作的，spec 本身是版本化的開源文件。這一點 Perforce 做不到，Git 也只公開了 wire protocol。」— Anchorpoint 官方部落格
Lore 同時隨專案提供了 Quickstart 文件、系統設計說明 與 roadmap，並且只要一行指令就能跑起 demo server：
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash -s -- --demo為什麼這件事重要
這則消息之所以在 Hacker News 一舉衝上 232 分、高居當日榜首，核心原因有三：
第一，遊戲產業被 Perforce 卡脖子已經 20 年。Perforce Helix Core 是 AAA 遊戲開發的事實標準，因為 Git 處理不了「兩個美術同時編輯同一張 8K 紋理」這種情境 — 沒有可靠的合併機制，所以業界長期依賴「一人 checkout → 編輯 → check in」的 lock 機制。Perforce 賣的不只是軟體，是整套工作流整合與長期顧問合約，中小工作室每年要為每個席位支付可觀的授權費。
第二，Git LFS 是 hack，不是解法。r/gamedev 社群對此有共識：「Git 處理遊戲素材很糟，Git+LFS 基本上是讓你在主 VCS 旁邊掛第二個 VCS，同時還要忍受 Git 本身的怪癖與限制。」Lore 直接在儲存層做 chunked 去重與 sparse hydration，根本不需要 LFS 這層 hack。
第三，Lore 不是從零開始的玩具。它已經在 UEFN 內部跑了多年，承載了大量真實遊戲創作工作流，這跟「某個新創公司週末做出來的 VCS demo」完全不是同一個可信度等級。MIT 授權 + Epic Games 維護 + GitHub 公開發展 — 這些條件跟 2005 年 Linus Torvalds 釋出 Git 時的處境驚人地相似。
從市場結構看，Lore 的開源等於直接攻入 Perforce 每年數億美元授權費的核心營收。對中小型工作室來說，省下的不只是軟體授權費，還有「養一個專職 tools engineer 來維持 Perforce 運作的人事成本」。
數據解讀與質疑：Lore 真的能取代 Perforce 嗎？
雖然消息令人振奮，但採用率不會自動發生。有幾個關鍵變數值得追蹤：
1. UEFN 與開源版的落差
Lore 自己的 README 直接承認：「Lore 是 UEFN 的內建 VCS，但現有的開源工具還沒辦法跟它對接 — UEFN build 用了專有的壓縮格式，無法隨開源專案一起釋出。」這個 gap 正在被補上（用開源專案自己的壓縮格式），但目前兩者並不相容。對於 UEFN 玩家來說是無感升級，對於想用 Lore 取代 Perforce 的外部工作室，這個落差是真實的轉換摩擦。
2. Desktop client 還沒開源
Roadmap 文件提到，現有的 desktop client 是 binary download，依賴專有元件，尚未開源。對大多數使用者來說，desktop client（不是 CLI）才是日常主力介面 — 這讓「完全開源」的現況打了折扣。
3. Perforce 的護城河不是技術，是生態
切換版本控制系統 = 中斷整條 production pipeline = 風險極高。大部分工作室會選擇「現有系統沒壞就不要動」，除非有東西真的壞了，或新工具帶來 5-10 倍以上的效率提升。Perforce 十幾年累積的 pipeline 整合、受過訓練的工具工程師、與 DCC 軟體（Maya、Houdini、Photoshop）的深度整合，這些都不是開源公告就能取代的。
4. Pre-1.0 的現實
Lore 自己標示為 pre-1.0、API 與 on-disk 格式「subject to change」。任何要拿來扛 AAA 製作的中堅團隊，都會等穩定後再評估 — 這至少是 1-2 年以後的事。
5. 「依賴遊戲引擎公司做版本控制」的疑慮
開源並不等於「公司消失也沒差」。如果 Epic 哪天決定把重心轉向別處，Lore 的維護節奏與 roadmap 走向都會受影響。歷史上開源專案被母公司拋棄的案例不勝枚舉（HashiCorp Terraform、Elastic、Redis 模組），這是任何採用者都必須評估的長期風險。
一位業界人士在相關討論中直言：「這跟 20 年前 Linus 釋出 Git 時的情境驚人地相似 — 開源、極快、針對既有商用方案的痛點而生。Linus 自己也說，社群（特別是 Ruby 社群）的早期貢獻是 Git 成功的關鍵。Lore 已經具備前兩個條件，現在是時候讓生態長出來了。」
Siami 觀點：Lore 的真正考驗在「生態年」
Lore 的技術設計顯然經過深思熟慮，content-addressed storage、chunked dedup、sparse hydration 都不是新概念，但 Epic 第一個把它們整合成一套開箱即用、為遊戲/創意工作流程量身打造的系統，這才是真正的產品價值。
接下來 12-24 個月是關鍵觀察期。值得追蹤的指標包括：
- 是否有 1-2 家知名 AAA 工作室公開宣佈從 Perforce 遷移到 Lore
- 開源社群貢獻者數量（GitHub stars 從 10 顆 → 1000+ 顆需要多久）
- Anchorpoint 承諾的「first desktop client for artists and designers」何時開源
- 是否有「Lore for Unreal Engine 5」官方 plugin，加速引擎整合
- 第一批圍繞 Lore 的工作流工具（code review、CI/CD、asset review）是否出現
對獨立開發者與小團隊而言，現在就是試水的最佳時機 — MIT 授權、本地 demo 一行指令啟動、學習曲線貼近 Git。等生態成形再加入，就跟 2008 年才開始用 GitHub 一樣 — 來得及，但錯過了早期紅利。
編按：本文綜合整理自 Phoronix、Lore 官方網站、EpicGames/lore GitHub 專案、Anchorpoint 官方部落格、Unreal Engine 官方 State of Unreal 2026 直播 與 r/gamedev 討論串，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (4)