通盤指南・深入篇
回答八個具體問題：特效現況／Shader 怎麼做／待辦盤點／UI 合併／Draw call／怪物合併與 VAT／怪物編輯／美術工作流——最後收斂到「團隊怎麼運作」。
特效 = 「遊戲邏輯發事件」＋「渲染層表現」兩件事。前者從沒變過，我們一直在改的只是後者。
遊戲邏輯層在事件發生時往陣列丟一筆資料，例如撞擊時：shockwaves.push({ x, y, radius, thickness, life, color })。渲染層每幀讀這些陣列去「表現」。改渲染方式完全不動玩法邏輯——這是我們敢一直換渲染做法的原因。
Shader 是「跑在顯示卡上的小程式」，分兩段：頂點著色器（決定形狀擺哪）＋片段著色器（決定每個像素什麼顏色）。衝擊波的片段著色器核心邏輯翻成白話：
對畫面上這個像素：
1. 算它離特效中心多遠（d）
2. 「離中心的距離」跟「衝擊波當前半徑」差多少？
差距 < 線寬的一半 → 這個像素在圓環上 → 上色
否則 → 透明
3. 顏色 = 遊戲傳來的顏色；透明度 = 剩餘壽命比例
（彩虹版：顏色改用「時間 → 色相」的公式流動）
（虛線版：多算「沿著圓弧走了多遠」，每 28px 亮 16px 暗 12px）每幀 CPU 只要告訴 GPU 幾個數字（中心/半徑/透明度/顏色），幾百萬個像素的判斷全部 GPU 平行算——這就是為什麼 shader 版零掉幀。
| 步驟 | 誰做 | 內容 |
|---|---|---|
| 1 指定標準 | 人 | 「跟 2D 版一樣」＋指出 2D 的繪製程式碼位置（視覺真相源） |
| 2 翻譯成公式 | AI | 把 2D 畫圖邏輯（漸層節點、虛線間距、淡出曲線）逐項翻成 shader 數學 |
| 3 實機對比 | 人 | 2D/3D 切換對比，指出「哪一種長歪了」 |
| 4 調參收斂 | AI | 只動公式常數，通常 1-2 輪收斂 |
依「玩家看得到的完成度」→「效能」→「團隊工具」排序。進行中下一波規劃中
| 類別 | 項目 | 做法 | 狀態 |
|---|---|---|---|
| 特效 3D 化 | 衝擊波 4 種 | GPU shader 程序化 | 已上線待驗 |
| 依附特效（警示圈/旋風圈/Boss 護盾/光環） | 變化慢的→貼圖烘焙；幾何規則的→shader | 下一波 | |
| 特殊粒子 7 種（星爆/電弧/抓痕/鏈鋸…） | 逐型：billboard 貼圖或 shader | 下一波 | |
| 斬擊/X斬/殘影（空中類） | 評估：蓋怪合理→可留上層；要 3D→billboard | 規劃中 | |
| 效能 | 怪物骨骼 CPU 成本（VAT 化） | 見③——目前最大的效能債 | 規劃中・建議排入 |
| Draw call 審計＋圖集合併 | 見③ | 規劃中 | |
| 手機效能分級測試 | 低階機實測＋renderScale 自動降級 | 規劃中 | |
| 團隊工具 | 怪物配置表外部化（JSON） | 見④——企劃可自改 | 規劃中・建議先做 |
| 特效參數調整面板 | 見④——美術可自調 | 規劃中 | |
| UI 走 HTML/CSS 的遷移評估 | 見③④ | 規劃中 | |
| 收尾 | 透視強度調參 | 你回饋一個感覺，改一個常數 | 等你回饋 |
| 木乃伊/猩猩色調微調 | 你排到後面的 | 已排隊 |
先講現況（compat 模式一幀）：背景 1～2、殭屍每型 1~3（已 instancing：同型 100 隻=1 次）、陀螺/箱子每個 1~3、特效 quad 池每個活躍特效 1、粒子每型 1、canvas 疊層合成 1。總計估 30~60，對 WebGL 來說很健康（手機安全線約 100~300）。
VAT（頂點動畫貼圖）就是正解，你的直覺完全對：把每段動畫的每一幀「每個頂點在哪」預先烘進一張貼圖 → 遊戲時頂點著色器直接查表 → CPU 骨骼計算完全歸零，且與 instancing 完美相容（每隻怪只要一個「播放進度」數字）。
| 現況（即時骨骼） | VAT | |
|---|---|---|
| CPU/幀 | 隨怪數線性（每隻 pose+上傳） | ≈0（只更新播放進度） |
| 記憶體 | 低 | 每型每動畫一張貼圖（可控，動畫段固定） |
| 動畫混合 | 可（mixer） | 難（通常直切，我們的怪本來就直切） |
| 工作量 | — | 烘焙工具（AI 寫）＋頂點 shader＋驗證，約一個中型工項 |
我們的怪剛好是 VAT 甜蜜點：動畫段固定（走/死/攻/受擊）、不需混合、量大。建議排進效能下一波。
「合併」分兩個問題：
這是「不用引擎」最需要正面回答的問題：引擎的編輯器沒了，非工程師怎麼工作？答案：配置外部化＋AI 快速自建小工具。網頁的優勢是「編輯器本身就是網頁」，AI 一兩天能做一個。
現況（不理想）：怪物的模型/血量/速度/動畫段/掉落全部寫死在程式碼裡——只有工程師或 AI 能改。
目標做法（業界標準＝配置驅動）：
| 特效類型 | 美術的介入方式 |
|---|---|
| 貼圖類（火花/光暈圖） | 美術直接出圖（PNG/序列幀），丟進資源夾即生效——跟引擎流程一樣 |
| 程序/shader 類（衝擊波/光圈） | 做特效參數面板（顏色/大小/速度/淡出曲線滑桿＋即時預覽）——美術拉滑桿調到滿意，參數存檔。AI 一天能做這面板 |
| 全新特效 | 美術給參考（別的遊戲截圖/影片/手繪示意）→ AI 實作 → 美術驗收迭代——跟我們現在「你當眼睛」的模式相同，美術取代你當眼睛 |
UI 走 HTML/CSS 之後，美術的調整方式跟「調網頁」一樣：改字級/色彩/間距/圖片都是標準網頁技能（或美術出 Figma 稿 → AI 一比一實作，這條 AI 極快且準）。這是網頁遊戲相對引擎的一大優勢——UI 人才與工具生態全世界最成熟。
你的擔憂合理：沒有引擎＝沒有現成的協作介面。解法是把「協作介面」換成三樣東西：配置表、小工具、規範文件。角色都在，只是介面變了。
| 階段 | 動作 | 陀螺專案的實例 |
|---|---|---|
| 1 需求 | 人用「一句話＋參考」描述 | 「怪物頭要朝螢幕上方，像 2D 那樣」 |
| 2 根因/方案 | AI 先比對分析再動手，附證據 | 並排讀兩版程式碼，推導出 −45° 座標換算 |
| 3 實作＋部屬 | AI 改、commit、3 分鐘上線預覽網址 | 每批修正都是當天上線 |
| 4 人眼驗收 | 實機玩、對比、一句話回饋 | 「旋轉向外移動時偏掉」→ 直接命中根因 |
| 5 沉澱 | 坑寫進規範、知識進 wiki、穩定點打 tag | R1-R12 規範、20 項問題報告、stable-fx2d tag |