SpinningTop 實戰教材版

不用遊戲引擎，用 AI 開發網頁遊戲

以陀螺專案 2D→3D 搬移的真實過程為教材：引擎做掉了什麼、網頁怎麼自己做、特效為什麼難、AI 的強項與盲區。給決策者的通盤認知地圖。

① 遊戲引擎到底幫你做掉了什麼

Unity/Cocos 不是「一個工具」，是十幾個子系統的集合。不用引擎，這些全部要自己做（或用零散的網頁函式庫拼）。好消息：每一項 AI 都寫得出來；差別在有些一次就對、有些要跟人來回迭代。

子系統引擎給你的網頁上自己做AI 開發難度
遊戲迴圈Update()/FixedUpdate() 框架requestAnimationFrame ＋ deltaTime ＋ 邏輯/渲染分離容易・一次寫對
渲染管線場景圖、相機、材質、光照全包Canvas 2D 自己畫，或 Three.js 自組場景/相機/材質中等・見②
資產載入拖進編輯器就能用自寫 loader（FBX/貼圖/音效）＋載入順序管理容易
骨骼動畫Animator 狀態機、動畫混合Three.js AnimationMixer ＋ 自寫狀態機（哪個狀態播哪段）中等・狀態機是坑（見④）
物理/碰撞物理引擎內建自寫（我們的專案就是自寫圓形碰撞＋反彈）中等・手感靠特例調
粒子/特效Particle System 視覺化編輯四種做法自己選（見③）難・本報告重點
UI 系統UGUI/FairyGUIHTML/CSS 疊在遊戲畫布上（反而比引擎好做）容易・網頁的主場
除錯工具編輯器內建 Inspector/Profiler自建除錯面板（我們的 PERF 面板：切渲染模式/凍結畫面/FPS）容易・但要記得做
跨裝置適配解析度方案內建自己處理縮放/DPR/效能分級中等
關鍵認知 不用引擎的真正代價不是「寫不出來」——AI 都寫得出來。代價是：引擎裡「所見即所得」的部分（特效外觀、動畫手感、視覺調校），變成要用「AI 改 → 人看 → 回饋 → 再改」的迭代循環來完成。所以「人當眼睛」的驗收流程是不用引擎開發的核心環節，不是輔助環節。

反過來說：不用引擎賺到什麼

② 網頁遊戲的三種渲染路線

我們的專案三種都有（PERF 面板可切），是活教材。

路線 A：Canvas 2D（陀螺專案的原點）

CPU 每幀用畫圖指令（畫線/畫圓/貼圖片）把整個畫面重畫一次。AI 最擅長的路線——所有視覺都是一行行看得懂的畫圖程式。

  • ✅ 開發最快、AI 生成視覺效果的成功率最高、除錯直觀
  • ✅ 「先後順序決定誰蓋誰」——分層直觀（一張紙原理）
  • ❌ 效能天花板：所有東西 CPU 逐幀畫，怪物一多就掉幀（這正是專案要 3D 化的原因）
  • ❌ 沒有真 3D：立體感要靠「離線烘焙」假裝（陀螺專案把 FBX 模型拍成 2D 圖片再播放）

路線 B：WebGL 3D（Three.js）

把模型/材質/燈光放進 3D 場景，GPU 負責畫。效能好、真立體，但要理解 3D 概念。

  • ✅ 效能：100 隻怪 = GPU 一批畫完（我們用 instanced rendering，殭屍再多都一次繪製）
  • ✅ 真 3D：透視、遮擋、光影自然正確
  • ❌ 概念門檻：場景/相機/材質/座標系/骨骼——AI 會寫但「寫錯了人看不出原因」（我們的頭朝向 ±45° 坑，AI 第一次也搬錯）
  • ❌ 視覺調校變抽象：2D 改一行畫圖碼就變，3D 要動材質參數/shader，迭代慢一些

路線 C：混合模式（我們的現況 compat）

3D 場景（背景/怪物/陀螺）＋透明 2D 畫布（特效/UI）疊在上面。移轉期的務實選擇，但有結構性代價：

  • ✅ 可以漸進搬移：先搬吃效能的（怪物），特效之後慢慢搬
  • ❌ 「兩張紙」問題：上層畫布永遠蓋住下層 3D——特效壓在怪物頭上（你抓到的問題），詳見③
  • ❌ 分工邊界要人工管理：每個視覺元素只能一邊畫，漏了=消失、兩邊都畫=重複（我們踩過 5 次）
  • ❌ 兩層的相機/震動要同步（踩過：特效跟怪錯位）
給決策者的判斷 新專案若一開始就選「純 WebGL（路線B）＋ HTML UI」，就沒有兩張紙問題和分工邊界問題——我們的痛大半來自「從 A 遷移到 B 的過渡期」。但若追求「AI 生成視覺的最快迭代」，A 仍是起步最快的。先 A 後 B 是合理路徑，但要有心理準備：遷移成本 ≈ 重寫渲染層（我們正在付這筆帳，好處是付完就懂了）。

③ 特效專章：四種做法與「兩張紙」問題

特效是「不用引擎」最難的部分——引擎的粒子編輯器幫美術做掉的事，網頁上要在四種技術方案裡選對的用。

四種做法（成本與適用）

做法原理適用代價
1. CPU 程序畫圖
（2D canvas）		 每幀用程式畫線/圓/漸層 形狀複雜、變化快、數量少的（星形爆炸、電弧、對決 UI） 吃 CPU；在混合模式下永遠蓋最上層
2. GPU 粒子系統 發射一批粒子，GPU 自己算軌跡 大量小顆粒（打擊碎屑、火花雨） 每顆粒子只能是簡單形狀（點/小貼圖）
3. GPU shader 程序化 用數學公式在顯卡上「算」出圖形 幾何規則＋高頻變化的（衝擊波圓環、光圈、虛線圈） 要寫 shader（AI 擅長，但視覺對齊要迭代）
4. 貼圖烘焙
（canvas→texture）		 用 2D 畫法畫進小圖，貼到 3D 面片 視覺要求 100% 一致＋變化慢的（警示圈） ⚠️ 每幀上傳貼圖有頻寬紅線（見下）

實戰案例：衝擊波的三次改版（頻寬紅線的由來）

V1・全螢幕烘焙整個畫面畫進大貼圖每幀上傳 GPU。每幀 8MB → FPS 崩到 20
V2・局部小貼圖每個特效一張 256px 小圖。上傳量降 30 倍，但高頻變化仍掉 10fps
V3・shader 程序化圓環用數學公式 GPU 直算，每幀只傳幾個數字。零上傳、零掉幀
效能紅線（用 FPS 換來的教訓） 「CPU 畫好的圖每幀送給 GPU」是混合模式的頭號效能殺手。判斷準則：特效「每幀都在變」→ 必須用 GPU 粒子或 shader（做法 2/3）；特效「一秒才變一點」→ 才可以用烘焙（做法 4）。這條判斷直接決定特效搬移的技術選型。

「兩張紙」問題：為什麼特效會蓋住怪物

混合模式 = 兩張獨立畫布疊放：下層 WebGL（3D 世界）、上層 Canvas（特效/UI）。同一張紙上可以自由決定先畫誰後畫誰；兩張紙疊著，上面永遠蓋住下面——這是瀏覽器的物理疊放，沒有商量餘地。

所以「特效蓋在怪物頭上」不是 bug，是混合架構的結構性代價。治本 = 把特效搬進 3D 世界內（它就有了「深度」，怪物可以站在特效上面）——這正是我們現在做的事，也是為什麼要一種一種搬（每種特效要按上面四種做法選型重做）。

該留在上層的：資訊類（血條、傷害數字、頭上票數、對決 UI）——這些本來就該蓋在一切之上，是合理的最上層。

④ 我們踩過的坑：四大類避坑地圖

20+ 個實際問題（完整清單見 wiki 問題報告）歸納成四類。新專案或新功能，先對照這四類做設計檢查。

類型一：座標系（最陰險，錯了畫面「怪但說不出哪怪」）

  • 2D 的「Y 往下」vs 3D 的「Y 是高度」——粒子座標照抄直接噴到天上（踩過）
  • 旋轉的疊加順序：同一個「頭上仰 45°」，在模型旋轉之前套要用 −45°（踩過：照抄正 45° 變低頭）
  • 模型自身的中心點偏移：旋轉時身體「繞圈偏擺」（踩過：撞飛時特效對不上怪）
  • 對策：任何空間數值跨系統搬移，要求 AI 先寫出座標系轉換的推導，不准照抄數字

類型二：分層與雙畫（混合模式特有）

  • 每個視覺元素必須「只有一邊畫」——漏接=整層消失（石頭/星星/對決UI 踩過）、兩邊都畫=雙重（頭上數字出現兩個、物件雙畫浪費效能，踩過）
  • 對策：維護一張「誰畫什麼」的分工表（我們的規範 R5），每次新增/搬移視覺元素必登記＋凍結對比驗收

類型三：效能（掉幀的三大來源）

  • 貼圖每幀上傳（見③紅線）
  • CPU 逐個畫 vs GPU 批次：大量同類物體必須 instanced（我們的百隻殭屍一次繪製）
  • 隱藏的重複工作：雙畫、每幀 new 物件、每幀重建 canvas（分身特效踩過）
  • 對策：效能問題「只能實機驗」（模擬環境雜訊大於訊號）；保留 FPS 顯示；改動後跑一輪真機

類型四：視覺一致性（搬移類工作的最大坑）

  • 「好看」藏在細節調校裡：材質自發光數值、貼圖過濾參數、動畫的哪一段、打擊停頓 0.15 秒——搬架構時這些細節不會自己跟過來（我們 20 個問題裡 12 個屬此類）
  • 對策一：指定「視覺真相源」——舊版能看的地方就是標準答案，AI 必須並排比對而不是憑感覺重做（規範 R1）
  • 對策二：「視覺零改變」原則——搬移不是改風格的機會（規範 R12，你定調的）
  • 對策三：凍結畫面 A/B 對比的驗收流程（規範 R8）

⑤ 用 AI 開發遊戲的方法論

從我們這幾天實際合作模式提煉——這套流程已經在陀螺專案上驗證過一輪。

AI 的強項與盲區（分工的依據）

項目說明
AI 強寫程序化視覺畫圖碼、shader、粒子——給參考就能寫出來
AI 強架構搬移、批次修改狀態機重寫 150 行一次到位、20 項問題逐一根因修復
AI 強自我排查並排讀兩版程式碼找差異、量測數據定位根因（身體偏移 10-30px 是量出來的）
AI 盲視覺驗收AI 的驗證環境看不準 3D 細節（頭朝向那次 AI 自以為修了）——人眼是唯一標準
AI 盲手感打擊感「停一拍」這種東西 AI 不會主動感知——要人描述（你說了 AI 才能對齊）
AI 盲真機效能AI 環境的 FPS 沒參考價值——掉幀只有你玩得出來

已驗證的工作流

1・根因先行不准 AI 猜著改——先並排比對/量測，根因用證據定死再動手（我們前期兩次「改了沒效」都是猜的）
2・小批部屬每批改動獨立 commit＋3 分鐘部屬上線→你實機驗→回饋→下一批
3・人眼驗收視覺/手感/效能三件事只認你的實機回饋；你一句話（「旋轉向外移動時偏」）常常就是定位根因的關鍵
4・版本保護穩定點打 tag（stable-fx2d）——AI 可以大膽迭代，玩壞就退

讓 AI 不失憶的三件基礎設施（已建立）

總結：AI 快速開發的成立條件 「用 AI 不用引擎」是成立的，我們正在做的就是證明——但它成立的條件不是「AI 很會寫 code」，而是：①人負責眼睛和手感、AI 負責手；②每一個教訓都沉澱成規範讓 AI 遵守；③小批快速部屬讓迭代循環轉起來；④版本保護讓試錯無風險。這四件事我們都已經建好了，後續新功能（或新遊戲）直接沿用這套框架。