---
slug: claude-of-duty-threejs-fps-agentic-game-dev
title: Claude of Duty 在做什麼？把「單一 prompt 做出 FPS」變成一套可量測的 AI 遊戲開發實驗
status: published
excerpt: Claude of Duty 表面上是在秀「單一 prompt 做出 Call of Duty 風格 FPS」，但 repo 真正值得看的是另一件事：它把 AI 代理寫遊戲，包成一套有架構契約、可重現截圖、像素級回歸與 gameplay profiler 的工程流程。
category: Development
tags: [threejs, webgl, ai-agents, game-dev, fps, claude-of-duty, procedural-generation]
author: Seer
author_role: Author
read_time: 8 min
cover: "/static/claude-of-duty-threejs-fps-agentic-game-dev-cover.png"
published_at: "2026-07-28T00:58:37Z"
updated_at: "2026-07-28T00:58:37Z"
---

[Claude of Duty GitHub repo](https://github.com/mshumer/Claude-of-Duty)

`Claude of Duty` 的亮點，並非僅是「用 AI 寫出瀏覽器版 FPS」。

如果只看專案名稱或那句 *A Call of Duty-quality FPS in Three.js, built from a single prompt*，很容易讓人以為這又是一個技術 Demo：用大型語言模型拼湊出一個勉強能跑的第一人稱射擊遊戲樣板，再以吸睛的行銷詞彙博取眼球。

然而，這個專案真正值得深入探討之處在於，它將這套流程推向了更嚴謹的工程化階段。

它所要證明的不是「AI 能憑空創造出 3A 大作」，而是：

> **當你嘗試讓多個 Agent 協作開發一款具備一定質感的 Three.js FPS 時，單憑 Prompt 是遠遠不夠的；你必須建立一套清晰的架構契約、回歸測試、視覺基線與效能量測工具。**

因此，`Claude of Duty` 更像是一個探討 **Agent 協作遊戲開發 (agentic game-dev)** 的工程實驗，而非單純的技術展示頁面。

## 先講定位：它不是成品遊戲，重點是 AI 代理怎麼被管起來

README 開宗明義就拉高了格局：

- 瀏覽器內運行的第一人稱射擊遊戲
- 基於 Three.js r180 與 WebGL2
- 程式碼約 5.5 萬行，劃分為 11 個子系統
- 由一組 AI Agent 協作撰寫
- 完全沒有外部美術資產
- 貼圖、模型、動畫與音效皆在載入時動態程式生成
- 執行期依賴僅有 `three`

在這些特色中，最關鍵的並非程式碼行數或「單一 Prompt 生成」，而是背後的兩個核心設計：

1. **將遊戲解構成定義清晰的子系統**
2. **將 Agent 的協作關係寫進架構規範中**

有了這兩點，這套專案才不至於淪為空洞的炫技 Demo。

## 它實際上做了什麼

從 README 與 `ARCHITECTURE.md` 來看，專案將架構切分為 11 個主要子系統：

- `render`
- `materials`
- `sky`
- `world`
- `physics`
- `player`
- `weapons`
- `fx`
- `ai`
- `ui`
- `audio`

這些劃分並非虛設，README 對每個子系統的職責都有具體描述：

- `render`：負責 HDR 渲染管線、GTAO、TAA、動態模糊、綻光、曝光控制、色彩查找表與 AgX 色彩對映。
- `materials`：負責程式生成表面與 PBR 材質。
- `world`：建構一個約 `120×120m` 的市集街景場景。
- `physics`：強調完全由核心程式碼實現，不引入外部物理引擎。
- `weapons`：涵蓋槍枝幾何、後座力、裝彈與彈道模擬。
- `audio`：直接透過 Web Audio API 進行聲音合成，不載入任何外部音效檔。

這代表開發者並非只想堆疊出一個勉強能動的半成品，而是認真將「第一人稱射擊遊戲」這項複雜任務，拆解為可獨立分工的工程模組。

## 真正有意思的地方：它先寫的是協作規則，不是先寫功能

整個專案最值得探討的檔案，不是 `src/` 底下的任何程式碼，而是 `ARCHITECTURE.md`。

這份文件本質上就是所有 Agent 的「施工契約」。

規範中嚴格限制了幾項開發邊界：

1. **各個 Agent 僅擁有自身目錄的修改權限**
2. **禁止直接載入其他子系統的模組**
3. **禁止新增 npm 依賴套件**
4. **禁止在遊戲邏輯或視覺表現中呼叫 `Math.random()`**
5. **禁止在每影格更新路徑上隨意配置記憶體空間**
6. **所有建立的幾何體、材質、貼圖及渲染目標都必須手動釋放**
7. **必須確保建置通過，且截圖工具能正常運作**

這些規則的出發點很明確：

> 這並非讓 Agent 自由發揮，而是將 Agent 視為容易在協作中相互干擾的工程成員，因此必須透過架構規範將影響範圍最小化。

甚至連跨子系統的溝通也被收斂至特定的事件詞彙：

- `weapon:fire`
- `weapon:reload`
- `bullet:impact`
- `damage:dealt`
- `damage:taken`
- `actor:death`
- `player:footstep`
- `explosion`
- `resize`

這樣的架構設計透露出一個核心思維：

> **與其期待 AI Agent 能夠完美無瑕，不如在它們出錯前，先把系統邊界築得足夠堅固。**

## 這個 repo 在秀的，不只是遊戲，還有一整套驗證 harness

README 中的一句話點出了精髓：

> *The interesting part of this repo is arguably the harness, not the game.*

這套測試框架並非裝飾，而是一條完整的驗證鏈：

- `tools/capture.mjs`：擷取單張畫面截圖
- `tools/shotset.mjs`：批次執行 11 組畫面擷取
- `tools/baseline.mjs`：在隔離的頁面環境中，固定每格時間預算，進行具重現性的畫面擷取
- `tools/imagediff.mjs`：進行逐像素比對，一旦畫面產生非預期變化便判定失敗
- `tools/profile.mjs`：量測遊戲運行的影格時間分佈與卡頓歸因
- `tools/playtest.mjs`：以指令碼驅動進行冒煙測試

這些工具的集結，背後指向了一個非常實際的工程痛點：

> **當 Agent 修改程式後，要如何驗證它是帶來了優化，還是不小心弄壞了畫面、效能或時序？**

作者的解答並非仰賴人工驗證，而是將以下環節自動化：

- 定義視覺基準
- 像素級圖像比對
- 實際遊戲效能分析
- 固定影格下的重現截圖

這也正是 `Claude of Duty` 與市面上許多「跑起來就收工」的 AI 生成專案最大的不同。它更在乎可重現性、可量測性，以及是否能精確揪出拖慢影格時間的子系統。

## 它最誠實的地方：作者自己承認，結果還不到 Call of Duty

這項專案令人激賞的地方，在於它並未刻意吹噓「AI 已能做出 AAA 級 FPS」。README 中直接坦承：

> **The goal was to match a modern Call of Duty. It does not.**

文中詳細列出了目前的限制：

- 手部建模仍顯粗糙
- 材質細節與紋理不夠豐富
- 敵人的外觀依然像假人
- 間接光照僅為粗略近似，而非全域光照
- 影格率仍有提升空間

專案甚至附帶了對抗性評審的評分紀錄，最終最高得分僅為 `5.05 / 10`，且評審在盲測中能輕易辨識出真實的 Call of Duty 畫面。

這份坦白讓整個專案更具實踐參考價值。它沒有停留在宣傳詞彙，而是把 AI 生成工作流面臨的技術瓶頸攤在陽光下：

- 程式生成貼圖的品質極限
- 角色模型為何依然擺脫不了假人感
- 光照設定的不一致如何破壞第一人稱視角模型的協調性
- 在提升畫面品質的同時，效能開銷可能隨之失控

## 它給的一個很強結論：平行 fan-out 不一定比單人順序修更有效

除了技術成果，專案也對 Agent 工作流提出了極具價值的實證觀察。README 指出：

- 進行三輪「由 6 個 Agent 平行各自負責單一目錄」的嘗試，僅讓評分提升了 `+0.46`，且遺留了更多破壞畫面的瑕疵。
- 隨後調整為「高度耦合的問題由單一 Owner 循序處理」，評分隨即上升了 `+1.00`。

這項經驗指出了目前許多 Agent 工作流的盲點：

> **能平行擴展，並不代表就應該平行擴展。**

諸如色調對映、天空盒與間接光照等高度耦合的系統，若強行切分給不同的 Agent 獨立開發，極易導致各自局部合理、整體卻相互衝突的窘境。這正是該實驗的啟發之處——它不只展示了協作的可能性，更定義了「哪些任務不適合被強行平行化」。

## 我怎麼看這個 repo

如果僅將其視為「憑藉單一 Prompt 產出 FPS 遊戲」的實例，無疑低估了它的價值。這套專案真正的精髓在於 Prompt 後面構築的工程流水線：

- 架構合約
- 子系統權責劃分
- 共享事件語彙
- 具重現性的畫面擷取
- 圖像比對閘門
- 遊戲效能剖析器
- Agent 工作流的反思與檢討

因此，它本質上是將「AI 代理開發遊戲」從概念驗證推向正規工程化流程的嘗試。它所證明的並非「AI 已能穩定產出 3A 遊戲」，而是：

1. AI 確實有能力將複雜的網頁 FPS 專案推進到可運作、可量測且可優化的階段。
2. 開發的痛點不再是功能生成，而是如何確保多個 Agent 協作後的產出具備可控性、可驗證性與回歸防護。
3. 面對視覺、效能、物理、材質與光照等高度耦合的系統，嚴格的工程規範遠比 Prompt 技巧來得重要。

## 幾個邊界也要先講清楚

### 1. 效能數據源自專案報告，而非筆者實測

README 中提及的一系列優化數據，包括：

- p50 / p99 影格率
- 最差影格時間
- 著色器編譯次數
- 啟動時間

這些皆是作者使用其分析工具量測的結果。由於本篇評析基於靜態程式碼研究，**並未實際運行該專案進行驗證**。因此上述指標應視為作者宣稱的成果，而非筆者獨立實測所得。

### 2. 「單一 Prompt」雖有其檔，但實踐裝備絕非一步到位

專案中確實包含了一份 `prompt.md`，其核心指導方針大致為：

- 打造一款貼近現代 Call of Duty 的第一人稱射擊遊戲。
- 將子任務分配給多個子代理執行。
- 各子代理進行循環疊代。
- 引入嚴格的評審機制審查視覺呈現。
- 若未達 AAA 質感則持續修正。

然而縱觀整個專案，真正支撐起開發流程的，是其後配套的架構規範、測試工具鏈與審查機制。僅憑 `prompt.md` 便宣稱能「一鍵生成 3A 遊戲」顯然言過其實。

### 3. 授權宣告的不一致

根據 GitHub API 及根目錄下的 `LICENSE` 檔案，該專案採用的是 `MIT` 授權，然而在 `package.json` 的 `license` 欄位中卻標示為 `ISC`。雖然這並不影響核心技術的評估，但撰寫報告時仍需持保留態度。保守的描述方式為：專案根目錄附帶 MIT 授權條款，但其 `package.json` 宣告為 ISC，存在些微不一致。

## 總結

`Claude of Duty` 的核心價值並非「展示 Claude 如何幫你搓出射擊遊戲」。更精確地說，它驗證了一件事：

> **當面臨體量龐大、高度耦合，且極度要求視覺與效能品質的專案時，決定成敗的關鍵不在於 Prompt，而在於明確的規格、系統邊界、基準建立、效能度量與回歸驗證。**

這份專案之所以值得關注，不僅是因為它在瀏覽器中實現了 FPS，更是將流於概念的 Agent 開發模式，朝向正規的軟體工程實戰推進了一步。

如果你正在思考：

- 如何避免協作的 Agent 彼此衝突？
- 如何針對視覺產出進行確定性審查？
- AI 生成的大型前端或遊戲專案該如何設計回歸測試？
- 邊界重疊的高耦合問題該如何循序解決？

那麼，`Claude of Duty` 最值得玩味的，或許不是它的遊戲畫面，而是它所建構的專案結構與驗證哲學。

## 參考資料

1. GitHub repo：<https://github.com/mshumer/Claude-of-Duty>
2. README：`README.md`
3. 架構契約：`ARCHITECTURE.md`
4. 原始 prompt：`prompt.md`
5. 入口與系統註冊：`src/main.js`
6. Engine：`src/core/engine.js`
7. baseline capture：`tools/baseline.mjs`
8. image diff gate：`tools/imagediff.mjs`
9. gameplay profiler：`tools/profile.mjs`
10. AI 子系統成本探針：`src/ai/aicost.mjs`