1. 為什么我放棄了游戲引擎選擇 Canvas 2D 硬寫1.1 一個(gè)“搜打撤”玩法的核心訴求《逃離鴨科夫》這個(gè)品類核心樂趣其實(shí)就三件事搜刮物資、遭遇戰(zhàn)斗、活著撤離。聽起來簡(jiǎn)單但真要把這套循環(huán)做出來你會(huì)發(fā)現(xiàn)它跟傳統(tǒng)關(guān)卡制游戲完全是兩碼事。傳統(tǒng)游戲是“設(shè)計(jì)好一條路讓玩家走”搜打撤是“給玩家一張圖讓他自己決定什么時(shí)候貪、什么時(shí)候跑”。這意味著游戲需要實(shí)時(shí)處理大量動(dòng)態(tài)狀態(tài)物資刷新、AI 巡邏路線、玩家背包、撤離點(diǎn)倒計(jì)時(shí)、傷害判定、視野遮擋……每一項(xiàng)都在持續(xù)變化。我一開始也想過用 Unity 或者 Godot畢竟現(xiàn)成的物理引擎、尋路系統(tǒng)、動(dòng)畫狀態(tài)機(jī)擺在那里拖拖拽拽就能跑起來。但實(shí)際動(dòng)手之后發(fā)現(xiàn)一個(gè) 2D 俯視角的搜打撤游戲真正需要引擎“幫忙”的地方其實(shí)沒那么多。物理只需要圓和矩形的碰撞檢測(cè)尋路用簡(jiǎn)單的網(wǎng)格 A* 就夠了動(dòng)畫更是幾張序列幀來回切。引擎帶來的額外復(fù)雜度——場(chǎng)景文件、組件系統(tǒng)、構(gòu)建流程、包體大小——反而成了負(fù)擔(dān)。更關(guān)鍵的是我想讓這個(gè)游戲在瀏覽器里直接打開就能玩不需要下載安裝不需要等待加載。Canvas 2D 配合原生 JavaScript一個(gè) HTML 文件加幾個(gè) JS 模塊就能跑起來部署成本幾乎為零。這對(duì)于一個(gè)想快速驗(yàn)證玩法、隨時(shí)分享給朋友試玩的項(xiàng)目來說吸引力太大了。1.2 Canvas 2D 到底能不能扛住很多人對(duì) Canvas 2D 的印象還停留在“畫個(gè)圖表”“做個(gè)粒子特效”的階段覺得它性能不行、做不了正經(jīng)游戲。我實(shí)測(cè)下來的結(jié)論是對(duì)于 2D 俯視角、同屏實(shí)體數(shù)量在 200 以內(nèi)的游戲Canvas 2D 完全夠用前提是你得知道怎么用。Canvas 2D 的繪制調(diào)用是即時(shí)模式immediate mode每一幀你都要重新描述整個(gè)畫面。這跟引擎的保留模式retained mode不一樣后者會(huì)幫你緩存場(chǎng)景圖。即時(shí)模式的好處是控制力極強(qiáng)你想畫什么就畫什么沒有中間層壞處是如果每幀都無腦重繪所有東西性能會(huì)迅速崩掉。我的優(yōu)化策略很簡(jiǎn)單只畫鏡頭里能看到的東西。游戲世界可以很大但屏幕就這么大視野外的實(shí)體直接跳過。再加上用離屏 Canvas 預(yù)渲染靜態(tài)地形每幀只需要把地形圖層拷貝一次然后在上層畫動(dòng)態(tài)實(shí)體。這套組合拳下來我在一臺(tái)五年前的筆記本上跑 150 個(gè)實(shí)體同屏幀率穩(wěn)定在 60fps。還有一個(gè)容易被忽略的點(diǎn)Canvas 的drawImage比逐個(gè)像素操作快幾個(gè)數(shù)量級(jí)。所有精靈圖我都提前打包成一張圖集繪制時(shí)用drawImage的九參數(shù)版本從圖集里裁切避免頻繁切換圖像源。這個(gè)技巧在粒子效果多的時(shí)候尤其明顯。1.3 這個(gè)項(xiàng)目適合誰來參考如果你符合下面任意一條這篇內(nèi)容應(yīng)該能幫到你想做一個(gè) 2D 小游戲但不想被引擎的復(fù)雜概念勸退已經(jīng)會(huì) JavaScript想找個(gè)項(xiàng)目把 Canvas API 練熟對(duì)搜打撤玩法感興趣想自己搭個(gè)原型驗(yàn)證想法需要在一個(gè)受限環(huán)境比如只能跑瀏覽器里快速出可玩版本我不假設(shè)你精通游戲開發(fā)但默認(rèn)你至少寫過一些 JavaScript知道requestAnimationFrame是干嘛的。如果你連 Canvas 的getContext(2d)都沒用過建議先花半小時(shí)看看基礎(chǔ)教程再回來讀這篇體驗(yàn)會(huì)順暢很多。2. 整體架構(gòu)沒有引擎我自己搭一套2.1 游戲循環(huán)與狀態(tài)管理沒有引擎幫你管生命周期第一件事就是自己寫游戲循環(huán)。核心就是一個(gè)requestAnimationFrame驅(qū)動(dòng)的 tick 函數(shù)每幀做三件事處理輸入、更新邏輯、渲染畫面。let lastTime 0; function gameLoop(timestamp) { const deltaTime (timestamp - lastTime) / 1000; lastTime timestamp; handleInput(); update(deltaTime); render(); requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);這里有個(gè)關(guān)鍵細(xì)節(jié)deltaTime 必須做上限截?cái)?。如果玩家切到別的標(biāo)簽頁再切回來deltaTime 可能是好幾秒直接傳給物理更新會(huì)導(dǎo)致實(shí)體瞬移穿墻。我的做法是Math.min(deltaTime, 0.05)也就是單幀最多按 50ms 計(jì)算超出的部分直接丟棄。狀態(tài)管理我用了一個(gè)極簡(jiǎn)的有限狀態(tài)機(jī)。游戲只有幾個(gè)大狀態(tài)LOADING、PLAYING、PAUSED、EXTRACTED、DEAD。每個(gè)狀態(tài)有自己的 enter、update、exit 鉤子。比如進(jìn)入EXTRACTED狀態(tài)時(shí)暫停所有 AI 更新彈出結(jié)算面板退出時(shí)重置關(guān)卡數(shù)據(jù)。這套東西手寫也就一百多行比引入狀態(tài)機(jī)庫輕量得多。2.2 實(shí)體系統(tǒng)不用 ECS用組合ECS實(shí)體-組件-系統(tǒng)架構(gòu)很流行但對(duì)于這個(gè)規(guī)模的項(xiàng)目來說有點(diǎn)殺雞用牛刀。我采用的是更樸素的組合模式每個(gè)游戲?qū)ο笫且粋€(gè)普通 JavaScript 對(duì)象包含位置、速度、渲染信息、碰撞體等屬性行為通過函數(shù)注入。function createPlayer(x, y) { return { type: player, x, y, vx: 0, vy: 0, radius: 12, hp: 100, inventory: [], update(dt) { /* 玩家更新邏輯 */ }, render(ctx) { /* 玩家渲染邏輯 */ } }; }所有實(shí)體塞進(jìn)一個(gè)entities數(shù)組每幀遍歷更新和渲染。需要分類處理時(shí)用type字段過濾。這種寫法在實(shí)體數(shù)量幾百以內(nèi)完全不會(huì)成為瓶頸而且調(diào)試起來極其直觀——你隨時(shí)可以在控制臺(tái)打印某個(gè)實(shí)體的完整狀態(tài)。2.3 地圖與碰撞網(wǎng)格化處理搜打撤游戲的地圖通常有大量墻壁、障礙物、可交互容器。我用二維網(wǎng)格來表示地圖每個(gè)格子記錄地形類型空地、墻壁、草叢、容器。網(wǎng)格的好處是碰撞檢測(cè)和尋路可以共用同一套數(shù)據(jù)結(jié)構(gòu)。碰撞檢測(cè)我用了最直接的圓-矩形相交。玩家和 AI 都是圓形碰撞體墻壁是矩形格子。檢測(cè)時(shí)只需要判斷圓心到矩形最近點(diǎn)的距離是否小于半徑。這個(gè)方法比像素級(jí)碰撞快得多而且對(duì)于俯視角游戲來說精度完全夠用。function circleRectCollide(cx, cy, r, rx, ry, rw, rh) { const nearestX Math.max(rx, Math.min(cx, rx rw)); const nearestY Math.max(ry, Math.min(cy, ry rh)); const dx cx - nearestX; const dy cy - nearestY; return dx * dx dy * dy r * r; }移動(dòng)時(shí)我采用分軸處理先嘗試水平移動(dòng)如果碰撞就回退水平速度再嘗試垂直移動(dòng)碰撞就回退垂直速度。這樣玩家貼著墻走的時(shí)候會(huì)自然滑動(dòng)不會(huì)卡死。這個(gè)技巧在幾乎所有 2D 游戲里都通用實(shí)現(xiàn)簡(jiǎn)單但效果拔群。2.4 渲染分層地形、實(shí)體、UI渲染我分了三層用三個(gè)離屏 Canvas 做緩存地形層靜態(tài)不變只在關(guān)卡加載時(shí)繪制一次。包含地面紋理、墻壁、裝飾物。實(shí)體層每幀清空重繪包含玩家、AI、子彈、掉落物。UI 層血條、背包、小地圖、提示文字直接畫在主 Canvas 上。地形層用離屏 Canvas 的好處是即使地圖很大每幀也只需要一次drawImage把可見區(qū)域拷貝過來。實(shí)體層因?yàn)橐l繁更新用主 Canvas 直接畫反而更快省去了離屏切換的開銷。視野遮擋我用了一個(gè)簡(jiǎn)化方案射線檢測(cè) 扇形視野。玩家和 AI 都有一個(gè)朝向角度和視野范圍每幀向周圍發(fā)射若干條射線碰到墻壁就截?cái)嘈纬梢粋€(gè)可見多邊形。這個(gè)多邊形用來裁剪實(shí)體層的繪制區(qū)域。聽起來復(fù)雜但實(shí)際代碼也就幾十行效果卻非常明顯——玩家能直觀感受到“墻后面看不見”。3. 核心玩法模塊的落地細(xì)節(jié)3.1 搜刮系統(tǒng)容器、背包與重量搜刮是搜打撤的“搜”。地圖上散布著各種容器箱子、柜子、尸體。玩家靠近后按交互鍵彈出搜刮界面。每個(gè)容器有一個(gè)戰(zhàn)利品表按權(quán)重隨機(jī)生成物品。const lootTable [ { item: bandage, weight: 40, min: 1, max: 3 }, { item: ammo_9mm, weight: 30, min: 10, max: 30 }, { item: medkit, weight: 10, min: 1, max: 1 }, { item: keycard, weight: 2, min: 1, max: 1 } ];權(quán)重隨機(jī)不是簡(jiǎn)單地把權(quán)重當(dāng)概率而是累加權(quán)重后取隨機(jī)數(shù)。比如總權(quán)重 82隨機(jī)一個(gè) 0 到 82 的數(shù)落在哪個(gè)區(qū)間就出哪個(gè)物品。這樣調(diào)整掉落率只需要改權(quán)重值不用保證總和為 100。背包系統(tǒng)我加了重量限制。每個(gè)物品有重量玩家有負(fù)重上限。超重會(huì)減速嚴(yán)重超重會(huì)無法奔跑。這個(gè)設(shè)計(jì)逼著玩家做取舍是帶滿彈藥還是留空間給高價(jià)值物品撤離前的那幾秒背包管理往往比戰(zhàn)斗還緊張。注意搜刮界面打開時(shí)游戲世界不能完全暫停。我一開始圖省事直接暫停了結(jié)果玩家在搜刮時(shí)被 AI 打死體驗(yàn)極差。后來改成“搜刮時(shí)玩家移速降為零但世界繼續(xù)運(yùn)轉(zhuǎn)”緊張感立刻就出來了。3.2 戰(zhàn)斗系統(tǒng)射擊、彈道與傷害戰(zhàn)斗是“打”。我實(shí)現(xiàn)了兩種攻擊方式近戰(zhàn)和遠(yuǎn)程。近戰(zhàn)就是扇形范圍判定遠(yuǎn)程是射線檢測(cè)。遠(yuǎn)程射擊的核心是彈道模擬。子彈不是一個(gè)瞬間到達(dá)的判定而是一個(gè)有速度的實(shí)體。每幀子彈向前移動(dòng)檢測(cè)與墻壁和實(shí)體的碰撞。這樣做的好處是子彈可以被躲避也可以被墻壁擋住真實(shí)感強(qiáng)很多。function updateBullet(bullet, dt) { const steps Math.ceil(bullet.speed * dt / 8); for (let i 0; i steps; i) { bullet.x bullet.vx * dt / steps; bullet.y bullet.vy * dt / steps; if (checkWallCollision(bullet.x, bullet.y)) { bullet.dead true; spawnImpactEffect(bullet.x, bullet.y); return; } // 檢測(cè)實(shí)體碰撞... } }這里有個(gè)關(guān)鍵點(diǎn)子彈速度太快會(huì)導(dǎo)致穿墻。如果子彈一幀移動(dòng) 50 像素而墻壁只有 16 像素厚直接檢測(cè)當(dāng)前位置就會(huì)漏掉。我的解法是把子彈的移動(dòng)拆成多個(gè)子步每步最多移動(dòng) 8 像素逐步檢測(cè)。這個(gè)“子步進(jìn)”技巧在快速移動(dòng)物體上必須用否則各種詭異穿透會(huì)讓你懷疑人生。傷害計(jì)算我用了部位倍率。雖然是個(gè) 2D 俯視角游戲但我給每個(gè)實(shí)體定義了“核心區(qū)”和“邊緣區(qū)”。命中核心區(qū)傷害翻倍邊緣區(qū)傷害減半。實(shí)現(xiàn)方式就是判斷命中點(diǎn)與實(shí)體中心的距離。這個(gè)設(shè)計(jì)讓走位和瞄準(zhǔn)有了意義而不是無腦對(duì)射。3.3 撤離機(jī)制倒計(jì)時(shí)與風(fēng)險(xiǎn)博弈撤離是“撤”。地圖上有若干撤離點(diǎn)玩家進(jìn)入撤離區(qū)域后開始倒計(jì)時(shí)倒計(jì)時(shí)結(jié)束即成功撤離。倒計(jì)時(shí)期間玩家必須待在區(qū)域內(nèi)離開則重置。這個(gè)機(jī)制看似簡(jiǎn)單但它是整個(gè)游戲張力最大的來源。我做了幾個(gè)調(diào)整來強(qiáng)化這種張力撤離倒計(jì)時(shí)全局可見AI 也會(huì)被吸引過來撤離點(diǎn)開啟有時(shí)間窗口不是一直可用攜帶高價(jià)值物品時(shí)撤離倒計(jì)時(shí)更長(zhǎng)最后一條是我從實(shí)際測(cè)試中加的。測(cè)試時(shí)發(fā)現(xiàn)玩家拿到好東西后直接沖撤離點(diǎn)一路無腦跑毫無緊張感。加了“負(fù)重影響撤離時(shí)間”之后玩家開始權(quán)衡要不要扔掉一些東西加快撤離還是冒險(xiǎn)帶著這個(gè)決策點(diǎn)非常有意思。3.4 AI 行為巡邏、追擊與搜索AI 是搜打撤游戲里最容易被做砸的部分。太笨了沒挑戰(zhàn)太聰明了玩家沒法玩。我用了分層狀態(tài)機(jī)來組織 AI 行為巡邏層沿預(yù)設(shè)路徑點(diǎn)移動(dòng)到達(dá)后隨機(jī)等待一段時(shí)間警覺層聽到聲音或看到可疑目標(biāo)轉(zhuǎn)向調(diào)查追擊層確認(rèn)敵人直接追擊并射擊搜索層丟失目標(biāo)后在最后已知位置附近搜索狀態(tài)切換的觸發(fā)條件包括視覺檢測(cè)射線 視野角度、聽覺檢測(cè)槍聲、腳步聲、受擊檢測(cè)被打了當(dāng)然要還手。function canSee(entity, target) { const dx target.x - entity.x; const dy target.y - entity.y; const dist Math.sqrt(dx * dx dy * dy); if (dist entity.viewDistance) return false; const angle Math.atan2(dy, dx); const angleDiff Math.abs(normalizeAngle(angle - entity.facing)); if (angleDiff entity.viewAngle / 2) return false; return !raycastWall(entity.x, entity.y, target.x, target.y); }實(shí)操心得AI 的視野檢測(cè)不要每幀都做。我一開始每幀對(duì)每個(gè) AI 做射線檢測(cè)10 個(gè) AI 就把幀率拉下來了。后來改成每 3 幀檢測(cè)一次并且用空間網(wǎng)格先做粗篩只檢測(cè)距離范圍內(nèi)的目標(biāo)性能立刻回來了。玩家根本感覺不到區(qū)別。4. 性能優(yōu)化讓 Canvas 2D 跑出引擎的感覺4.1 繪制調(diào)用的合并與裁剪Canvas 2D 最大的性能陷阱是頻繁的樣式切換。每次修改fillStyle、strokeStyle、globalAlpha都會(huì)觸發(fā)狀態(tài)重設(shè)。如果每畫一個(gè)實(shí)體就改一次顏色幾百個(gè)實(shí)體下來開銷非?？捎^。我的做法是按材質(zhì)分組繪制。同一幀內(nèi)先把所有需要畫同一種精靈圖的實(shí)體收集起來一次性設(shè)置好樣式然后連續(xù)drawImage。這樣樣式切換從幾百次降到幾次。// 不好的做法每個(gè)實(shí)體單獨(dú)設(shè)置 entities.forEach(e { ctx.fillStyle e.color; ctx.fillRect(e.x, e.y, e.w, e.h); }); // 好的做法按顏色分組 const groups groupBy(entities, color); for (const [color, list] of groups) { ctx.fillStyle color; list.forEach(e ctx.fillRect(e.x, e.y, e.w, e.h)); }另一個(gè)關(guān)鍵是視野裁剪。每幀計(jì)算鏡頭矩形只繪制與鏡頭相交的實(shí)體。這個(gè)判斷本身有開銷所以我又加了一層空間網(wǎng)格把地圖分成若干區(qū)塊每個(gè)區(qū)塊記錄包含的實(shí)體。鏡頭移動(dòng)時(shí)只檢查相鄰區(qū)塊進(jìn)一步減少遍歷量。4.2 離屏 Canvas 與圖集靜態(tài)地形用離屏 Canvas 預(yù)渲染這個(gè)前面提過了。這里補(bǔ)充一個(gè)細(xì)節(jié)離屏 Canvas 不要開太大。瀏覽器對(duì)單個(gè) Canvas 的尺寸有限制而且太大的 Canvas 會(huì)占用大量?jī)?nèi)存。我的做法是把地圖分塊每塊 512x512按需渲染和緩存。圖集方面我用了一個(gè)簡(jiǎn)單的打包腳本把所有精靈圖拼成一張 2048x2048 的大圖同時(shí)生成 JSON 描述每個(gè)精靈的位置和尺寸。運(yùn)行時(shí)只需要加載一張圖繪制時(shí)用drawImage的九參數(shù)版本裁切。// 從圖集繪制精靈 ctx.drawImage( atlas, sprite.sx, sprite.sy, sprite.sw, sprite.sh, entity.x - sprite.ox, entity.y - sprite.oy, sprite.sw, sprite.sh );4.3 對(duì)象池與垃圾回收J(rèn)avaScript 的垃圾回收是性能的隱形殺手。如果每幀都創(chuàng)建新對(duì)象子彈、粒子、傷害數(shù)字GC 會(huì)頻繁觸發(fā)導(dǎo)致幀率波動(dòng)。我的解法是對(duì)象池。所有頻繁創(chuàng)建銷毀的對(duì)象都預(yù)先分配好用的時(shí)候從池里取用完還回去。const bulletPool { pool: [], get() { return this.pool.pop() || createBullet(); }, release(bullet) { bullet.dead false; this.pool.push(bullet); } };粒子效果尤其要注意。爆炸時(shí)可能瞬間產(chǎn)生幾十個(gè)粒子如果每次都 new 一個(gè)對(duì)象GC 壓力很大。用對(duì)象池之后幀率曲線明顯平滑了。注意對(duì)象池不是萬能的。如果對(duì)象持有大量?jī)?nèi)存比如大數(shù)組池化反而會(huì)導(dǎo)致內(nèi)存泄漏。只對(duì)生命周期短、創(chuàng)建頻繁的小對(duì)象使用池化。4.4 幀率控制與自適應(yīng)不是所有設(shè)備都能跑 60fps。我的做法是動(dòng)態(tài)調(diào)整渲染質(zhì)量如果檢測(cè)到幀率持續(xù)低于 45fps自動(dòng)關(guān)閉粒子效果、降低視野多邊形精度、減少 AI 視野檢測(cè)頻率。這些調(diào)整對(duì)玩法沒有影響但能顯著提升流暢度。let frameCount 0; let lastFpsCheck 0; let currentQuality high; function checkPerformance(timestamp) { frameCount; if (timestamp - lastFpsCheck 1000) { const fps frameCount; frameCount 0; lastFpsCheck timestamp; if (fps 45 currentQuality high) { currentQuality medium; disableParticles(); } else if (fps 30 currentQuality medium) { currentQuality low; reduceViewPrecision(); } } }這套自適應(yīng)機(jī)制上線后低端設(shè)備的留存率明顯提升。玩家不會(huì)因?yàn)榭D而直接關(guān)掉頁面。5. 常見問題與排查實(shí)錄5.1 畫面撕裂與閃爍現(xiàn)象快速移動(dòng)時(shí)畫面出現(xiàn)橫向撕裂或者實(shí)體閃爍。原因Canvas 的繪制不是原子的如果在一幀內(nèi)分多次繪制而瀏覽器在中間進(jìn)行了合成就會(huì)看到不完整的畫面。解決所有繪制操作必須在同一個(gè)requestAnimationFrame回調(diào)內(nèi)完成。不要用setTimeout或setInterval驅(qū)動(dòng)渲染。另外確保canvas的尺寸與 CSS 尺寸匹配避免瀏覽器縮放導(dǎo)致的模糊和撕裂。// 正確設(shè)置 Canvas 尺寸 const dpr window.devicePixelRatio || 1; canvas.width canvas.clientWidth * dpr; canvas.height canvas.clientHeight * dpr; ctx.scale(dpr, dpr);5.2 碰撞檢測(cè)漏判現(xiàn)象高速移動(dòng)的實(shí)體穿過墻壁或者兩個(gè)實(shí)體重疊時(shí)沒有觸發(fā)碰撞。原因離散碰撞檢測(cè)只檢查當(dāng)前位置如果一幀內(nèi)移動(dòng)距離超過障礙物厚度就會(huì)漏判。解決前面提到的子步進(jìn)是標(biāo)準(zhǔn)解法。另外對(duì)于玩家和 AI 的移動(dòng)我加了最小步長(zhǎng)限制如果單幀移動(dòng)距離超過碰撞體半徑就拆成多步移動(dòng)。function moveWithCollision(entity, dx, dy) { const maxStep entity.radius * 0.8; const dist Math.sqrt(dx * dx dy * dy); const steps Math.ceil(dist / maxStep); for (let i 0; i steps; i) { entity.x dx / steps; entity.y dy / steps; resolveCollision(entity); } }5.3 輸入延遲與按鍵沖突現(xiàn)象玩家感覺操作“粘滯”或者同時(shí)按多個(gè)鍵時(shí)行為異常。原因輸入處理放在了渲染之后或者用了keydown的重復(fù)觸發(fā)。解決輸入狀態(tài)用布爾標(biāo)記記錄在每幀開始時(shí)讀取而不是在事件回調(diào)里直接驅(qū)動(dòng)邏輯。const keys {}; window.addEventListener(keydown, e keys[e.code] true); window.addEventListener(keyup, e keys[e.code] false); function handleInput() { if (keys[KeyW]) player.vy -speed; if (keys[KeyS]) player.vy speed; // ... }另外用e.code而不是e.key避免輸入法切換導(dǎo)致按鍵失效。這個(gè)坑我在測(cè)試時(shí)踩過中文輸入法激活時(shí)e.key會(huì)變成Process導(dǎo)致玩家動(dòng)不了。5.4 內(nèi)存泄漏與頁面卡死現(xiàn)象玩了幾分鐘后頁面越來越卡最終無響應(yīng)。原因事件監(jiān)聽器沒有移除、定時(shí)器沒有清理、對(duì)象池?zé)o限增長(zhǎng)。解決每次關(guān)卡切換時(shí)執(zhí)行一次清理流程移除所有事件監(jiān)聽、清空對(duì)象池、取消未完成的動(dòng)畫幀。我寫了一個(gè)destroy()函數(shù)在離開游戲狀態(tài)時(shí)調(diào)用。function destroy() { cancelAnimationFrame(rafId); window.removeEventListener(keydown, onKeyDown); window.removeEventListener(keyup, onKeyUp); bulletPool.pool.length 0; entities.length 0; }實(shí)操心得用 Chrome DevTools 的 Memory 面板做堆快照對(duì)比能快速定位泄漏點(diǎn)。我在開發(fā)過程中發(fā)現(xiàn)每次重開關(guān)卡都會(huì)多出一批 AI 對(duì)象最后查到是 AI 的定時(shí)器沒有清理。養(yǎng)成“誰創(chuàng)建誰清理”的習(xí)慣能省掉大量調(diào)試時(shí)間。5.5 常見問題速查表問題現(xiàn)象可能原因排查方向解決方案畫面撕裂繪制跨幀檢查 rAF 回調(diào)所有繪制在單幀內(nèi)完成實(shí)體穿墻離散碰撞漏判檢查移動(dòng)步長(zhǎng)子步進(jìn) 最小步長(zhǎng)限制操作粘滯輸入處理時(shí)機(jī)不對(duì)檢查事件綁定狀態(tài)標(biāo)記 每幀讀取幀率驟降GC 頻繁觸發(fā)檢查對(duì)象創(chuàng)建對(duì)象池 減少臨時(shí)對(duì)象內(nèi)存增長(zhǎng)監(jiān)聽器/定時(shí)器未清理堆快照對(duì)比destroy 流程 弱引用畫面模糊Canvas 尺寸不匹配檢查 DPR按設(shè)備像素比設(shè)置尺寸AI 卡墻尋路路徑未平滑檢查路徑點(diǎn)路徑平滑 碰撞回退音效延遲音頻未預(yù)加載檢查 Audio 上下文預(yù)加載 解碼后播放6. 從原型到可玩我的迭代節(jié)奏6.1 第一周能跑起來就行第一周我只有一個(gè)目標(biāo)讓一個(gè)方塊在地圖上移動(dòng)碰到墻壁會(huì)停下。沒有美術(shù)沒有音效沒有 AI。就是驗(yàn)證最核心的移動(dòng)和碰撞。這個(gè)階段最重要的是快速看到東西動(dòng)起來給自己正反饋。我用最簡(jiǎn)單的矩形繪制地圖就是隨機(jī)生成的網(wǎng)格。跑通之后立刻加了第二個(gè)方塊作為“敵人”讓它朝玩家移動(dòng)。這時(shí)候還沒有戰(zhàn)斗就是單純的追逐。但已經(jīng)能感受到一點(diǎn)點(diǎn)緊張感了。6.2 第二周加入搜刮和撤離第二周開始加玩法循環(huán)。容器、背包、撤離點(diǎn)這三個(gè)東西一加上游戲立刻有了“局”的概念。玩家有了目標(biāo)搜東西、找撤離點(diǎn)、活著出去。這個(gè)階段我花了大量時(shí)間調(diào)數(shù)值容器刷新率、物品價(jià)值、撤離倒計(jì)時(shí)長(zhǎng)度、AI 數(shù)量。數(shù)值調(diào)不好游戲要么太簡(jiǎn)單要么太挫敗。我的方法是自己反復(fù)玩記錄每次死亡的原因和撤離的成功率然后針對(duì)性調(diào)整。6.3 第三周打磨手感和反饋第三周全部花在“手感”上。射擊的后坐力、命中時(shí)的頓幀、拾取物品的音效、撤離成功的結(jié)算動(dòng)畫。這些東西不影響玩法邏輯但決定了玩家愿不愿意再開一局。我加了一個(gè)簡(jiǎn)單的屏幕震動(dòng)效果開槍時(shí)鏡頭輕微抖動(dòng)被擊中時(shí)抖動(dòng)更明顯。實(shí)現(xiàn)就是渲染時(shí)給鏡頭加一個(gè)隨機(jī)偏移幾行代碼但打擊感提升了一個(gè)檔次。let shakeAmount 0; function render() { const shakeX (Math.random() - 0.5) * shakeAmount; const shakeY (Math.random() - 0.5) * shakeAmount; ctx.save(); ctx.translate(shakeX, shakeY); // ... 繪制世界 ctx.restore(); shakeAmount * 0.9; // 衰減 }6.4 第四周性能優(yōu)化和兼容性最后一周專門處理性能和兼容性。在低端安卓機(jī)上測(cè)試發(fā)現(xiàn)幀率只有 20 多。通過前面說的自適應(yīng)質(zhì)量、對(duì)象池、視野裁剪最終把低端機(jī)也拉到了 40fps 以上。兼容性方面主要是 Safari 的一些怪癖。比如 Safari 對(duì)requestAnimationFrame的時(shí)間戳精度處理不同還有音頻上下文需要用戶交互后才能啟動(dòng)。這些坑我都記在了代碼注釋里避免以后忘記。7. 一些讓我少走彎路的工具和習(xí)慣7.1 調(diào)試工具不止 console.logCanvas 游戲調(diào)試光靠console.log效率太低。我常用的幾個(gè)手段可視化碰撞體按 F1 切換顯示所有碰撞體輪廓一眼就能看出碰撞檢測(cè)對(duì)不對(duì)。實(shí)時(shí)狀態(tài)面板在角落畫一個(gè)半透明面板顯示幀率、實(shí)體數(shù)量、玩家坐標(biāo)、當(dāng)前狀態(tài)。慢動(dòng)作模式按 F2 把deltaTime乘以 0.2方便觀察快速發(fā)生的碰撞和傷害判定。這些調(diào)試功能在發(fā)布版本里用條件編譯去掉開發(fā)時(shí)極其好用。7.2 代碼組織模塊化但不復(fù)雜我沒有用打包工具直接用 ES Module 的import/export。瀏覽器原生支持不需要構(gòu)建步驟。文件按功能分engine/游戲循環(huán)、輸入、渲染、碰撞game/玩家、AI、子彈、物品、地圖ui/HUD、菜單、結(jié)算面板data/物品表、AI 配置、關(guān)卡數(shù)據(jù)每個(gè)文件不超過 300 行職責(zé)單一。找 bug 的時(shí)候能快速定位到具體文件。7.3 版本控制小步提交每完成一個(gè)小功能就提交一次commit message 寫清楚改了什么。游戲開發(fā)經(jīng)常需要回退——某個(gè)改動(dòng)導(dǎo)致手感變差或者引入了一個(gè)難查的 bug。小步提交讓回退成本極低。我還會(huì)在關(guān)鍵節(jié)點(diǎn)打 tag比如“第一個(gè)可玩版本”“AI 重做前”“性能優(yōu)化后”。這樣隨時(shí)可以對(duì)比不同版本的表現(xiàn)。7.4 測(cè)試習(xí)慣自己玩讓別人玩自己玩能發(fā)現(xiàn)邏輯 bug但發(fā)現(xiàn)不了體驗(yàn)問題。我每隔幾天就會(huì)把鏈接發(fā)給朋友讓他們?cè)囃娌浧??？磩e人玩的時(shí)候你會(huì)發(fā)現(xiàn)很多自己完全沒意識(shí)到的問題有人不知道按哪個(gè)鍵交互有人找不到撤離點(diǎn)有人被 AI 打死之后不知道發(fā)生了什么。這些反饋比任何自動(dòng)化測(cè)試都有價(jià)值。游戲最終是給人玩的人的感受才是唯一標(biāo)準(zhǔn)。8. 后續(xù)可以繼續(xù)折騰的方向這個(gè)項(xiàng)目目前已經(jīng)是一個(gè)完整可玩的搜打撤原型但還有很多可以深挖的地方。我列幾個(gè)自己接下來想嘗試的方向也給有興趣的讀者一些參考。聯(lián)機(jī)對(duì)戰(zhàn)用 WebSocket 做幀同步或者狀態(tài)同步讓兩個(gè)玩家在同一張地圖里搜刮和對(duì)抗。技術(shù)難點(diǎn)在于延遲補(bǔ)償和作弊防護(hù)但玩法上的可能性會(huì)成倍增加。地圖編輯器做一個(gè)可視化的關(guān)卡編輯工具讓地圖設(shè)計(jì)從手寫數(shù)組變成拖拽生成。這個(gè)工具本身也可以用 Canvas 2D 來做算是“用 Canvas 做 Canvas 工具”。更豐富的 AI 生態(tài)現(xiàn)在的 AI 行為還比較單一?？梢约尤氩煌嚑I(yíng)的 AI它們之間也會(huì)互相攻擊或者加入“Boss 級(jí)”AI有獨(dú)特的技能和掉落。移動(dòng)端適配目前的操作還是鍵盤鼠標(biāo)為主。加一套虛擬搖桿和觸摸按鈕讓手機(jī)玩家也能玩。Canvas 2D 的觸摸事件處理很直接主要是 UI 布局需要重新設(shè)計(jì)。數(shù)據(jù)持久化用 IndexedDB 存玩家的倉庫、裝備、進(jìn)度做成一個(gè)輕量的“局外成長(zhǎng)”系統(tǒng)。這樣每局撤離帶出的物資就有了長(zhǎng)期價(jià)值玩家粘性會(huì)更強(qiáng)。這些方向每一個(gè)都可以獨(dú)立展開但核心思路是一樣的先用 Canvas 2D 把玩法跑通再考慮要不要引入更重的技術(shù)方案。很多時(shí)候最簡(jiǎn)單的工具反而能讓你把注意力集中在真正重要的事情上——游戲好不好玩。