運輸部落 Tribe Transit Demo 開發紀要 封面

過去一個多月，我做了一款叫「運輸部落 Tribe Transit」的棋盤式運輸規劃遊戲。玩家在一座史前部落的小島上鋪路、選路口型式、配置車隊，看著一籃籃貨物送到工地。表面上是輕鬆的經營遊戲，底下跑的是一套交通工程模擬：起步延滯、跟車間距、號誌綠波、圓環讓行、Braess 悖論，全部都會在棋盤上真實發生。

這篇紀要整理從發想、網頁版雛形、Godot 正式開發到 V2.9 試玩包的過程，也記錄我怎麼和多個 AI（Claude、ChatGPT／Codex、影像生成、Blender 與 Godot 的 MCP 工具）分工合作。

一、遊戲發想

我的工作和交通工程有關。交通裡有很多「反直覺」的現象：多蓋一條捷徑，全體反而更慢（Braess 悖論）；號誌綠燈多給幾秒，下游卻塞得更嚴重；大車一台頂好幾台小車。這些現象在教科書上是公式，在現實裡是每天的塞車。我想做一款遊戲，讓玩家不用懂公式，就能親手「玩」出這些現象。

世界觀選了「架空的史前部落」：用馱獸、牛車、猛瑪象運貨，號誌是旗語與火光。這讓交通規則有新鮮感，也刻意避開任何可辨識的真實原住民族群。技術上選 Godot 4，邏輯用 GDScript、確定性模擬核心用 C++ GDExtension；不用 C#，是因為 Godot 4 的 C# 無法匯出 Web，而玩家自製關卡需要能在瀏覽器直接試玩。

早期概念板（AI 影像生成），用來對齊美術方向，不是實機畫面。
早期概念板（AI 影像生成），用來對齊美術方向，不是實機畫面。

二、試驗雛形：一個 HTML 檔的網頁版

在碰 Godot 之前，先用一個約 620 行的 HTML／JavaScript 檔做了網頁版雛形（demo v0.9）：等距視角棋盤、五道測試關（基準、泥沼、峽谷、Braess 陷阱、手機分段測試），可以升級路段、買車隊、按「開始運輸」看車隊跑。它不漂亮，但可以在電腦和手機上直接打開。

網頁版雛形 v0.9，第 4 關「Braess 陷阱」：中間虛線是可擴充的捷徑，蓋了反而可能變慢。
網頁版雛形 v0.9，第 4 關「Braess 陷阱」：中間虛線是可擴充的捷徑，蓋了反而可能變慢。

這個雛形用批次自動化跑了大量模擬，再拿到電腦和手機實測，換來幾個關鍵結論：

  • 在手機上逐格畫路不可行，操作單位要改成「整段道路」。
  • 轉角懲罰要全車種一致，否則會毀掉車種平衡。
  • Braess 關卡要問「要不要蓋這條捷徑」，而不是「拆掉一條路」，比較符合直覺。
  • 配置空間有限時，自動求解器可以窮舉，三星門檻就能精確算出來。

這些結論寫進了設計文件（GDD）v0.3，成為後續開發的地基。

三、從雛形到 Demo：開發歷程

  • 2026-09-06　GDD v0.3：網頁版雛形通過電腦與手機實測，核心玩法定型。
  • 2026-09-20　Godot 專案骨架：建立專案、版本控制與多 AI 協作說明檔 AGENTS.md。
  • 2026-10-07　雛型開發前確認：12 組核心決策逐項確認後才動工。
  • 2026-10-09　第一次試玩與大轉向：太像交通模擬軟體，改為棋盤規則。
  • 2026-10-11　V1.0：棋盤玩法、關卡編輯器、3D 木雕棋盤、教學。
  • 2026-10-25　V2.0：三軸評分、交通驗證關、車輛反應、圓環型式與村落生活定稿。
  • 2026-10-27　V2.9：車輛行為稽核後的路口、圓環與王道細修，是目前的試玩包。
第一版用程式產生的 3D 棋盤原型。
第一版用程式產生的 3D 棋盤原型。
V2 的首頁，關卡卡片與標題牌為 AI 手繪素材。
V2 的首頁，關卡卡片與標題牌為 AI 手繪素材。

四、開發重點

確定性模擬核心

所有車輛以「半格」為單位移動，一個半格是 1024 個整數單位，模擬固定每秒 30 次。同一份方案不論跑幾次結果都一樣，所以可以完整重播、可以比較 A/B 方案，也可以讓自動求解器替每一關算出星級門檻。

  • 30 Hz：固定步長、整數座標
  • 1 格 = 14 公尺：1 格／秒約等於時速 50 公里
  • 4 種車：斥候、馱獸、牛車、猛瑪
  • 每關最多 600 次：自動求解試跑
  • 17 關：含 7 道交通驗證關

真實的交通特性，簡化成玩得懂的規則

車輛有 1 秒反應、約 2 秒加速、行進中保持「自身速度 × 0.5 秒」的間距；路口有停讓、主路優先、號誌（含綠燈分配與時差）；圓環有一般與渦輪兩種型式，可加入口儀控。村落的村民車流與玩家車隊共用道路，玩家的決定會影響他們。

圓環是整個專案修改最多次的地方（見下一節）。
圓環是整個專案修改最多次的地方（見下一節）。

評分要鼓勵「好的交通工程」

評分由完成時間、預算、村民延滯三軸依比例合成，每關權重由自動求解器依各軸的分散程度決定。這個設計不是一開始就對，下一節會講到。

有生命感的世界

3D 木雕棋盤、會走路擺頭的車隊、塞車時冒泡抱怨的村民、到貨後才開始生火煮飯的庭院、海上的漁船與跳魚。這些不影響分數，但讓「運到了」這件事有畫面。

海島外圍、小船與重做的猛瑪。
海島外圍、小船與重做的猛瑪。
村落生活樣品與觀察面板。
村落生活樣品與觀察面板。

五、困難與突破

從「模擬軟體」轉成「遊戲」

第一版 Godot 雛型的交通模型非常完整：連續路網、動態交通指派、近似均衡分析。但第一次試玩的結論很直接：分析要等好幾分鐘、介面像工程診斷工具、不好玩。我們決定大轉向：道路改成棋盤、車長以半格計、路口一次放行一台、出發後只能用有限指令點介入。模型變簡單，但交通現象仍然存在，玩家第一次能「看懂」自己為什麼塞車。

圓環：前後改了二十多版

圓環是最難的部分。早期內外雙環會互卡：內環車出不來、出口被外環車搶走、連續進環的車讓外環車長時間出不去。之後又遇到車輛畫面上異常加速、斜向接入的路面破口、王道兩車道進環時重疊。我參考了 FHWA 的渦輪圓環指引與英澳的入口儀控做法，請 AI 先量測再提方案。最後的結論是：一般圓環改為單環、入口一次一台、停止線移到圓環外；需要更大容量時，玩家可以選渦輪圓環或加儀控，這兩種都要多花預算。

畫面上的車速不等於模擬的車速

玩家回報「車進圓環時會瞬間加速」。原有測試只量車頭，所以一直沒抓到。AI 寫了一套稽核，跑了 492 個情境（各種道路、路口、車種），逐 tick 記錄車頭與車身。原因是模型畫在車身中點，而中點用「模擬距離」回推，在轉彎處畫面距離和模擬距離不同。改成沿畫面路徑量固定距離後，圓環內車身／車頭速度比從 0.31–4.15 收斂到 0.82–1.20，路段與路口的模型重疊降到 0。

用交通理論驗證遊戲

我想確定遊戲裡的現象「是真的」，所以做了七道交通驗證關，逐 tick 量測後與理論比對。符合的部分：綠波時差讓下游停車次數降為 0、號誌放行量與綠燈長度成正比、回堵波速與理論一致、捷徑讓平均旅行時間增加約 12%（Braess）。不符合的部分也照實寫出：排頭車原本沒有起步延滯、行進中可以零車距。後來依此加入反應時間、加速與跟車間距，再重新量測確認。

堵住評分漏洞

早期評分只看玩家車隊，於是最高分的打法是封掉村民的路、把主線綠燈壓到最短，讓村民塞在家門口。這完全違背交通治理的精神。改法是把村民延滯計入分數、出發前檢查村民起訖必須連通、號誌綠燈至少佔週期 20%；後來又發現升級村民道路會讓「延滯」變成負數，於是改以「不計號誌等候的自由流時間」為基準、延滯下限為 0。

跨平台的確定性（仍在進行）

GitHub 上的 Linux 自動測試和 Windows 跑出不同結果。原因之一是各平台 C 函式庫的 sin、cos 取整不同，所以核心改用只靠加減乘除與開根號的自製三角函數。這修正了一部分差異，但兩平台仍有其他差異來源尚未查明。我把它留在待辦清單上，而不是宣稱已經解決。

六、AI 如何輔助這次開發

這個專案由我加上幾個 AI 協作者完成。我負責方向、試玩手感與每一個設計決定；AI 負責大部分的程式、量測、文件與素材。分工大致如下：

  • Claude（Cowork、Claude Code）：網頁雛形、C++ 模擬核心、Godot 遊戲與編輯器、教學、圓環與車輛行為、交通理論驗證、試玩包。
  • ChatGPT／Codex：第一版 Godot 雛型（連續路網模型）、設計擴充提案、架構審查與修正、三軸評分實作、美術素材、村落生活。
  • AI 影像生成：概念板、首頁手繪素材、地面貼圖。
  • Blender MCP：車隊、建築、植物、小船、儀控旗手柱等 3D 模型。
  • Godot MCP：啟動編輯器、執行專案、讀取除錯輸出。
由 AI 直接建模、匯入 Godot 驗證的馱獸模型（3,520 面，含載貨與隊伍色節點）。
由 AI 直接建模、匯入 Godot 驗證的馱獸模型（3,520 面，含載貨與隊伍色節點）。

讓多個 AI 協作不失控的做法

單一入口檔案。專案根目錄有一份 AGENTS.md，任何 AI 開工前都要先讀它和最新版設計文件，完工後在最上面新增一則進度紀錄：做了什麼、驗證了什麼、還沒做什麼。不同 AI、不同對話之間就靠這份紀錄交接。

設計文件是唯一權威。GDD 裡每個定案決策都有編號（目前到 D37），附上日期與來源。AI 可以指出疑慮、提出方案，但不能自己改定案內容。文件一律另存新版號，不覆蓋舊版。

先量測，再提方案，最後由人決定。遇到設計取捨時，AI 會先寫量測工具、跑幾十到幾百組情境，再整理成 A／B／C 方案與數據，由我選擇。例如圓環車流就先試算了五種配置、80 個案例，才決定採用哪一種。

每次修改都要有證據。原生 C++ 測試、17 套 Godot 回歸測試、全關卡自動驗收、匯出版效能量測（p95 影格時間），每一則紀錄都寫明跑了哪些、哪些沒跑。人類試玩清單則另外記錄手感，因為「測試通過」不等於「好玩」。

我的幾點心得

AI 的速度改變了開發節奏：常常在一個工作階段內，就能從「我覺得車進圓環怪怪的」走到量測、找到原因、修正、回歸測試、打包新版。但速度越快，越需要護欄：明確的權威文件、版本紀錄、誠實的驗證報告。AI 偶爾會說得比做得多，所以我要求它把「已驗證」和「未驗證」分開寫。

真正留給人的工作，是判斷「什麼才是對的」：這個交通現象該不該讓玩家感受到、這個規則好不好懂、這個畫面有沒有部落的味道。AI 能把每個選項的代價算清楚，選擇仍然是人的責任。

七、下一步

目前的 V2.9 試玩包是 Windows 版。接下來會依試玩回饋重新求解圓環關卡的參考值、查明跨平台差異、補上音效，並往 Web 與行動版前進，最後開放玩家用關卡編輯器分享自己的交通難題。如果你也對交通、遊戲設計或 AI 協作開發有興趣，歡迎留言交流。

圖片皆為專案內的實機截圖、雛形截圖或 AI 生成的概念與素材。