一、瀏覽器給了你什麼：四種「畫面能力」＋一台受控電腦

把瀏覽器想成「一台幫使用者把關的電腦」：你的遊戲跑在它的沙箱裡，它給你四種畫東西的能力，各有分工。

瀏覽器同時是「規則制定者」，這些規則 Unity Player 沒有，要記住：

• 單執行緒：邏輯、渲染指令、UI 全在一條線上跑——某段程式卡 50ms，整個畫面就頓 50ms（沒有背景執行緒可躲）
• 沙箱：不能碰使用者的檔案系統、不能自由連任意網路（跨域限制）——存檔用 localStorage、對外連線要伺服器允許
• 自動播放政策：使用者沒點過頁面前，聲音播不出來（我們遊戲開頭要先點一下就是這原因）
• 分頁切走會節流：切到別的分頁，rAF 停跑——回來時 deltaTime 會爆大，要設上限（對照手冊第 12 題）
• 記憶體由 GC 管理：跟 C# 一樣有垃圾回收——每幀 new 物件會造成 GC 卡頓（我們的渲染碼都用「重用暫存物件」的寫法）

二、什麼是 WebGL（白話版）

一句話：WebGL 是瀏覽器裡「跟顯示卡（GPU）說話」的標準語言。它不是引擎、不是函式庫——它是一組很低階的指令，讓網頁能命令 GPU 畫三角形。

為什麼需要 GPU？CPU 擅長「複雜但少量」的運算（遊戲邏輯），GPU 擅長「簡單但海量」的運算——螢幕有 200 萬個像素，每個像素每幀都要算顏色，這種「同一件事做 200 萬次」的工作只有 GPU 做得動。Canvas 2D 慢就是因為它主要靠 CPU；我們把怪物搬到 WebGL 就是把這批海量工作交還給 GPU。

GPU 畫一個東西的流水線（理解 shader 在哪裡用）

「shader」就是第 2、4 步那兩個你能自己寫的小程式（用 GLSL 語言）。Three.js 的角色：直接用 WebGL 寫遊戲太累（畫一個三角形要 50 行），Three.js 把它包裝成「場景/相機/材質/模型」的人話 API——你可以把 Three.js 理解成「只拿渲染層的迷你 Unity」。

三、一個網頁遊戲的完整架構（以陀螺專案為例）

從上到下七層——右側標注陀螺專案對應的程式碼位置。任何網頁遊戲都是這七層，差別只在各層選什麼技術。

Unity 對照：這七層就是 Unity 幫你「裝好」的東西攤開來——入口外殼≈啟動場景、資源層≈Assets 匯入、邏輯層≈你的 Scripts、渲染層≈引擎渲染管線、輸入層≈Input System。不用引擎=這七層都看得到、AI 都改得到。

四、一幀之內發生什麼（1/60 秒的旅程）

把上面的架構串起來動態看——每秒跑 60 次的完整旅程：

整趟必須在 16.7ms 內完成（60fps 的預算）。哪一步超支哪裡就掉幀：第 2 步超支=邏輯太重（怪太多 → 空間分格優化）、第 4a=GPU 或上傳太重（我們的貼圖上傳教訓）、第 4b=CPU 畫太多（特效 3D 化的動機）。效能調優=找出超支的那一步，DevTools Performance 面板就是量這個的。

五、做 WebGL 的困難點（每一條都附我們的對策）

誠實清單——WebGL 難的不是 API，是下面這十件事。全部是本專案親身踩過或正面遭遇的，附上實例與對策，讓困難「可管理」。

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

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

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

• AI 可以直接改到每一行——引擎的黑盒子（序列化場景、二進位資產、編輯器操作）AI 碰不到；純程式碼專案 AI 全域可控，這正是「AI 快速開發」成立的前提
• 零安裝、即點即玩、部屬即上線——我們每次修完 3 分鐘就部屬到網址給你玩，引擎專案做不到這個節奏
• 版本控制覆蓋一切——所有狀態都在 git 裡（我們的 20+ commits、隨時可退的 tag），引擎的場景檔衝突地獄不存在

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

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

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

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

四種做法（成本與適用）

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

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

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

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

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

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

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

⑤ 用 AI 開發遊戲的方法論

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

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

已驗證的工作流

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

• 知識庫 wiki——系統知識＋問題總報告：新的 AI session 接手先讀，不用重新摸索（wiki/decisions/2d-to-3d-migration-issues.md）
• 規範 R1-R12——踩過的坑變成規則：AI 每次動手前對照，同樣的坑不踩第二次（wiki/conventions/webgl-3d-rendering-rules.md）
• git 紀錄——每個 commit 寫「改了什麼＋為什麼」：AI 和人都能考古

① 現在特效怎麼做（含 Shader 實例解剖）

特效 = 「遊戲邏輯發事件」＋「渲染層表現」兩件事。前者從沒變過，我們一直在改的只是後者。

資料流（所有特效共通）

遊戲邏輯層在事件發生時往陣列丟一筆資料，例如撞擊時：shockwaves.push({ x, y, radius, thickness, life, color })。渲染層每幀讀這些陣列去「表現」。改渲染方式完全不動玩法邏輯——這是我們敢一直換渲染做法的原因。

Shader 是什麼（用衝擊波實例講）

Shader 是「跑在顯示卡上的小程式」，分兩段：頂點著色器（決定形狀擺哪）＋片段著色器（決定每個像素什麼顏色）。衝擊波的片段著色器核心邏輯翻成白話：

對畫面上這個像素：
1. 算它離特效中心多遠（d）
2. 「離中心的距離」跟「衝擊波當前半徑」差多少？
   差距 < 線寬的一半 → 這個像素在圓環上 → 上色
   否則 → 透明
3. 顏色 = 遊戲傳來的顏色；透明度 = 剩餘壽命比例
（彩虹版：顏色改用「時間 → 色相」的公式流動）
（虛線版：多算「沿著圓弧走了多遠」，每 28px 亮 16px 暗 12px）

每幀 CPU 只要告訴 GPU 幾個數字（中心/半徑/透明度/顏色），幾百萬個像素的判斷全部 GPU 平行算——這就是為什麼 shader 版零掉幀。

「用 AI 寫 shader」的實際工作流（已跑通）

② 待辦盤點：接下來要做的事

依「玩家看得到的完成度」→「效能」→「團隊工具」排序。進行中下一波規劃中

③ 效能三問：UI 合併／Draw call／怪物合併與 VAT

Draw call 現況與怎麼減少

先講現況（compat 模式一幀）：背景 1～2、殭屍每型 1~3（已 instancing：同型 100 隻=1 次）、陀螺/箱子每個 1~3、特效 quad 池每個活躍特效 1、粒子每型 1、canvas 疊層合成 1。總計估 30~60，對 WebGL 來說很健康（手機安全線約 100~300）。

• 已做：InstancedMesh2（同型怪合批）、粒子系統批次
• 可再做（需要時才做）：特效 quad 池改 instanced（全部衝擊波 1 次 draw）、貼圖合併圖集（減材質切換）、UI 圖集
• 判斷：draw call 目前不是瓶頸，別過早優化——真正的效能債在下面這條

怪物怎麼合併／VAT（你問到重點了）

VAT（頂點動畫貼圖）就是正解，你的直覺完全對：把每段動畫的每一幀「每個頂點在哪」預先烘進一張貼圖 → 遊戲時頂點著色器直接查表 → CPU 骨骼計算完全歸零，且與 instancing 完美相容（每隻怪只要一個「播放進度」數字）。

我們的怪剛好是 VAT 甜蜜點：動畫段固定（走/死/攻/受擊）、不需混合、量大。建議排進效能下一波。

UI 要怎麼合併

「合併」分兩個問題：

• 效能面：UI 現在畫在 canvas 疊層＝瀏覽器合成 1 層，效能上已經是「合併」狀態，不是瓶頸
• 工作流面（更重要）：建議把「螢幕 UI」（HUD/計分/選單）逐步改 HTML/CSS——瀏覽器渲染、不佔遊戲迴圈、而且美術可以直接用網頁工具調（見④）。「世界內 UI」（怪頭上血條/數字）留在遊戲渲染層（跟著鏡頭走的必須在裡面）

④ 編輯工具：怪物怎麼編、美術怎麼調

這是「不用引擎」最需要正面回答的問題：引擎的編輯器沒了，非工程師怎麼工作？答案：配置外部化＋AI 快速自建小工具。網頁的優勢是「編輯器本身就是網頁」，AI 一兩天能做一個。

怪物編輯（企劃的工作流）

現況（不理想）：怪物的模型/血量/速度/動畫段/掉落全部寫死在程式碼裡——只有工程師或 AI 能改。

目標做法（業界標準＝配置驅動）：

• 第一步：把怪物參數抽成 JSON 配置表（一隻怪一筆：用哪個模型/多少血/走多快/放什麼技能/動畫用哪幾段/掉多少票）——企劃改表存檔重新整理就生效，不碰程式碼
• 第二步（可選）：AI 做一個網頁編輯面板——左邊改參數、右邊即時預覽那隻怪（轉視角/播動畫），存檔直接寫回 JSON。這就是你自己的「怪物編輯器」，規格由你們定

美術怎麼調整特效

美術怎麼調整 UI

UI 走 HTML/CSS 之後，美術的調整方式跟「調網頁」一樣：改字級/色彩/間距/圖片都是標準網頁技能（或美術出 Figma 稿 → AI 一比一實作，這條 AI 極快且準）。這是網頁遊戲相對引擎的一大優勢——UI 人才與工具生態全世界最成熟。

⑤ 團隊運作模式（回應你的擔憂）

你的擔憂合理：沒有引擎＝沒有現成的協作介面。解法是把「協作介面」換成三樣東西：配置表、小工具、規範文件。角色都在，只是介面變了。

角色分工（建議）

一個功能的標準流程（已在陀螺專案驗證）

對你擔憂的直接回應

• 「AI 做的東西會不會失控」→ 版本保護（每步 commit＋穩定 tag）讓任何失敗都可退；規範讓同樣的坑不踩兩次。這幾天特效玩壞過兩次（FPS 崩），都在當天修復或可回退
• 「沒人懂內部怎麼辦」→ wiki＋規範＋commit 說明就是「可考古的專案記憶」，任何新的 AI session 或新工程師都能接手（我們已實測過 AI 換模型接手）
• 「美術企劃沒工具」→ 工具由 AI 現造，且規格完全按你們的工作習慣定——這反而是引擎給不了的客製化
• 「品質怎麼保證」→ 人眼驗收是唯一標準（AI 盲區），流程上把它制度化：每批部屬必驗、凍結對比、真機效能實測

部屬後第一輪遊玩發現的 6 個問題。

agent 全檔掃描 2D 渲染器＋烘焙器逐項比對、架構級項目人工二次驗證。

蔡實機遊玩回報的追加問題（含手感層級）。

這三個失誤都導致「修了但你看沒變」，已寫入規範避免重犯。

從 20 項根因提煉，後續所有渲染開發照此走。

一、先破題:AI 開發改變了「維護」的本質

二、資產清單:維護就是保護這五樣東西

AI 不在資產清單裡——AI 是可替換的工具。這正是這套體系的安全性來源:知識在 repo，換哪家 AI、哪個模型，讀完文件就能接手（本專案已實測:換 AI 當天恢復全速）。

三、維護場景手冊（出事了照這個做）

四、人的最小技能組合（維護這系統需要會什麼）

五、品質不腐化的三道防線（讓系統十年後還能維護）

六、開發循環（新需求與 bug 修復共用）

維護中的「改東西」都走這個循環——這是引擎，上面五節是保養手冊。

七、誠實的風險表（這套體系哪裡會痛）