2026 年最值得用的體素遊戲引擎——外加一款完全不用安裝的

體素遊戲引擎可以分成三類：專門做體素的引擎、本身是通用引擎再外掛體素層、以及在分頁裡直接算圖、什麼都不用裝的瀏覽器世界。專門引擎在第一天就給你區塊儲存、網格生成和光照傳播，然後用這些東西把其他一切框住。通用引擎給你一整套工具鏈，再把區塊管線當成作業丢給你。瀏覽器世界則直接跳過安裝與建置步驟。

本頁比較 Hytopia、Noa、Luanti、Godot 加體素外掛，以及 Unity 加體素外掛：各自到底是什麼、你在裡面寫什麼、以及時間會花在哪裡。最後是瀏覽器選項——一個你在描述完它的同一分鐘內就能打開、走進去逛的世界。

快速回答：你該用哪一款體素引擎？

專用體素引擎，例如 Noa 或 Luanti：當世界資料本身就是產品，而你又不想在看到任何畫面之前先自己寫網格生成器、區塊串流和 flood-fill 光照時，就用它。

通用引擎加體素外掛，例如 Godot 或 Unity：當你需要動畫、UI、物理、音訊、輸入映射與多平台匯出，並且願意在別人的主迴圈裡自己管區塊管線時，就用它。

永遠不用安裝的瀏覽器世界，例如 Neta Studio 的 3D 遊戲建構器：當第一道障礙是「先讓另一個人看到這個世界」時，就用它——一條連結比一次下載、一套工具鏈、一道建置步驟都便宜。

決定性的因素是：你的關鍵路徑上擺的是什麼。如果難的是內容，就選那條從想到到能走進去之間距離最短的管線。如果難的是模擬——成千上萬個會互相作用的方塊、自訂物理、可決定性的連線狀態——就選你能夠 profile、能改、能重新編譯的工具組。

引擎比較

以下五個選項，按形態描述而不是排名。它們都會算圖體素。差別在於它們交給你什麼，以及它們期待你回饋什麼。

先看語言那一欄。它決定了你在不動原生建置步驟的前提下能改動多少執行環境，而那又決定了你凌晨兩點要怎麼除錯。

Hytopia

Hytopia 是一套代管式的體素遊戲平台，附 JavaScript 與 TypeScript SDK。世界是體素構成的，客戶端跑在瀏覽器裡，多人連線是平台的一部分而不是你自己加上去的功能：你對著 SDK 的 entity 與 player API 寫遊戲邏輯，伺服器由平台處理。代價是你的遊戲活在他們的執行環境上。你設定它、寫腳本給它跑，但你不會拿到引擎的獨立執行檔。

Noa

Noa 是一套以 Three.js 為基礎、瞄準瀏覽器的 JavaScript 體素引擎。它處理區塊化地形、網格生成、entity 系統，以及簡單的碰撞與重力，其餘的要你自己帶進來：算圖設定、輸入、遊戲規則、連線。它的 API 小到可以從頭讀到尾，這才是它真正的優勢。當某個地方行為怪怪的，問題出在你能打開來看的程式碼裡，而不是黑盒子裡。

Luanti（原名 Minetest）

Luanti，原名 Minetest，是一套開源體素平台而不是單一款遊戲。引擎本體是 C++，但玩法以 Lua 寫成的 games 與 mods 的形式出現，所以你可以改方塊行為、合成、entity，而不用重新編譯。它的世界是 16x16x16 mapblock 組成的節點網格，伺服器透過網路把區塊串流給客戶端。你可以在本機跑伺服器，同一份伺服器程式碼也能跑在租來的主機上。active_block_range、max_block_send_distance 這類設定值決定玩家能看多遠，以及客戶端要吃多少 RAM。

Godot 加體素外掛

Godot 核心引擎沒有體素地形。要自己加：看是要用社群 addon 來生成區塊網格，還是自己寫 mesher 產生 ArrayMesh 表面再加上碰撞形狀。Godot 給你圍繞在體素周邊的那些東西，也就是場景樹、AnimationPlayer、UI、物理 body、輸入、匯出範本，再加上 GDScript、C#，或透過 GDExtension 用 C++ 寫 meshing 程式碼。區塊網格生成要放在工作執行緒或 WorkerThreadPool 任務上。放在主執行緒做，就是玩家跨過區塊邊界時卡頓的常見原因。

Unity 加體素外掛

Unity 是同一套故事，只是工具鏈更重。體素地形來自外掛或你自己的區塊系統；比較有生產力的路線是用 C# Job System 裡經 Burst 編譯的 job，在工作執行緒上產生網格資料，再用 Mesh.SetVertices 之類的呼叫上傳。碰撞是反覆出現的麻煩：每個區塊一個 MeshCollider 的 cook 成本很高，所以很多專案乾脆自己寫針對方塊網格的體素 raycast 與 AABB 碰撞。你換到的是 Unity 的動畫、UI、混音器，以及跨桌面與網頁目標的建置管線。

不用安裝任何東西就能玩體素世界

判斷自己到底想不想做體素世界，最快的方法就是站進一個裡面。Neta Studio 的 3D 遊戲建構器跑在瀏覽器分頁裡。你打一段對世界的描述——地形、氣氛、建築——建構器就生成一個可以玩的 Three.js 場景，你用 WASD 加滑鼠在裡面走。不用 SDK、不用裝編輯器、不用建置步驟、沒有要先接好的素材管線。

你拿到的是真的幾何，不是影片。你會跟它碰撞，會把攝影機推著穿過它，而且靠描述就能改它——把水位拉高、加一座橋、把山谷拓寬——然後重新生成。Agent Sprite Forge 補上 2D 那一層：給 agent、道具和拾取物用的精靈圖，這樣場景才不會卡在等美術。Mini World 是最小的 demo，也是筆電上該先試的目標。The Cyclops' Island 是規模較大、手工雕過的世界，可以看見地形與光照不再是平的時候，場景會長什麼樣。

它做不到的事：它不會給你專用引擎那種方塊層級的腳本 API，也不會產出能上商店的獨立執行檔。它是管線裡「看過再改」的那一端，也是最快能讓另一個人看懂你說的體素世界是什麼的方法。

真正該在意的事

有四項性質決定一款體素引擎到了第三個月是順手還是痛苦。它們沒有一項會出現在功能表上，而且全都在你投入之前就能量測。

世界大小

儲存便宜，串流不便宜。一個世界通常切成 16x16x16 或 32x32x32 方塊的區塊，引擎讓一定半徑內的區塊常駐。記憶體大致隨半徑的三次方成長，所以視距加倍大約是方塊資料變八倍，還沒算網格。座標也要注意：float32 位置離原點太遠會掉精度，表現出來就是攝影機抖動和 z-fighting，大概在十萬單位之外就開始。引擎通常用原點重定位或相對攝影機算圖處理這件事。在規劃一整塊大陸之前，先查清楚你手上那款是用哪一種。

光照

體素光照通常是 flood fill。每個方塊存一個光照等級，陽光往下傳播直到碰到不透明方塊，火把往外傳播並衰減。每個方塊的成本很低，但要維持正確卻很貴。玩家放上或移除方塊時，該區塊和鄰接區塊的光照都得重算；如果你漏掉鄰接區塊，光就會從邊界漏出去，變成一條亮縫。如果引擎把光烘進頂點色，那每次編輯都得重新烘一份網格。如果是在 shader 裡做光照，你付出的是 uniform 上限和額外的 draw call。

多人連線

體素多人連線基本上是頻寬問題。伺服器是權威：方塊網格由它持有，客戶端送的是意圖而不是位置。只有編輯會以 delta 傳送，而且只有興趣半徑內的區塊會被送出，所以流量是隨玩家人數乘上視距成長，而不是隨世界大小成長。兩個客戶端在同一個 tick 挖同一個方塊是真實情況，你必須定義答案。如果你選的引擎沒有連線功能，那興趣系統、delta 格式和客戶端預測都得你自己寫。那是一個專案，不是一個功能。

能在瀏覽器裡跑

瀏覽器目標移除了安裝步驟，而當你叫別人試玩你的世界時，安裝就是最大的流失點。代價是預算更小：WebGL2 的 draw call 數量、除非你為 SharedArrayBuffer 設好跨來源隔離否則只有一條主 JavaScript 執行緒、以及每一份素材的下載量。目前的桌面瀏覽器大多有 WebGPU，但並不齊一，所以留一條 WebGL2 後備路徑仍是常規做法。世界能在分頁裡跑，你就能用一則訊息把它送出去。需要啟動器的，做不到。

體素沙盒 vs 體素引擎

體素沙盒是一款剛好用方塊做成的完成品遊戲。你下載它、玩它，方塊種類就是開發者出貨的那一套。體素引擎是一組工具：區塊儲存、meshing、算圖器，以及你對著寫的 API。這個區分重要，是因為搜尋結果對兩者用同一組字。

頁面上的訊號。如果有啟動器和截圖牆，那是沙盒。如果有 API 參考、類別名稱、和一個可以安裝的套件，那是引擎。如果方塊型別是你編輯的資料檔，而不是你註冊的執行期物件，那就告訴你這項產品活在哪一層。如果有匯出或獨立建置的路徑，你買的是工具組。如果唯一能發布的方式是在他們的平台裡，你租的是工具組。

混合型很常見，也值得點名。Luanti 是一個平台：引擎是工具組，隨附的 games 是蓋在它上面的沙盒，你選擇要在哪一層工作。Hytopia 同時是 SDK 和代管執行環境，所以你寫的是引擎層級的程式碼，跑在別人的伺服器上。瀏覽器建構器在最偏內容的那一端，產出的是世界而不是系統。在比較功能表之前先決定你想擁有哪一層，因為一個附好編輯器的沙盒，不能替代一個有 API 的引擎。

走進它該屬於的那個世界

精靈圖是一個無處可站的角色。最後一步是別人沒提供的：把你剛做好的那張精靈表放進一個有人能走來走去的世界——一座小島、一顆行星、一個下雨的街角。這個網站上的每個世界都是從一段文字描述做出來，再發布成一個可以直接玩的頁面。

常見問題