RPG 遊戲引擎比較：RPG Maker、Godot、Unity、Unreal 與瀏覽器建造器

選擇 RPG 遊戲引擎，大致上就是在決定三件事：美術如何製作、由誰來寫程式，以及完成的遊戲要在哪裡運行。選項可以清楚切分。RPG Maker MV 與 MZ 是 2D 編輯器，內建了現成的 RPG 系統。Godot、Unity、Unreal 與 Phaser 是需要你自己撰寫程式的通用引擎。Ren'Py 是以對話為先的引擎，把一款遊戲當成劇本來看待。瀏覽器建造器則完全免去安裝與建置步驟。

本頁會就真正決定一個專案走向的要素來比較這些路線：成本與授權、是否會碰到程式碼、2D 或 3D、能匯出什麼，以及多久能做出可玩的東西。凡是數字只能靠猜的地方，我們改為描述其運作機制。如果你想在投入某款引擎之前先看到一個世界跑起來，靠近頁尾的免引擎章節會是你該先讀的部分。

快速解答

如果這款遊戲是帶有數值、道具與對話框的俯視角 2D RPG，RPG Maker MV 或 MZ 能最快做出可玩場景，因為資料庫與事件系統本身就為這些系統建立了模型。如果你想要掌控渲染器與規則，又不願為任何一方付費，Godot 是最便宜、又不會把你鎖進某種格式的路線。當涉及團隊、主機送審或中介軟體時，Unity 與 Unreal 才合理。當 RPG 是一個網頁、而你又已經會寫 JavaScript 時，Phaser 就是答案。當遊戲以文字與分支選擇為主時，Ren'Py 就是答案。

下表涵蓋七條路線：RPG Maker MV/MZ、Godot、Unity、Unreal、Phaser、Ren'Py，以及產出是網頁而非建置檔案的瀏覽器建造器。欄位包括成本與授權、是否需寫程式、2D 或 3D、目標平台，以及達到首次可玩的時間。最後一欄請解讀為「讓一個可操控角色連同碰撞與一個可互動物件出現在畫面上」的時間，而不是完成一款遊戲的時間。多數 RPG 專案卡關是在系統，而非渲染，所以請把這張表當成篩選器，並把後面的章節當成做決定的依據。

比較表

這張表中有兩個欄位值得提出警告。Unity 的 Web 建置目標確實可用，但即使是規模不大的 2D RPG，其 WebAssembly 建置在素材壓縮前通常也會落在數十 MB 之譜；而啟用執行緒的建置需要跨來源隔離標頭（COOP 與 COEP），許多靜態主機預設並不會送出這些標頭。症狀會是一塊空白畫布，以及一則關於 SharedArrayBuffer 的主控台訊息，而不是明確的錯誤。Godot 的執行緒版網頁匯出有同樣的標頭要求，這也是 Godot 專案能在本機運行、卻在免費主機上失敗最常見的單一原因。

Unreal 的 HTML5 匯出在 4.23 到 4.24 那個時期已被移除，而且沒有受支援的替代方案，所以在 Unreal 中打造的 RPG 只能以二進位檔或透過商店平台發布。如果散布模型是一個連結，那這在你寫下任何一行程式碼之前，就已把 Unreal 從候選名單中剔除。

RPG Maker 的瀏覽器部署會在一開始就把整棵素材樹送出。對小型專案來說沒問題，但對擁有長篇配樂的專案就很痛苦，因為音訊在遠早於地圖之前就主導了載入量。請把首次載入、而不是影格率，列為你第一個要處理的效能問題。

2D 與 3D RPG 引擎

渲染器只是便宜的那一部分。Godot 與 Unity 都能在同一次下載中渲染 2D 與 3D，而把相機從透視切換成正交也只是改一個屬性。2D 與 3D RPG 之間的差異，在於渲染器上游的一切：素材如何製作、需要多少人手，以及一項變更要多久才會顯現出來。

2D 路線意味著精靈圖表與圖磚集。一個會朝四個方向行走的角色，通常每個方向需要三個影格，總共十二個影格，以 16x16、32x32 或 48x48 像素繪製。匯入設定比美術本身更重要：像素藝術請把篩選模式設為 Point（不篩選），並將壓縮設為 None，否則編輯器預設的雙線性篩選會把每塊圖磚都弄糊，讓你花一整晚怪罪美術。迭代很快，因為新圖磚只要畫好、丟進資料夾就行。一張每格 32 像素的 100x100 地圖，是 3200x3200 像素的影像，記憶體成本確實不小，但仍在可控範圍。

3D 路線意味著網格、骨架、蒙皮權重與動畫片段。一個角色需要一個網格、一副骨架，以及至少待機、行走與攻擊三種片段。如果你不打算授權使用現成素材庫，那就是在任何遊戲玩法存在之前先花上的建模時間。迭代在兩個方向上也都更慢：當一個網格改變時，光照、細節層級網格與碰撞形狀全都要重新檢查。回報是：一台能做到圖磚網格做不到的事的相機，以及一條能接受掃描或拼湊環境的製作流程。

實際的問題不在於哪一種看起來更好，而在於你在首次可玩的那一小時之後，預期還要改動多少素材。一個 2D 專案能便宜地吸收數十次變更。一個 3D 專案吸收十幾次之後，就會開始讓你每次付出一個星期的代價。

RPG Maker 把你綁定在 2D，而這其實是一項優點：地圖編輯器、自動圖磚與角色集全都假設是圖磚網格，所以你唯一必須製作的素材類型就是圖磚集。Unreal 則把你推向 3D——Paper2D 雖能渲染精靈圖，但光照、物理與動畫工具鏈都是圍繞網格打造，所以在那裡做 2D 遊戲是在跟引擎對抗。

Godot 與 Unity 是唯二讓你之後再決定的選項，但這是有代價的。把原型從精靈圖切換到網格，意味著要重建碰撞、重新調校相機距離，並重新製作每一個動畫，因為精靈圖表的影格數與骨架的片段長度毫無共通之處。請在打造第一場戰鬥遭遇之前就選定維度，而不是之後。

你需要寫程式嗎？

不需要，直到你想要某個工具尚未建立模型的東西那一刻為止。RPG Maker 的事件系統是一份帶有條件、開關與變數的指令清單，你無須打任何一行程式碼，就能建出一條任務鏈、一間商店與一場回合制戰鬥。牆會出現在資料庫無法表達的自訂選單版面與戰鬥公式上；到了那個時候，你就是在編輯 JavaScript 外掛檔案，並把它們註冊到外掛清單中，那是外掛作者的工作，而不是新手的工作。

Unreal 的 Blueprints 最接近一款具備完整視覺化腳本層的通用引擎。你可以把整個 RPG 的邏輯都建成節點圖，而它與 C++ 的效能差異，只有在每個影格、每個角色都執行的程式碼中才會顯現，例如大量人群或投射物的迴圈。Unity 的視覺化腳本是一個套件加上第三方素材，而多數教學與論壇解答都假設你使用 C#。Godot 完全沒有內建的遊戲邏輯節點圖；GDScript 才是正途，而且它的語法刻意貼近 Python。Phaser 從第一行就是程式碼。Ren'Py 的腳本格式讀起來更像電影劇本而非程式，並以 Python 處理各種邊角狀況。

還有第四個選項，不屬於「節點圖對比程式語言」的那種分野：描述這款遊戲，讓工具來建構它。Neta Studio 的 3D 遊戲建造器接收一段文字描述，並產出一個在分頁中以 Three.js 運行的世界。你透過描述來做出變更，而不是打開場景檔案、到處尋找正確的檢視器面板。當你需要對傷害公式做到影格級精確控制時，它是節點圖的拙劣替代品；但它也是大多數專案在初始設定上白白損失的那兩個星期的絕佳替代品。

Ren'Py 是最明顯的例子。一個專案就是一個裝滿純文字腳本檔案的資料夾；你可以用任何文字編輯器加上啟動器來撰寫並運行它，而啟動器唯一必須做的工作就是啟動遊戲。Phaser 是第二個例子：一個專案就是一個裝滿 JavaScript 的資料夾與一個 HTML 檔案，而瀏覽器就是編輯器。這兩條路線都沒有視覺化的地圖繪製工具，但兩者也都不要求你安裝一種在文字編輯器裡讀不了的專案格式。

RPG Maker 不符合，因為資料庫、地圖與事件頁面都存在於編輯器的專案格式中。瀏覽器建造器則反其道而行：描述本身就是專案，而編輯器就是你早就在看的那個文字欄位。如果你避免使用編輯器的理由是不想再學一套，那這個區別比功能清單更重要。

匯出與發布

你匯出什麼，就決定了玩家在能玩之前必須先做什麼。RPG Maker 透過 NW.js 部署 Windows 與 macOS 建置，瀏覽器與行動裝置部署則取決於版本與社群工具。瀏覽器部署是一個 HTML 檔案、一個 JavaScript 執行環境，以及專案的影像與音訊目錄——可放在任何靜態伺服器上，但素材會在標題畫面出現之前先行下載。

Godot 透過儲存在 export_presets.cfg 中的預設集進行匯出。網頁匯出會產出一個 HTML 外殼、一個 .wasm 二進位檔，以及一個包含專案資料的 .pck 檔案。Godot 4 的執行緒版網頁匯出需要 SharedArrayBuffer，這要求主機送出 COOP 與 COEP 標頭。少了它們，你要嘛改出單執行緒建置，要嘛頁面永遠不會啟動。Unity 的 Web 建置會經過 IL2CPP，產出 WebAssembly 加上一個資料包，同樣有執行緒的標頭要求，忽略它的後果也相同。

Unity 兩個實務上的網頁問題是初始載入與記憶體。一個在啟動時載入所有東西的場景會在第一個影格卡住；可定址素材與場景分割才是解法，而不是把建置縮小。Unreal 為桌上型電腦與主機匯出原生二進位檔，並沒有受支援的瀏覽器目標。Phaser 什麼都不用匯出，因為那些檔案本來就是網頁檔案——部署就只是複製一個資料夾。Ren'Py 會依其建置設定產出各平台的發行檔，包括網頁建置，並把素材與執行環境一起打包。

如果你要發布到靜態主機，請在測試遊戲之前先測試標頭。一個會設定 COOP 與 COEP 的本機伺服器，會掩蓋一個只在正式環境才會出現的主機問題。

免引擎選項

有一條路線，上述全都不適用，因為沒有引擎要安裝、沒有專案資料夾，也沒有匯出預設集要設定。Neta Studio 的 3D 遊戲建造器接收一段文字描述，並產出一個在瀏覽器分頁中以 Three.js 渲染的世界。產出就是一張網頁。你把連結傳給別人，世界就會開啟；他們不必下載壓縮檔、不必執行安裝程式，也不必決定要不要信任一個執行檔。

這改變了工作的樣貌。編輯之後沒有建置步驟要重跑，也沒有平台專屬的匯出要維護。你描述地形、相機角度、光照、存在哪些角色，以及玩家能做什麼；建造器組出場景圖，並由 Three.js 繪製。Agent Sprite Forge 涵蓋了在美術出現之前就需要一個角色或道具的情況，而 Mini World 與 The Cyclops' Island 是可遊玩的世界，你可以打開來看看相機、地面與移動已經在運作。

在大型 RPG 上，這並不是 Godot 或 Unity 的替代品。具有精確數值需求的系統——傷害公式、必須跨版本保持相容的存檔格式、帶有十幾種互相作用狀態的戰鬥狀態機——仍然需要真正的腳本層。它移除的是在那之前的那個階段：世界還不存在，而你看不出相機的觀感是否成立、尺度感覺是否怪異。

如何在十分鐘內做出選擇

依序看過以下幾點，並在第一條能定案的敘述就停下來。多數專案在前兩條就能定案。

走進它所屬的那個世界

在有一列真正跑起來之前，引擎比較都只是一張表。瀏覽器那一列是你無須安裝任何東西就能測試的：打開一個用一句話描述、並以網頁形式匯出的世界。那正是表中最後一列的實際感受。