Unreal Engine 5 的最後一個大型版本，已經出現了

Unreal Engine 5 在 2022 年正式發布時，Epic 最醒目的技術名詞是 Nanite 與 Lumen。

前者重新思考大型幾何資料如何被即時渲染，後者則試圖把動態 Global Illumination 帶進一般遊戲 production pipeline。

四年後，Epic 已經開始談下一個世代。

2026 年 6 月推出的 Unreal Engine 5.8，被 Epic 正式稱為目前 roadmap 上：

最後一個計畫中的 Unreal Engine 5 大型版本。

這不代表 UE5 從此停止更新。

Epic 明確表示仍會處理 bug fixes 與 regressions，如果實際情況需要，也保留推出 UE5.9 的可能。

但開發主線已經開始向另一個方向移動：

Unreal Engine 6。

而如果只把 UE6 想成：

Nanite 更強

＋

Lumen 更漂亮

＋

GPU 吃更多

那可能完全低估 Epic 正在做的事情。

因為 Epic 對三個世代給出的描述其實非常不同：

UE4：讓 Unreal Engine 對更多開發者開放。

UE5：重新思考我們如何建造世界。

UE6：重新思考我們如何發布與營運這些世界。

UE6 真正的變化，可能發生在 rendering 下面更深的地方。

---

先看 UE5.8：這其實是一個大量『收尾』的版本

如果把 UE5.8 的更新拆開來看，會發現 Epic 正在做一件很明顯的事情：

讓 UE5 時代的重要系統成熟，同時把下一代架構需要的零件提前放進引擎。

其中包括：

• MegaLights Production Ready
• Lumen Lite
• Mesh Terrain Experimental
• Procedural Vegetation Editor
• PCG workflow 改進
• Chaos Cloth Production Ready workflow
• Animation / Skeletal Editor 改進
• Experimental Toon Shader
• Unreal MCP
• shader compilation 優化

它不像是一個單純追求 headline feature 的版本。

更像是 UE5 在離開主舞台以前，把過去幾年推出的系統逐步整理成可以真正大量生產內容的狀態。

---

MegaLights 終於走到 Production Ready

MegaLights 是 UE5 後期最值得注意的 rendering 技術之一。

傳統即時 rendering 最大的麻煩之一，就是：

動態燈光很貴。

尤其當每一盞燈都需要產生 shadow 時，成本會快速增加。

所以過去遊戲場景常需要大量人工取捨：

哪些燈是真的？

哪些只是 emissive material？

哪些 shadow 要 bake？

哪些燈只能影響部分物件？

MegaLights 的目標，就是讓場景能存在非常大量的動態、有陰影的 area lights。

到了 UE5.8，Epic 將 MegaLights 標記為 Production Ready，並改善 noise、debugging 與 performance。

Epic 甚至把 current-generation console 的 60 fps 當成重要設計目標之一。

在 State of Unreal 2026 上，《Gears of War: E-Day》團隊展示了原本只有少量主要光源的部分場景，如何擴張到數百甚至數千個 dynamic shadow-casting lights，同時瞄準 Xbox Series X 60 fps。

這種變化的意義不是單純：

『我們可以放更多燈。』

而是 lighting artist 可以少做很多為效能服務的假燈技巧。

換句話說：

引擎正在把過去需要大量人工管理的 rendering constraint，逐漸吃進底層系統。

---

Lumen Lite：Epic 開始處理 UE5 最現實的問題，跑不跑得動

UE5 推出後最常被玩家和開發者討論的問題之一，就是：

很好看。

但很重。

Lumen 尤其如此。

所以 UE5.8 很有代表性的一項功能反而不是更高品質的 Lumen，而是：

Lumen Lite。

Epic 表示，Lumen Lite 使用 irradiance fields 搭配 probe occlusion，在保留大量動態 GI 視覺效果的同時，大幅降低 GPU 成本。

官方宣稱它的運算速度約為 Lumen High Quality 的兩倍。

而一個非常有意思的目標平台是：

Nintendo Switch 2，60 fps。

這代表 UE5 後期的方向已經慢慢從：

『我們能做到多驚人的畫面？』

轉成：

『這些技術怎麼真正跑到更多硬體上？』

這件事很重要。

因為一項 rendering 技術真正成為遊戲產業基礎設施的條件，不是它能不能在 RTX 5090 上跑。

而是它能不能一路往下 scale。

---

Mesh Terrain：連 Landscape 都可能重新設計

UE5.8 還加入了一個 Experimental 系統：

Mesh Terrain。

傳統遊戲 Landscape 很常以 heightfield 為基礎。

這種方式非常適合：

山坡

平原

丘陵

大型自然地形

但 heightfield 本質上受到高度圖結構限制。

例如真正複雜的：

懸崖

洞穴

overhang

垂直岩壁

多層地形

通常需要再混合 static meshes 或其他 geometry system。

Mesh Terrain 則直接以 3D mesh 為基礎，並整合 World Partition 與 One File Per Actor。

如果這條路最後成熟，未來 open world terrain pipeline 可能會越來越少區分：

Landscape

和

Environment Mesh。

對 environment artist 而言，這其實比又多一個畫質選項重要得多。

---

PCG 也開始從『生成東西』走向『可以真的拿來製作』

Procedural Content Generation 是 UE5 另一條快速成長的技術線。

但 procedural system 最大的 production 問題一直都是：

程序生成很好。

直到 art director 說：

『這棵樹往左移兩公尺。』

如果手動調整後程序系統就失效，工具就很難真正進 production。

UE5.8 新增的重要能力之一，就是允許開發者在 procedural generation 結果上進行人工修改，同時保留上游 procedural relationship。

也就是：

Procedural Generation

＋

Manual Art Direction

不再必須二選一。

Epic 同時增加 arrays、structures、sets、maps 等更複雜 attribute type，以及新的 spatial-operation PCG graph examples。

官方甚至直接把：

建築

城市街道

大型環境

列為應用情境。

這代表 UE 正在把 procedural worldbuilding 從『工具插件』慢慢推進核心 workflow。

---

甚至連樹，Epic 都想讓你在引擎裡長出來

UE5.8 的 Experimental Procedural Vegetation Editor 更進一步。

它不是簡單 random scatter。

Epic 的方向是：

直接在 Unreal Editor 裡生成 biologically plausible、Nanite-ready vegetation。

樹木可以彼此競爭光照、形成群落，甚至根據周圍 mesh 改變生長方式。

Artist 仍然可以直接雕塑與增加、刪除枝條。

換句話說，UE 正在慢慢侵蝕以前需要：

SpeedTree

DCC

專用 vegetation tool

才能完成的一部分工作。

這其實符合 UE5.8 很明顯的一個方向：

把更多內容製作工作搬回 Editor 本身。

---

然後 AI 真的進 Unreal Editor 了

這裡開始碰到 UE6 的真正伏筆。

UE5.8 加入 Experimental Model Context Protocol，MCP plugin。

這不是在 Editor 側邊放一個聊天機器人而已。

MCP 的概念是讓外部模型能透過結構化 tool interface：

理解 Unreal project

→ 呼叫 Unreal 能力

→ 操作工作流程

Epic 公開提到的模型包含 Claude、Gemini 等，而 UE6 roadmap 更進一步把 model-assisted development 直接列為核心方向。

未來它可能處理的事情包括：

• 建立 level setup
• character rig
• particle system
• skinning bone weights
• lighting adjustment
• 分析程式碼
• 建立工具
• automated testing
• crash root-cause analysis

這跟單純：

『幫我生成一段 Blueprint』

是完全不同的層級。

更接近：

讓 AI 可以操作遊戲引擎。

---

然後就是 Unreal Engine 6

Epic 已經正式啟動 UE6 development stream，而且原始碼開發分支公開可見。

更重要的是，UE6 的定義已經非常清楚：

UE5 + UEFN → 一個統一的 Unreal Engine 6。

這點可能比任何 rendering feature 都重要。

因為現在 Epic 實際上有兩條平行技術線。

一條是：

UE5

→ AAA standalone games

→ PC / console / mobile

另一條是：

UEFN

→ Fortnite live ecosystem

→ Verse

→ persistent worlds

→ live deployment

→ creator economy

Epic 的計畫，是在未來兩年把這兩條河直接匯在一起。

---

UE6 不只是『做遊戲』，而是『遊戲怎麼活著』

Epic 對 UE6 的核心願景可以拆成三大方向。

第一：新的 gameplay programming model

Epic 正把未來 programming model 移向：

Verse。

同時建立新的 gameplay framework：

Scene Graph。

Scene Graph 將從頭建立在 Verse 上。

這件事非常大。

因為今天 Unreal gameplay development 的核心仍然大量依賴：

C++

＋

Actors

＋

Components

＋

Blueprints

UE6 並不會第一天把這些全部刪掉。

Epic 已確認早期 UE6 仍然保留 Actors 與 Blueprints，現有 UE5 專案會有可管理的升級路徑。

但長期方向已經不同。

當新的 framework 足夠成熟後，Actors 與 Blueprints 預計會逐步 deprecated，Epic 會提供 conversion tools。

這不是普通 API revision。

如果最後真的完成，這會是 Unreal gameplay architecture 很大的一次世代交替。

---

Verse 最奇怪，也最有野心的東西：Transaction

Verse 並不是單純『Epic 自己做一個 Python』。

它真正特殊的地方之一，是 transaction semantics。

Epic 的設計方向是讓 Verse function 執行在 atomic transaction 裡。

如果事情需要重新處理：

transaction 可以 rollback

→ 修改狀態

→ 再重新執行。

甚至從 Verse 呼叫的 C++ code，也能透過 Epic 自訂 LLVM compiler 被 transactionalize。

目前 Verse 為了這套模型仍主要運行在 single thread 上。

但 Epic 的長期野心更狂。

他們希望建立：

Distributed Software Transactional Memory。

---

一個遊戲世界，背後可能自動跑在很多 Server 上

想像一個超大型 persistent world。

今天如果要讓它跨多台 server 運行，開發者通常必須面對：

state synchronization

network ownership

database

server handoff

sharding

persistence

race conditions

Epic 想做的是另一種模型。

開發者撰寫 gameplay code 時，表面上像它只跑在一台機器。

底層 Verse runtime 則負責：

transaction

→ object migration

→ rollback

→ re-execution

→ distributed servers

例如某個 object 實際位在另一台 server，runtime 可以 rollback 當前 transaction，把 object 移到適合的位置，再重新執行。

如果這套架構真的成熟，最大的改變並不只是效能。

而是開發者可能不需要在 gameplay code 裡到處手動處理 distributed networking concern。

這就很接近：

把大型 multiplayer backend complexity 吃進語言 runtime。

Epic 目前仍把它描述為正在研究與建立的方向，而不是已完成技術。

但這可能是 UE6 roadmap 裡最值得注意的東西之一。

---

Save Game 甚至可能變成一張 Global Map

同一套 transaction architecture 還碰到 persistence。

Epic 描述的理想情境是：

開發者可以定義：

Player → Saved State

的 global map。

Verse runtime 自己負責同步、儲存與跨 instance 分享狀態。

也就是以前可能需要：

game server

↓

backend API

↓

database schema

↓

persistence service

的事情，部分可能直接變成 language/runtime concern。

如果真的走到這一步，UE6 就不只是 Game Engine。

它開始碰 Backend Platform。

---

第二個大方向：Asset 不再一定屬於某一款遊戲

UE6 的第二條主線更加不像傳統引擎。

Epic 希望：

Content、Code、Economy 都能跨遊戲與跨引擎移動。

他們把 glTF 與 USD 這些既有 open standards 列為重要方向。

如果現有標準能解決問題，就提升為 first-class format。

如果沒有標準，Epic甚至準備把自己的部分 Unreal system 開放成 specification，包括：

Verse API

asset convention

documentation

讓其他 engine、tool 或 studio 也能實作。

這與傳統遊戲引擎哲學有明顯差異。

以前是：

Asset → 專案的一部分。

Epic 希望未來更接近：

Smart Asset

→ 有資料

→ 有邏輯

→ 有功能

→ 可以跨 Experience 使用。

---

第一個實驗品竟然是 Fortnite Skin

Epic 選來證明 portability 的第一個大型案例並不是 geometry format。

而是：

Fortnite cosmetics。

Epic 計畫把 Fortnite Outfit system 移到 open UE6 module。

目標包括：

玩家在 Fortnite 擁有的 Outfit

→ 可能能在其他相容遊戲使用

其他遊戲建立的 Outfit

→ 也能進 Fortnite。

這背後其實不是單純『Skin 跨遊戲』。

它牽涉：

ownership

entitlement

skeleton compatibility

asset standard

runtime behavior

economy

identity

如果連這種複雜系統都能 portable，Epic 就能證明：

跨遊戲 economy 不一定只是 Metaverse PowerPoint。

至少在技術上，它真的可能存在共同規格。

---

第三個方向：AI 不只是功能，而是 Development Pipeline

UE6 的第三條主線就是 AI-assisted development。

但 Epic 的定位非常值得注意。

他們並沒有把 UE6 描述成：

『輸入一句 Prompt，自動幫你做 GTA 7。』

而是把模型定位成：

Creativity and Productivity Multiplier。

目標是拿掉大量 tedious manual work。

例如：

Level setup

Rig setup

Particle setup

Skin weights

Lighting adjustment

Tool scripting

Crash investigation

Automated test generation

Epic 甚至公開提到，他們內部讓 backend、engine、game development 團隊大範圍使用 code generation 與 AI analysis 後，效果最明顯的案例很多並不是讓模型直接寫 mainline engine code。

反而是：

自製工作工具

大型 codebase indexing

incident response

crash root-cause analysis

CI failure analysis

automated tests。

這非常符合大型軟體工程真正浪費時間的地方。

不是每一天都在寫華麗的新 renderer。

大量時間其實死在：

『為什麼 CI 又紅了？』

---

MCP 可能會變成遊戲引擎的新 API Layer

這也是 UE5.8 MCP 最值得注意的地方。

傳統 Unreal automation interface 大多面向：

C++

Python

Blueprint

Editor Utility

Commandlet

未來又多了一層：

MCP。

模型不需要透過模擬滑鼠去猜 Unreal Editor 在哪裡。

引擎可以直接提供結構化工具給模型呼叫。

於是流程可能變成：

Developer

↓

AI model

↓

MCP

↓

Unreal Engine tool

↓

Project state

而且 Epic 強調這套架構應該是 model-agnostic。

也就是你不一定只能用 Epic 自己的 AI。

可能是 Claude。

可能是 Gemini。

可能是 Codex。

未來也可能是其他模型。

引擎變成工具層。

模型變成可替換的 reasoning layer。

這可能比在 Editor 裡硬塞一個固定 chatbot 更有生命力。

---

那 Blueprints 會死嗎？不是現在，但長期真的會變

看到 Scene Graph + Verse，很容易直接得出：

Blueprint 要被殺了？

目前答案是：

短期不會。

Epic 已經清楚表示，早期 UE6 仍會支援 Actors 與 Blueprints。

甚至開發中的 UE5 project 應該有 manageable、clear 的 migration path。

但 Epic 也沒有掩飾長期方向。

當新 framework 成熟後：

Actors / Blueprints

→ eventually deprecated

→ conversion tools

→ Scene Graph / Verse framework。

所以比較精確的理解不是：

UE6 發布 = Blueprint 消失。

而是：

UE6 開始了 Unreal gameplay framework 的長期換軌。

這個換軌可能花很多年。

---

UE6 什麼時候來？

Epic 現在公布的 roadmap 是：

2027 年底：Unreal Engine 6 Early Access

之後約：

12～18 個月：Full Release

因此 UE6 stable release 仍不是眼前幾個月會發生的事情。

Epic 也已經把新的 UE6 development stream 公開在 GitHub。

但官方特別警告：

這不是 Alpha。

只是讓開發者透明看到 Unreal Engine 正往哪裡走。

另一個有趣的 policy 是：

UE5 remaining changes

→ merge into UE6

但 UE6 changes

→ 不反向 merge 回 UE5。

同時 Fortnite 開發也會接到 UE6 stream。

所以從現在開始，UE6 branch 本質上會慢慢變成：

UE5 的下一代技術

＋

Fortnite production technology

的共同實驗場。

---

那 UE6 畫面到底會不會更好？當然會，但那不是故事主角

Epic 明確說 UE6 仍會繼續改善：

Rendering

Cook Times

Iteration Loops

Mobile

Performance

Team Workflow

所以完全不用擔心 UE6 不更新圖形技術。

但如果比較 UE5 與 UE6 的核心敘事，差異其實非常巨大。

UE5 最重要的幾張名片是：

Nanite

Lumen

World Partition

Virtual Shadow Maps

UE6 目前最重要的幾張名片反而是：

Verse

Scene Graph

Distributed Transactions

Portable Content

Interoperability

MCP

AI-assisted workflow

UE5 解決的是：

『我們怎麼建立更大的世界？』

UE6 問的是：

『這些世界建立之後，要怎麼持續活著、互相連接、跨平台存在，而且讓數千人一起維護？』

這是完全不同的問題。

---

從 Game Engine 變成 Game Operating System

如果 Epic 的 roadmap 最終真的完成，到了 UE6 後期，Unreal Engine 這個名稱甚至可能有點低估它。

因為整套東西開始包含：

Rendering

Physics

Animation

World Building

Gameplay Framework

Programming Language

Persistence

Distributed Runtime

Version Control

Asset Portability

Economy

AI Tool Interface

Deployment

Live Ecosystem

這已經越來越像一層：

Game Development Operating System。

遊戲只是跑在上面的其中一種產品。

而 Fortnite 的角色也會變得很奇怪。

它不再只是 Epic 最賺錢的遊戲。

它同時是：

UEFN runtime

Verse testbed

Scene Graph testbed

massive multiplayer test environment

creator economy test environment

portable asset test environment

UE6 的 production laboratory。

Epic 等於拿一個每天有真實玩家、真實創作者、真實金流的大型 live service，提前測 UE6 的核心架構。

這是一般 game engine developer 很難複製的優勢。

---

UE5.8 因此看起來很像兩個世代之間的橋

回頭再看 UE5.8，就會發現很多功能突然很有意思。

MegaLights

→ 讓現有 rendering system 成熟。

Lumen Lite

→ 把 UE5 rendering 往低階平台 scale。

Mesh Terrain

→ 重構 worldbuilding。

PCG / Procedural Vegetation

→ 讓內容生產更 procedural。

MCP

→ 提前建立 AI tool interface。

shader compilation optimization

→ 改善大型 production iteration。

這些看似互不相關的 feature，最後其實都指向同一個需求：

讓更大的團隊，用更少人工摩擦，維護更大的世界。

Epic 在 UE5.8 甚至透過 shader compilation 與 deduplication 改進，把 Fortnite 的 shader 數量削減了 68%。

這種數字沒有 Nanite demo 那麼性感。

但對真的每天 build 一個巨大遊戲的人而言，這種改進可能更重要。

---

UE6 真正要解的，不是 Polygon 數量

UE5 世代最有代表性的宣傳畫面，是 Nanite 場景裡數以億計的 triangles。

但到了 UE6，真正困難的 scale 可能已經不是 geometry scale。

而是：

Team Scale

World Scale

Server Scale

Content Scale

Economy Scale

Tool Scale

Live Operations Scale。

一個 500 人團隊做一款遊戲已經很複雜。

如果未來是：

數千名 contributors

＋

持續十年的 persistent world

＋

跨遊戲 asset

＋

跨遊戲 economy

＋

AI-assisted development

＋

multi-server simulation

那麼最大的問題早就不是：

『GPU 能畫幾個三角形？』

而是：

整個軟體系統怎麼不要在自己的複雜度下坍塌。

這也許才是 Unreal Engine 6 真正想解決的問題。

它不是讓 UE5 多畫 30% polygon。

而是試著重新定義：

未來十年的遊戲，到底要怎麼被製作、連接、發布與持續運作。

---

本文 Tech English

Scene Graph｜場景圖／場景關係圖
以結構化關係描述遊戲世界中的 objects、components 與 hierarchy。UE6 的新 Scene Graph 將建立在 Verse 上，成為下一代 gameplay framework 的核心之一。

Software Transactional Memory, STM｜軟體交易記憶體
用 transaction 處理共享狀態的 concurrency 模型。操作可以以 atomic transaction 執行，失敗時 rollback，再重新執行。Epic 正研究把這種概念延伸到分散式 UE6 runtime。

Interoperability｜互通性
不同程式、遊戲、引擎與生態系統之間交換並使用相同內容、資料或功能的能力。UE6 希望讓 content、code 甚至 economy 能跨 ecosystem 移動。

Model Context Protocol, MCP｜模型上下文協定
讓 AI 模型以結構化方式存取工具、資料與應用程式能力的協定。UE5.8 已加入 Experimental MCP plugin，並被 Epic 視為 UE6 AI-assisted workflow 的重要基礎。

Persistent World｜持續性世界
即使玩家離線或特定 server instance 結束後，世界狀態仍持續存在的線上環境。這類系統通常需要大量 backend、database 與 synchronization infrastructure。

Gameplay Framework｜遊戲玩法框架
管理 game object、logic、state、interaction 與 lifecycle 的底層程式架構。UE6 計畫以 Verse 與 Scene Graph 建立新的 framework，長期逐步取代部分現有 Actor／Blueprint 架構。