Cinevva 把引擎選型變成堆疊

我拆 Cinevva 的 2026 web game engines guide，整理成可直接套用的 2D、3D、Wasm 引擎選型堆疊與模板。

我用 web 遊戲引擎一陣子了，最煩的不是功能少，而是比較表都在騙我。Demo 看起來很順，功能列一長串，真要上線就開始出事：載入慢、手機 Safari 怪、下載包一大坨，玩家還沒看到畫面就先被你勸退。這種引擎 roundup 我看多了，常常像在列菜單，不像在幫我做決策。

我會拆 Cinevva 的 2026 web game engines guide，是因為它至少沒有假裝所有引擎都在解同一題。它把市場切成 browser-first 3D、2D、Wasm 效能、no-code 工作流，這才是正常思路。真正有價值的不是「誰最強」，而是誰能少讓我跟瀏覽器吵半年。

這份指南裡最值得我記下來的轉折很簡單：WebGPU 不再是未來式。Cinevva 提到 Safari 26 已經在 macOS、iPadOS、iOS、visionOS 加上 WebGPU 支援，這件事直接改掉我對 2026 年 web 遊戲的預設判斷。不是說每個團隊明天都該切 WebGPU，而是「因為 Safari 所以只能守著 WebGL」這個老理由，現在真的站不住腳了。

WebGPU 不是加分題，是新底線

WebGPU 已經不是實驗室玩具。Safari 26 把支援補上後，過去那句「先別碰 WebGPU，Safari 會死」基本上可以收起來了。

白話講就是，現在卡你的不再是瀏覽器，而是引擎自己有沒有把路鋪好。這差很多。我看過太多規劃會議一直說「等瀏覽器成熟再說」，結果瀏覽器早就成熟了，真正沒動的是引擎團隊跟整條管線。

我把 WebGPU、Safari 和引擎支援一起看，2026 的答案其實很清楚：PlayCanvas 的 WebGPU 路徑最成熟，Godot 4.7 有 experimental WebGPU web export，Three.js 也有零設定的 WebGPU renderer 跟 WebGL2 fallback。這代表我終於可以把 WebGPU 當部署選項，不用再把它當研究題目。

我之前做過一個 3D configurator，舊版技術上沒問題，但一到手機就開始跟 texture size、shader 限制、載入時間互相折磨。那時候如果有一條夠順的 WebGPU 路徑，體驗會好很多，但前提是引擎不能逼我整個重寫。這就是現在的篩選標準：引擎到底幫我藏掉多少痛苦。

實操寫法：

• 如果你做 browser-first 3D，先看 WebGPU 是真的能用，還是只在 roadmap 上。
• 如果你現在就要覆蓋廣泛裝置，WebGL2 fallback 仍然要留著。
• 如果引擎只在簡報裡提 WebGPU，我會直接假設整合成本要自己吞。

PlayCanvas 只適合把瀏覽器當主戰場的人

PlayCanvas 在 browser-first 3D 這件事上很兇：runtime 小、WebGPU renderer 最像能上線的樣子，還有協作式 cloud editor。

白話講，PlayCanvas 是給那些真的把瀏覽器當終點的人，不是把 web 當匯出格式的人。我很吃這種態度。很多工具都說自己支援 web，但「支援 web」跟「為 web 而生」不是一回事。誰做過 WebGL scene，誰就知道啟動慢一點，整個產品感受就爛掉一截。

這份指南也點到 PlayCanvas 的小 runtime、cloud editor、以及最近的 WebGPU 進展，官方站在 PlayCanvas，文件在 developer.playcanvas.com，原始碼在 GitHub。我特別在意 cloud workflow，不是因為它聽起來很潮，而是因為它真的少掉一堆版本地獄：不用一直 export、傳檔、問誰拿到最新檔。

我用過 rendering 很強、workflow 很爛的工具，最後通常變成技術上很漂亮、維護上很痛苦的 prototype。PlayCanvas 比多數工具更少踩這個坑。它不是所有遊戲都適合，尤其不是深度 2D 系統的首選，但如果你做的是 product demo、互動場景、web-native 3D，它的下載量和現代 renderer 組合很難打。

實操寫法：

• 如果你的第一個 KPI 是 browser 裡的 time-to-interaction，就先看 PlayCanvas。
• 如果團隊很重視 editor workflow，它比很多引擎更順手。
• 不要為了 runtime 小，就硬拿它去扛複雜 2D 遊戲。

Godot 是最穩的全能選項，但不是萬能藥

Godot 是目前最完整的免費引擎之一，2D 和 3D 都能打。

白話講，Godot 是你想要自由、工具夠用、又不想跟授權條款玩猜謎時，最不煩的選擇。Cinevva 提到 Godot 的 MIT 授權、強 2D、WebAssembly 加 SIMD 預設，以及 4.7 的 experimental WebGPU export，這包裝起來真的很能打。但它還是有代價，不是免費就等於沒問題。

指南也沒裝好人：C# web export 還不行、WebGPU 還是 experimental、Safari/iOS 仍然麻煩。我喜歡這種誠實，因為太多「最佳引擎」文章都把 open source 說得像零摩擦。根本不是。你只是可以看 source，同時還是要自己處理 export 變肥、threading 需要 COOP/COEP headers 這些鳥事。

我跑過 Godot web build，桌機上很舒服，一到中階手機就把我 asset 做得多粗糙這件事全部照妖鏡照出來。那不是 Godot 的錯，是在提醒我：引擎自由不會幫我免掉瀏覽器限制。好處是 Godot 給我的控制權夠多，不用跟授權層級低頭。

實操寫法：

• 你要同一套引擎同時做 2D 和 3D，又不想被 vendor lock-in 綁住，就先看 Godot。
• 做 web export 時先用 GDScript，除非你已經準備好處理 C# 限制。
• 資產裁切和手機測試要提早做，不要等內容都補完才開始救火。

Defold 是我在乎載入速度時會先拿的工具

Defold 的 build 最小，大約 1.14 MB，而且載入最快。

白話講，Defold 很兇地只做好一件事：讓玩家在看到第一個畫面前不要等太久。Cinevva 比 empty build 的細節我很喜歡，Defold 大約 1.14 MB、Unity 約 8 MB、Godot 約 9 MB，這幾個數字其實已經把使用者體驗講完一半了。

Defold 的 runtime 很小，預設用 WebAssembly，也能直接發到像 Poki 這類平台。代價也很明顯：社群比較小、Lua 要適應、架構不能亂來。我不介意這些，老實說我還比較喜歡。會逼你守紀律的引擎，通常後面比較不會讓我自己收拾殘局。

我做過一些 casual 專案，第一秒體驗比什麼 fancy 系統都重要。那種情境下，Defold 很適合幫我守住「一打開就能玩」這個承諾。流量如果會很亂、裝置如果很雜、我又不能接受啟動流程太肥，它就會是我優先考慮的工具。

實操寫法：

• 做 mobile-first web game 或 casual game，先看 Defold。
• 當啟動速度比 editor 功能更重要時，它通常比大而全的引擎好用。
• Lua 和效能調校要提早排進時程，不要等場景長大才開始補。

Phaser 還是 code-first 2D 的正常答案

Phaser 是一個功能完整、社群最大的 batteries-included framework。

白話講，如果你想寫 code、做 2D 遊戲、又不想自己從零拼基本系統，Phaser 還是最省事的預設解。Cinevva 提到 Phaser 4 在 2026 年 4 月已經 stable，上了重做過的 WebGL renderer，而且 API 形狀還跟 v3 很接近。這種升級路線我很買單，因為新版本但舊手感，學習成本不會突然翻車。

指南也提醒一件重要的事：Phaser 4 是 WebGL2，不是 WebGPU。這很重要，因為我看過太多人以為「新版」就等於「新圖形 backend」，結果把功能排進時程，最後才發現根本沒那回事。Phaser 的價值還是在 code-first 2D，physics、input、audio、scene management、ecosystem，這些才是它厲害的地方。

我用 Phaser 的時候，通常是我想快，但又不想被 visual editor 綁住。它不是最小，也不是最漂亮，但它會乖乖讓路。對我來說，這很值錢，尤其當我在做的是 game loop，不是展示片。

實操寫法：

• 你要 batteries included，但還是想保留 code 控制權，就選 Phaser。
• 適合標準 2D、原型、browser-friendly 的 arcade mechanics。
• 不要因為版本新，就預設它有 WebGPU。

PixiJS 是我已經知道架構時才會拿的渲染器

高效能 2D rendering library。

白話講，PixiJS 根本不是想當完整遊戲引擎。它就是渲染工具，而它之所以一直有用，就是因為它知道自己只負責這一塊。Cinevva 把它放在 JavaScript frameworks 那類，是有道理的：如果我要的是低負擔，而且我自己願意把其他系統補齊，PixiJS 會很銳利。體積小是一回事，真正的好處是我不用替它付那些我根本用不到的系統成本。

但缺點也很直接。PixiJS 不會替你把整個 game architecture 打包好，你要自己處理 input、scene、state、gameplay logic。對某些專案，這正好；對另一些專案，這就是假裝自由的陷阱。

我在一些 rendering 效能很重要、但 gameplay layer 很薄的專案上用過 PixiJS。那種情境它很順，因為我已經知道我要什麼，只想讓引擎少講話。

實操寫法：

• 你要自訂 2D rendering 或 UI-heavy experience，就看 PixiJS。
• 你想自己掌控架構，而不是直接繼承別人的框架，就用它。
• 如果團隊期待的是全包式引擎，就別拿它硬湊。

no-code 引擎不是玩具，是為了真的把東西做完

Construct 和 GDevelop 可以用視覺化方式做 2D 遊戲，不需要寫程式。

白話講，視覺化工具不是低一階，只是它們解的題目不同。Cinevva 把 Construct 和 GDevelop 當成能上線的 2D 與快速原型工具，不是玩具。這點我認同。太多開發者一看到 no-code 就翻白眼，然後花三週重做一個下午就能拼好的 UI flow。

Construct 的 event-sheet 模型，適合你要快、邏輯又相對直白的情境。GDevelop 則多了 open-source 的彈性，還有越來越多 3D 和 multiplayer 的支援。它們都沒假裝自己能扛超大型 simulation，這種誠實反而是價值的一部分。

我不會在要極致控制時選它們，但如果我是要驗證 mechanic、做 playable prototype，或是要把專案交給不該先學整套 codebase 的人，這類工具會比你想像中更實用。這不是比較差，只是約束不同。

實操寫法：

• 想最快把 2D idea 變 playable，就先看 Construct。
• 想要 no-code 又想保留 open-source 彈性，就看 GDevelop。
• 不要再假設每個專案一開始都需要 code-first 架構。

我會怎麼把這份指南變成選型規則

這篇指南真正有用的地方，不是它列了多少引擎，而是它逼你先定義「你到底要交付什麼」。我自己現在看 web game engine，第一個問題不是誰最強，而是：我要的是 browser-first 3D、2D、Wasm performance，還是 no-code？這四種題目，答案本來就不該一樣。

如果你把這個順序反過來，先選引擎再想產品，後面一定會痛。因為引擎會開始反過來定義你的限制：包體多大、支不支援 WebGPU、手機 Safari 能不能活、是不是得自己寫一堆基礎系統。那時候再改，通常已經晚了。

我自己現在會這樣切：

• browser-first 3D：先看 PlayCanvas
• 全能免費引擎：先看 Godot
• 載入速度優先：先看 Defold
• code-first 2D：先看 Phaser
• 自訂渲染與極簡架構：先看 PixiJS
• 快速原型或 no-code：先看 Construct / GDevelop

這套不是神諭，只是我覺得比較不會把自己帶進坑裡的排序。你如果一開始就把 delivery target、browser support、runtime size、WebGPU 路徑講清楚，很多爭論其實會自動消失。

可抄的模板

# 2026 web game engine 選型模板

這段我真的會直接貼進規劃文件。它逼團隊先回答那些很煩、但一定要先講清楚的問題。引擎選型本來就該在這裡發生，不是在三週 feature 做完後，才跑去 iPhone 上面驚慌失措。

來源致謝：原始內容來自 Cinevva 的 https://app.cinevva.com/guides/web-game-engines-comparison。我上面做的是拆解、重排跟實務化；模板與選型規則是我的衍生整理，不是原文逐字引用。