適合 AI 開發的開源遊戲架構：Web、編輯器橋接與自動檢查全解析
我們在之前的 告別 Vibe Coding！Agentic SDLC 完整架構解析 中深入探討過，如何透過狀態機與自動化驗證閘門，讓 AI Coding Agent 穩定交付軟體。但當你把這套流程搬到遊戲開發時，很多人會立刻碰壁：
在一般的 Web 或後端專案裡，AI 只要跑單元測試、看編譯錯誤或打 API，就能知道自己有沒有做對；但遊戲不一樣，遊戲是高度依賴畫面、空間布局與即時反饋的產品。如果你叫 AI 在傳統遊戲引擎裡做一個 3D 場景，它常常只會丟出一堆坐標重疊的方塊、漏掉貼圖，最後整個畫面亂成一團。
這不是因為 AI 不會寫遊戲程式碼，而是因為大部分傳統遊戲引擎，在誕生之初就不是為了給 AI Agent 操作而設計的。
核心痛點：遊戲開發最缺的不是寫程式，而是「看不見結果」
在討論技術選型時，大家常問：AI 比較會寫 C#、GDScript 還是 TypeScript？
但這完全問錯了方向。在遊戲開發中，真正的痛點只有一個：
AI 寫完程式之後，到底能不能看到遊戲畫面，並確認角色有沒有掉出地圖？
如果 AI 寫完程式碼，根本不知道畫面長什麼樣子，那它每改一次都只能靠盲猜。相反地，如果環境能讓 AI 自動截圖、讀取錯誤訊息、模擬玩家點擊，它就能像真人工程師一樣自己發現問題並修正。
這也是為什麼以網頁技術為核心的遊戲工具，在 AI 開發上的體驗常常好上一大截。因為瀏覽器天生就能輕易截圖、檢查 DOM 與 Canvas、讀取 Console 報錯，搭配 Playwright 這類自動化工具，AI 就能在幾秒鐘內自己開啟遊戲、玩一次並確認畫面。
接下來，我們直接聚焦在實戰：在完全開源、可自己掌控程式碼的前提下，哪些架構最能解決這個痛點？
方案一：純程式碼網頁架構（2D 首選 Phaser 4）
這是目前實測下來，AI 寫起來最順暢、最不容易翻車的一類。
- 2D 組合：Phaser 4 + TypeScript + Vite + 一般網頁 UI + Playwright
- 3D 組合：Babylon.js（或 Three.js）+ TypeScript + Vite + Playwright
為什麼這套對 AI 特別友善
原因很直白：專案裡的所有東西都是純文字。
遊戲邏輯是 TypeScript、介面是用 HTML/CSS 排版、關卡資料是 JSON。AI 修改程式碼後，瀏覽器立刻熱更新重整；接著 Playwright 自動截圖並檢查 Console 報錯，AI 一看截圖就能知道「按鈕有沒有被擋住」、「角色動畫有沒有播放」。
以 2D 引擎來說，Phaser 4 採用完全開放的 MIT 授權，而且官方在設計時就主打 AI-ready，原始碼庫裡直接內建了專為 AI Agent 設計的技能設定（Agent Skills），涵蓋場景切換、物理碰撞、輸入按鍵、動畫播放與攝影機跟隨。
如果你想做的是 2D RPG、農場釣魚、模擬經營、休閒卡牌、塔防或放置點擊遊戲，這套方案是目前開發速度最快、反饋最直接的選擇。
方案二：網頁引擎加上本地編輯器（3D 首選 Babylon.js）
如果要做 3D 遊戲，純手寫程式碼來排布空間，AI 很容易算錯坐標。這時最好的解法，是使用帶有本地視覺化編輯器的開源 3D 引擎。
代表方案是 Babylon.js 加上 Babylon Editor 5。
澄清一個常見觀念：Three.js 與 Babylon.js 不太一樣
很多人以為這兩者差不多，但本質上有很大差異：
- Three.js 本質上是一個非常優秀的3D 繪圖函式庫，主要負責把東西畫出來，但遊戲常見的物理、動畫控制器、音效管理等，需要自己東拼西湊。
- Babylon.js 則是功能齊全的開源遊戲引擎（採用 Apache-2.0 授權），內部已經把場景管理、物理引擎、粒子與動畫系統都整合好了。
更棒的是它的桌面編輯器 Babylon Editor 5。它不是綁定雲端的付費服務，而是一個開源的跨平台桌面軟體（Windows、macOS、Linux 都能自己編譯打包），沒有任何平台綁定。
為什麼對 AI 很厲害
Babylon Editor 官方直接內建了 MCP（Model Context Protocol） 介面與命令列工具（CLI）。這表示 AI Agent 不僅能直接修改 TypeScript 腳本，還能透過通訊協定命令編輯器「建立某個物件」、「掛上光源」、「調整位置」，甚至叫編輯器截圖傳回給 AI 審查。
在打包發布時，它有完全獨立的命令列工具 babylonjs-editor-cli，不用打開圖形介面就能自動打包場景與貼圖，完全可以在自己的伺服器上自動化建置。
方案三：傳統引擎加上專用橋接工具（Godot 的正確用法）
很多人喜歡 Godot，因為它是完整、輕量且完全免費的開源引擎（MIT 授權），而且它的場景檔（.tscn）本來就是文字格式。
以前的常見盲點：叫 AI 盲改場景檔
很多人嘗試讓 AI 直接修改 .tscn 檔案，結果往往很糟糕。
因為 .tscn 雖然是文字，但長這樣：
1 | [node name="House" type="Node3D"] |
AI 雖然會改數字，但它無法在腦袋裡想像出這個坐標會不會讓房子卡在地底下、會不會擋住視線。沒有畫面回饋，AI 只能亂猜。
現在的解法：給 Godot 裝上 AI 橋接器
現在社群推出了專門的工具（例如 Godot Editor MCP 或 Swallowtail）。這些工具就像在 Godot 內部開了一扇溝通窗戶，AI 可以直接：
- 檢查場景樹裡有哪些物件。
- 命令 Godot 建立節點或掛載腳本。
- 指令遊戲啟動試玩、模擬按鍵，並把遊戲畫面截圖回傳給 AI。
這樣一來，AI 就不再是閉著眼睛改設定檔，而是能真正確認運行結果。
一個非常重要的注意事項：Godot 4 的網頁匯出限制
如果你打算用 Godot 4 做網頁遊戲，**請務必使用 GDScript，不要使用 C#**。因為目前官方 Godot 4 的 C# 專案仍然無法直接匯出為 Web（手機雙端的 C# 也還標註為實驗階段）。原生桌面遊戲才適合自由選擇 GDScript 或 C#。
方案四：不要叫 AI 從零捏模型，要像拼積木一樣擺放
這是在 3D 遊戲開發中，幾乎所有人都踩過的坑：千萬不要叫 AI 在程式碼裡用幾十個方塊和球體去硬拼出一座村莊。
讓 AI 用程式碼去算幾百個點的空間位置，既花費大量 Token，產出的成果又通常很難看。
更好的分工是「積木歸模型庫，擺放歸 AI」：
- 模型在 Blender 做好，或從開源資產庫下載現成的，匯出成標準的
.glb（glTF）檔案（例如house_a.glb、boat_b.glb）。 - 讓 AI 只負責寫規則和擺放邏輯，例如下指令：
在港口中心點放一艘 boat_b。
讓專業的 3D 模型保持獨立完整，AI 只要負責調度與撰寫遊戲邏輯，整體專案就會非常乾淨穩定。
方案五：想要發行手機 App？用 Capacitor 包裝
如果你的遊戲主要是網頁技術開發，但最後想要上架到 Apple App Store 和 Google Play，目前非常推薦的方案是搭配 Capacitor。
這套架構的核心優勢在於：
- 平日 95% 的開發時間：AI 都在最擅長的 TypeScript、瀏覽器和 Playwright 裡跑，測試速度飛快，隨改隨看。
- 只有 5% 的特殊功能：像是應用程式內購（IAP）、廣告、手機震動或推播通知，才透過 Capacitor 的原生外掛去串接。
Capacitor 是完全開源的（MIT 授權），它輸出的 iOS 和 Android 專案就是標準的 Xcode 與 Android Studio 原始碼，完全掌握在你自己手裡，不需要被任何第三方的封閉雲端打包平台綁架。
連線多人遊戲：後端該怎麼選
如果遊戲需要連線多人遊玩，後端架構也大有學問：
- 小型連線、房間合作制（最推薦）：
- 使用 Colyseus（Node.js / TypeScript）。
- 優點：遊戲前端跟後端都用 TypeScript，連線規格與遊戲規則可以前後端共用，AI 改起程式碼來最不容易出錯。
- 需要帳號、排行榜、聊天與公會：
- 直接自建 Nakama。
- 用一條
docker compose up就能在本機跑起整套包含 PostgreSQL 的遊戲伺服器，直接提供登入、排行榜與配對功能，省去自己從零手寫後端的大量時間。
各種架構特色速查表
| 架構方案 | 代表工具 | AI 寫邏輯難易度 | AI 檢查畫面能力 | 引擎功能完整性 | 適合發行平台 | 最佳適用遊戲類型 |
|---|---|---|---|---|---|---|
| 網頁 2D 程式導向 | Phaser 4 + TypeScript | 極度輕鬆 | 優秀 (Playwright 自動截圖) | 良好 | 網頁、手機 App (透過包裝) | 2D 經營、RPG、卡牌、小品動作 |
| 網頁 3D + 本地編輯器 | Babylon.js + Babylon Editor | 極度輕鬆 | 優秀 (內建 MCP 與截圖) | 完整 | 網頁、手機 App (透過包裝) | 空間佈局型 3D、展示型與網頁 3D 遊戲 |
| 傳統引擎 + 橋接工具 | Godot 4 + Swallowtail / MCP | 良好 | 良好 (需透過橋接截圖) | 極度完整 | 原生電腦、手機、網頁 (限 GDScript) | 跨平台中大型獨立遊戲、原生桌面專案 |
| 純程式碼 ECS 架構 | Bevy + Rust | 邏輯清楚，但 API 常變動 | 較弱 (缺少官方可視化編輯器) | 發展中 | 原生電腦、實驗性網頁 | 規則複雜的數值模擬、大量物件演算 |
| 網頁封裝成 App | Phaser / Babylon + Capacitor | 極度輕鬆 | 優秀 | 依選用引擎而定 | iOS、Android、網頁 | 打算跨平台發行的商業休閒遊戲 |
| 同語言連線後端 | Colyseus + TypeScript | 極度輕鬆 | 不適用 (後端邏輯) | 專精於連線 | 支援各大前端平台 | 房間制連線、回合制合作遊戲 |
實戰建議組合
如果你正打算讓 AI Agent 當你的副手一起做遊戲，推薦依照以下組合出發：
想做 2D 遊戲，且打算放網頁或上架手機雙平台：
- 選擇 Phaser 4 + TypeScript + Vite。
- 用 Playwright 寫好自動測試與截圖檢查。
- 打算上架 App Store / Google Play 時，用 Capacitor 包裝。
- 如果要做多人連線，後端搭配 Colyseus。
想做中輕度 3D 網頁或跨平台遊戲：
- 選擇 Babylon.js 搭配 Babylon Editor 5。
- 3D 模型全部在外部做好轉成
.glb檔案，讓 AI 透過 MCP 驅動編輯器擺放，並用截圖確認效果。
想做中型原生桌面或手機 3D 遊戲：
- 選擇 Godot 4（搭配 GDScript）。
- 務必安裝 Swallowtail 或 Godot Editor MCP 這類本地橋接工具，讓 AI 能連進編輯器檢視畫面與除錯，而不是讓它盲改場景檔。
總結
AI 時代在選擇遊戲引擎時，評判的標準已經變了：
最好的工具，不一定是功能清單最長、按鈕最多的軟體；而是最能讓 AI「看得見結果、能自己測試，並迅速把問題修正好」的架構。
當你為 AI 準備了一套能自動截圖、能回傳錯誤訊息、所有設定都用純文字清楚記錄的開發環境，AI 就會從一個常常幫倒忙的實習生，真正變成能為你獨當一面的超強開發助手。
