1. 從“游戲引擎都沒用”說起這個(gè)螞蟻搬家項(xiàng)目到底在做什么第一次看到“游戲引擎都沒用純AI又上線了一款螞蟻搬家小游戲”這個(gè)標(biāo)題我腦子里蹦出來的第一個(gè)念頭是又是一個(gè)標(biāo)題黨。畢竟做小游戲的人都知道微信小游戲生態(tài)里用Unity、Cocos、Laya這些引擎才是主流純手寫Canvas做商業(yè)級(jí)小游戲聽起來像是回到2012年。但仔細(xì)看完這個(gè)項(xiàng)目的實(shí)現(xiàn)路徑之后我發(fā)現(xiàn)它其實(shí)踩中了一個(gè)非常有意思的交叉點(diǎn)AI輔助編碼 微信小游戲原生Canvas渲染 零引擎依賴。先說清楚這個(gè)項(xiàng)目是什么。它是一個(gè)運(yùn)行在微信小游戲環(huán)境里的“螞蟻搬家”玩法小游戲——玩家控制螞蟻把食物搬回巢穴途中要避開障礙、規(guī)劃路線、積累分?jǐn)?shù)。核心玩法不復(fù)雜屬于典型的休閑益智品類。但它的特殊之處在于整個(gè)項(xiàng)目沒有引入任何游戲引擎沒有Unity沒有Cocos Creator沒有LayaAir甚至連輕量級(jí)的Egret都沒用。渲染層完全基于微信小游戲提供的Canvas 2D接口手寫邏輯層用原生JavaScript組織開發(fā)過程中大量借助AI編碼工具比如Codex這類代碼生成助手來加速?gòu)牧愕揭坏拇罱?。這就引出一個(gè)很實(shí)際的問題為什么有人會(huì)選擇“不用引擎”這條路我自己的判斷是三個(gè)原因疊加。第一包體和啟動(dòng)速度。微信小游戲?qū)κ装w積有硬性限制主包不能超過4MB用Unity打包出來的小游戲即便做了裁剪首包也很容易逼近這個(gè)紅線而純Canvas項(xiàng)目的代碼量可以控制在幾百KB級(jí)別冷啟動(dòng)速度肉眼可見地快。第二AI編碼工具對(duì)純JS/Canvas項(xiàng)目的支持度遠(yuǎn)高于引擎項(xiàng)目。你讓AI幫你寫一個(gè)Canvas繪制循環(huán)、碰撞檢測(cè)、精靈動(dòng)畫它給出的代碼質(zhì)量相當(dāng)高但你讓AI幫你寫Unity的C#組件掛載邏輯它經(jīng)常會(huì)在API版本和生命周期上出錯(cuò)。第三學(xué)習(xí)門檻和可控性。引擎有自己的一套抽象層出問題時(shí)排查鏈路長(zhǎng)純Canvas項(xiàng)目所有東西都在你眼皮底下哪里畫錯(cuò)了、哪里幀率掉了打開微信開發(fā)者工具的Performance面板一看便知。這個(gè)項(xiàng)目適合誰來參考我認(rèn)為三類人最值得看。一是想入門微信小游戲但被引擎勸退的前端開發(fā)者你有JavaScript和Canvas基礎(chǔ)完全可以跳過引擎直接上手二是想用AI工具提升開發(fā)效率的獨(dú)立開發(fā)者這個(gè)項(xiàng)目展示了AI在哪些環(huán)節(jié)真正能幫上忙、哪些環(huán)節(jié)必須自己兜底三是做輕量級(jí)休閑游戲的產(chǎn)品同學(xué)理解技術(shù)邊界之后你在定需求時(shí)會(huì)更清楚什么能做、什么做不了。接下來我會(huì)把這個(gè)項(xiàng)目拆成幾個(gè)層面來講整體設(shè)計(jì)思路、Canvas渲染的核心細(xì)節(jié)、AI編碼工具的實(shí)際使用方式、以及我在類似項(xiàng)目里踩過的坑和排查經(jīng)驗(yàn)。不是教程是一個(gè)從業(yè)者做完之后的復(fù)盤。2. 整體設(shè)計(jì)與技術(shù)選型為什么敢不用引擎2.1 微信小游戲的技術(shù)底座到底給了什么要理解“不用引擎”這件事的可行性得先搞清楚微信小游戲平臺(tái)本身提供了什么。微信小游戲運(yùn)行在微信客戶端內(nèi)置的JavaScript引擎里它暴露了一套全局對(duì)象wx其中和渲染相關(guān)的是wx.createCanvas()。這個(gè)接口返回一個(gè)Canvas對(duì)象你可以拿到它的2D上下文然后就像在瀏覽器里一樣調(diào)用ctx.drawImage、ctx.fillRect、ctx.arc這些標(biāo)準(zhǔn)Canvas 2D API。關(guān)鍵區(qū)別在于瀏覽器里的Canvas是DOM元素微信小游戲里的Canvas是平臺(tái)托管的渲染表面。你不需要關(guān)心它怎么合成到屏幕上微信底層會(huì)處理。這意味著你只要有Canvas 2D的繪圖能力就能完成所有2D游戲的渲染。螞蟻搬家這種游戲所有視覺元素?zé)o非就是圓形螞蟻身體、矩形食物塊、線條路徑Canvas 2D完全覆蓋。再往上微信小游戲還提供了wx.createImage()來加載圖片資源、wx.createInnerAudioContext()來播放音效、wx.onTouchStart等觸摸事件接口。這些加起來構(gòu)成了一套“剛好夠用”的游戲開發(fā)基礎(chǔ)設(shè)施。你缺的不是能力而是引擎幫你封裝好的那些便利層——場(chǎng)景管理、精靈系統(tǒng)、物理引擎、動(dòng)畫狀態(tài)機(jī)。但對(duì)于螞蟻搬家這種量級(jí)的游戲這些便利層帶來的收益可能還抵不上引入引擎帶來的包體膨脹和調(diào)試復(fù)雜度。2.2 引擎方案和純Canvas方案的取舍賬我拿一個(gè)具體的對(duì)比表來說明這個(gè)決策過程。以下數(shù)據(jù)基于我實(shí)際參與過的幾個(gè)微信小游戲項(xiàng)目數(shù)值是量級(jí)參考不是精確值。對(duì)比維度Unity WebGL方案Cocos Creator方案純Canvas方案首包體積3.5MB~4.5MB1.5MB~2.5MB200KB~500KB冷啟動(dòng)時(shí)間中端機(jī)3~5秒1.5~3秒0.5~1.2秒開發(fā)語言C# 引擎APITypeScript 引擎APIJavaScript Canvas APIAI編碼工具支持度低API版本敏感中有模板依賴高純邏輯代碼熱更新靈活性受限于引擎機(jī)制較靈活完全自主控制復(fù)雜物理需求強(qiáng)中需手寫團(tuán)隊(duì)協(xié)作門檻高中低前端即可從這張表能看出來純Canvas方案的優(yōu)勢(shì)集中在體積、啟動(dòng)速度、AI工具友好度這三個(gè)維度。而它的劣勢(shì)也很明顯復(fù)雜物理、粒子特效、3D渲染這些需求手寫成本極高。螞蟻搬家這個(gè)項(xiàng)目的聰明之處在于它的玩法天然避開了這些劣勢(shì)——沒有物理碰撞的復(fù)雜模擬沒有粒子系統(tǒng)沒有3D。所有交互都是2D平面上的位置判斷和狀態(tài)切換。這里有一個(gè)選型原則值得記住引擎解決的是“復(fù)雜度的規(guī)?；瘑栴}”如果你的游戲復(fù)雜度沒有達(dá)到需要規(guī)?；芾淼牡夭揭娣炊秦?fù)擔(dān)。判斷標(biāo)準(zhǔn)很簡(jiǎn)單——如果你的游戲核心邏輯用一張A4紙就能畫完?duì)顟B(tài)流轉(zhuǎn)圖那就不需要引擎。2.3 AI編碼工具在這個(gè)項(xiàng)目里的真實(shí)角色標(biāo)題里說“純AI又上線了一款”這個(gè)“純AI”需要拆開理解。它不是說游戲本身是AI在玩而是說開發(fā)過程大量依賴AI編碼工具。具體來說Codex這類工具在這個(gè)項(xiàng)目里承擔(dān)了以下幾類工作第一類是樣板代碼生成。比如Canvas的初始化、游戲主循環(huán)的requestAnimationFrame封裝、觸摸事件的坐標(biāo)轉(zhuǎn)換這些代碼有固定模式AI生成的質(zhì)量很高基本一次成型。第二類是算法邏輯輔助。螞蟻搬家涉及路徑規(guī)劃螞蟻怎么繞開障礙走到食物、碰撞檢測(cè)螞蟻和障礙物的矩形/圓形相交判斷、分?jǐn)?shù)計(jì)算邏輯。這些算法AI能給出可用的實(shí)現(xiàn)但需要你理解之后做適配調(diào)整。第三類是調(diào)試輔助。遇到Canvas繪制錯(cuò)位、觸摸坐標(biāo)偏移、幀率抖動(dòng)這些問題時(shí)把現(xiàn)象描述給AI它能給出排查方向。但注意AI給的排查方向經(jīng)常是“通用可能性列表”真正定位到具體問題還是得靠你自己在微信開發(fā)者工具里打斷點(diǎn)、看日志。第四類是代碼重構(gòu)建議。當(dāng)項(xiàng)目文件變多、函數(shù)變長(zhǎng)之后讓AI幫你拆分模塊、提取公共函數(shù)效率比手動(dòng)重構(gòu)高不少。但有幾類工作AI幫不上忙或者說幫倒忙微信小游戲平臺(tái)特有的API調(diào)用比如wx.createCanvas的返回值處理、wx.onTouchMove的事件對(duì)象結(jié)構(gòu)AI經(jīng)?；煜秊g覽器和小程序的差異性能優(yōu)化AI給出的優(yōu)化建議往往是泛泛而談?wù)嬲行У膬?yōu)化必須基于微信開發(fā)者工具的性能面板數(shù)據(jù)游戲手感調(diào)優(yōu)螞蟻移動(dòng)速度、動(dòng)畫幀間隔、觸摸響應(yīng)閾值這些參數(shù)只能靠人反復(fù)試。3. Canvas渲染核心細(xì)節(jié)從零搭建一個(gè)2D渲染循環(huán)3.1 初始化Canvas和適配屏幕微信小游戲里創(chuàng)建Canvas的方式和瀏覽器不同。瀏覽器里你寫canvas idgame然后document.getElementById拿引用微信小游戲里你得調(diào)用wx.createCanvas()而且第一次調(diào)用返回的是上屏Canvas后續(xù)調(diào)用返回的是離屏Canvas。這個(gè)細(xì)節(jié)很關(guān)鍵搞錯(cuò)了就會(huì)出現(xiàn)“畫了半天屏幕上什么都沒有”的情況。// 獲取上屏Canvas const canvas wx.createCanvas(); const ctx canvas.getContext(2d); // 獲取屏幕尺寸信息 const systemInfo wx.getSystemInfoSync(); const screenWidth systemInfo.screenWidth; const screenHeight systemInfo.screenHeight; const pixelRatio systemInfo.pixelRatio; // 設(shè)置Canvas邏輯尺寸 canvas.width screenWidth * pixelRatio; canvas.height screenHeight * pixelRatio; // 縮放上下文讓后續(xù)繪圖按邏輯像素進(jìn)行 ctx.scale(pixelRatio, pixelRatio);這段代碼里有個(gè)容易踩的坑pixelRatio的處理。不同手機(jī)的物理像素和邏輯像素比例不同iPhone通常是2或3部分安卓機(jī)是1.5或2.75。如果你不處理這個(gè)比例在高分屏上畫出來的東西會(huì)模糊或者尺寸不對(duì)。處理方式就是上面這樣——Canvas的實(shí)際像素尺寸設(shè)為邏輯尺寸乘以比例然后通過ctx.scale把繪圖坐標(biāo)系縮回邏輯尺寸。這樣你后續(xù)所有繪圖代碼都用邏輯像素思考不用關(guān)心設(shè)備差異。實(shí)操心得wx.getSystemInfoSync()在新版基礎(chǔ)庫里有同步和異步兩個(gè)版本同步版本在冷啟動(dòng)階段調(diào)用可能返回不完整信息。穩(wěn)妥做法是在wx.onShow之后再讀一次或者用wx.getWindowInfo()替代。我遇到過在部分安卓機(jī)型上冷啟動(dòng)時(shí)screenWidth返回0的情況加一個(gè)兜底默認(rèn)值能避免白屏。3.2 游戲主循環(huán)的設(shè)計(jì)與幀率控制Canvas游戲的心臟是主循環(huán)。瀏覽器里通常用requestAnimationFrame微信小游戲也支持這個(gè)全局函數(shù)。但直接裸用會(huì)有問題不同設(shè)備的刷新率不同60Hz、90Hz、120Hz都有如果你的游戲邏輯和渲染都綁在requestAnimationFrame上高刷設(shè)備上游戲速度會(huì)變快。解決方案是固定時(shí)間步長(zhǎng)的邏輯更新加可變步長(zhǎng)的渲染。簡(jiǎn)單說就是邏輯更新按固定間隔比如每秒60次即16.67ms一次執(zhí)行渲染每次requestAnimationFrame都執(zhí)行但渲染用的數(shù)據(jù)來自最近一次邏輯更新的結(jié)果。const FIXED_DT 1000 / 60; // 固定邏輯步長(zhǎng)單位毫秒 let lastTime 0; let accumulator 0; function gameLoop(currentTime) { if (lastTime 0) { lastTime currentTime; requestAnimationFrame(gameLoop); return; } let deltaTime currentTime - lastTime; lastTime currentTime; // 防止切后臺(tái)回來后的巨大deltaTime導(dǎo)致邏輯爆炸 if (deltaTime 250) deltaTime FIXED_DT; accumulator deltaTime; // 固定步長(zhǎng)更新邏輯 while (accumulator FIXED_DT) { updateGame(FIXED_DT); accumulator - FIXED_DT; } // 渲染 renderGame(ctx); requestAnimationFrame(gameLoop); }這個(gè)模式的好處是無論設(shè)備刷新率是多少螞蟻的移動(dòng)速度、動(dòng)畫播放速度都是一致的。accumulator機(jī)制保證了邏輯更新的總次數(shù)和真實(shí)時(shí)間成正比。那個(gè)deltaTime 250的判斷是處理切后臺(tái)場(chǎng)景——用戶把微信切到后臺(tái)幾分鐘再回來currentTime的跳變會(huì)非常大如果不做限制while循環(huán)會(huì)執(zhí)行幾千次直接卡死。3.3 螞蟻和食物的繪制從圓形到精靈圖螞蟻搬家的視覺元素不復(fù)雜但要做到“看起來舒服”需要一些細(xì)節(jié)處理。最基礎(chǔ)的螞蟻可以用圓形加線條畫出來function drawAnt(ctx, ant) { const { x, y, angle, scale } ant; ctx.save(); ctx.translate(x, y); ctx.rotate(angle); ctx.scale(scale, scale); // 身體三個(gè)橢圓 ctx.fillStyle #2d1b0e; ctx.beginPath(); ctx.ellipse(0, 0, 8, 6, 0, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.ellipse(-10, 0, 6, 5, 0, 0, Math.PI * 2); ctx.fill(); ctx.beginPath(); ctx.ellipse(10, 0, 5, 4, 0, 0, Math.PI * 2); ctx.fill(); // 觸角 ctx.strokeStyle #2d1b0e; ctx.lineWidth 1.5; ctx.beginPath(); ctx.moveTo(13, -2); ctx.quadraticCurveTo(20, -10, 25, -8); ctx.stroke(); ctx.beginPath(); ctx.moveTo(13, 2); ctx.quadraticCurveTo(20, 10, 25, 8); ctx.stroke(); ctx.restore(); }但純幾何繪制在性能上有個(gè)隱患每幀重新構(gòu)建路徑的開銷。如果屏幕上有幾十只螞蟻每只都這樣畫beginPath和ellipse的調(diào)用次數(shù)會(huì)很多。優(yōu)化方案是預(yù)渲染到離屏Canvas把一只螞蟻畫好之后存成圖片后續(xù)用drawImage直接貼。// 預(yù)渲染螞蟻精靈 function createAntSprite() { const offscreen wx.createCanvas(); offscreen.width 64; offscreen.height 64; const octx offscreen.getContext(2d); // 在離屏Canvas上繪制螞蟻?zhàn)鴺?biāo)居中 octx.translate(32, 32); // ... 繪制代碼同上 return offscreen; } // 使用時(shí) const antSprite createAntSprite(); ctx.drawImage(antSprite, x - 32, y - 32);這個(gè)優(yōu)化在螞蟻數(shù)量超過20只時(shí)效果明顯幀率能從40fps左右回到穩(wěn)定60fps。代價(jià)是螞蟻的旋轉(zhuǎn)角度需要額外處理——drawImage不支持旋轉(zhuǎn)你得用ctx.save/translate/rotate/drawImage/restore這一套。但即便如此也比每幀重新畫路徑快。注意事項(xiàng)wx.createCanvas()創(chuàng)建的離屏Canvas在部分低端安卓機(jī)上有數(shù)量限制一般不超過10個(gè)。如果你給每種螞蟻、每種食物都創(chuàng)建一個(gè)離屏Canvas很容易超限導(dǎo)致創(chuàng)建失敗。穩(wěn)妥做法是用一個(gè)精靈圖集把所有元素畫在一張大離屏Canvas上通過drawImage的裁剪參數(shù)來取用。3.4 觸摸交互與坐標(biāo)轉(zhuǎn)換螞蟻搬家的操作方式是觸摸拖動(dòng)——玩家按住螞蟻拖到食物上或者點(diǎn)擊食物讓螞蟻過去搬。觸摸事件的處理有一個(gè)經(jīng)典坑事件坐標(biāo)和Canvas坐標(biāo)的映射。微信小游戲的觸摸事件對(duì)象里touch.clientX和touch.clientY是相對(duì)于屏幕的坐標(biāo)單位是邏輯像素。如果你的Canvas邏輯尺寸和屏幕邏輯尺寸一致上面初始化時(shí)就是這么做的那直接使用即可。但如果你做了縮放或者偏移就需要轉(zhuǎn)換。wx.onTouchStart((e) { const touch e.touches[0]; const x touch.clientX; const y touch.clientY; // 判斷是否點(diǎn)中了某只螞蟻 for (let ant of ants) { const dx x - ant.x; const dy y - ant.y; if (dx * dx dy * dy 30 * 30) { // 30像素命中半徑 ant.isDragging true; ant.dragOffsetX dx; ant.dragOffsetY dy; break; } } });命中檢測(cè)用平方距離比較而不是開方省一次Math.sqrt調(diào)用。在觸摸移動(dòng)事件里更新螞蟻位置時(shí)記得減去dragOffset否則螞蟻會(huì)“跳”到手指正下方手感很怪。還有一個(gè)細(xì)節(jié)微信小游戲的觸摸事件默認(rèn)會(huì)冒泡如果你在頁面上還有其他交互元素可能需要e.preventDefault()。但小游戲環(huán)境里通常不需要因?yàn)檎麄€(gè)屏幕都是你的Canvas。4. AI編碼工具實(shí)操哪些環(huán)節(jié)真能提效哪些是坑4.1 用Codex生成游戲骨架的完整流程我拿這個(gè)螞蟻搬家項(xiàng)目里“從零搭建游戲骨架”這個(gè)環(huán)節(jié)來舉例展示AI編碼工具的實(shí)際使用方式。假設(shè)你打開Codex的對(duì)話界面輸入這樣一段提示用JavaScript寫一個(gè)微信小游戲的骨架代碼要求 1. 使用wx.createCanvas創(chuàng)建上屏Canvas 2. 處理pixelRatio適配 3. 實(shí)現(xiàn)固定時(shí)間步長(zhǎng)的游戲主循環(huán) 4. 包含update和render兩個(gè)空函數(shù)供后續(xù)填充 5. 處理切后臺(tái)回來的deltaTime跳變Codex給出的代碼基本就是上面3.1和3.2兩段代碼的合并版質(zhì)量可用。但有幾個(gè)地方需要你手動(dòng)修正它可能會(huì)用wx.getSystemInfoSync()而不是更新的wx.getWindowInfo()它可能忘記處理requestAnimationFrame在微信小游戲里的兼容性部分舊版本基礎(chǔ)庫需要polyfill它給出的ctx.scale調(diào)用位置可能不對(duì)。我的做法是把AI生成的代碼當(dāng)作“第一稿”然后逐行審查對(duì)照微信官方文檔確認(rèn)每個(gè)API的用法。這個(gè)過程大概花10分鐘比完全手寫省一半時(shí)間但比直接復(fù)制粘貼多花5分鐘。這5分鐘是值得的因?yàn)锳I對(duì)微信小游戲API的“幻覺”率不低。4.2 AI輔助算法實(shí)現(xiàn)的邊界在哪里螞蟻搬家涉及幾個(gè)算法點(diǎn)螞蟻的移動(dòng)路徑計(jì)算、食物生成的位置隨機(jī)化、碰撞檢測(cè)。我分別說一下AI的表現(xiàn)。移動(dòng)路徑計(jì)算如果只是“從A點(diǎn)直線移動(dòng)到B點(diǎn)”AI寫得很好。但如果要“繞開障礙物”AI會(huì)給出A算法的實(shí)現(xiàn)。A本身沒問題但AI生成的A代碼通常沒有做網(wǎng)格化處理——它假設(shè)你有一個(gè)現(xiàn)成的網(wǎng)格地圖。而螞蟻搬家的障礙物是任意形狀的你需要先把連續(xù)空間離散化成網(wǎng)格這個(gè)預(yù)處理步驟AI經(jīng)常忽略。我的做法是讓AI先寫A然后自己補(bǔ)上網(wǎng)格化邏輯。食物生成隨機(jī)化這個(gè)簡(jiǎn)單AI一次成型。但要注意它可能生成的食物位置和障礙物重疊需要加一個(gè)“重新生成直到不重疊”的循環(huán)并設(shè)置最大重試次數(shù)防止死循環(huán)。碰撞檢測(cè)圓形和圓形的碰撞AI寫得沒問題圓形和矩形的碰撞它有時(shí)會(huì)搞混邊界條件。我建議自己寫一遍或者用成熟的分離軸定理SAT簡(jiǎn)化版。實(shí)操心得AI編碼工具最擅長(zhǎng)的領(lǐng)域是有大量公開代碼樣本的通用問題排序、查找、基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)操作最不擅長(zhǎng)的是平臺(tái)特定API 業(yè)務(wù)邏輯耦合的場(chǎng)景。判斷標(biāo)準(zhǔn)很簡(jiǎn)單——如果你在GitHub上能搜到100個(gè)類似實(shí)現(xiàn)AI大概率能寫好如果搜不到AI大概率會(huì)編。4.3 調(diào)試環(huán)節(jié)AI能幫什么忙調(diào)試是AI工具價(jià)值被低估的環(huán)節(jié)。舉一個(gè)我實(shí)際遇到的例子螞蟻拖動(dòng)時(shí)手指離開屏幕后螞蟻會(huì)“飛”回原位而不是停在拖動(dòng)位置。我把現(xiàn)象描述給AI它給出的排查方向包括觸摸結(jié)束事件沒有正確清除isDragging標(biāo)志、螞蟻位置更新邏輯在touchend之后仍然執(zhí)行、渲染層使用了舊的位置數(shù)據(jù)。順著這三個(gè)方向查發(fā)現(xiàn)是touchend事件里只清了isDragging但沒有把螞蟻的targetX/targetY更新為當(dāng)前位置導(dǎo)致下一幀的邏輯更新把螞蟻拉回了舊目標(biāo)點(diǎn)。這個(gè)問題如果自己排查可能要打十幾個(gè)斷點(diǎn)AI給了方向之后五分鐘定位。但AI的排查建議也有誤導(dǎo)的時(shí)候。另一次遇到幀率突然從60掉到30AI建議檢查“是否有內(nèi)存泄漏”“是否每幀創(chuàng)建了新對(duì)象”。查了半天沒發(fā)現(xiàn)問題最后用微信開發(fā)者工具的Performance面板一看是某張圖片的尺寸是2048x2048每幀drawImage縮放繪制導(dǎo)致的GPU開銷。AI沒有考慮到微信小游戲在移動(dòng)端GPU上的紋理尺寸限制。5. 常見問題與排查技巧實(shí)錄5.1 白屏問題的五種可能原因白屏是微信小游戲開發(fā)里最高頻的問題沒有之一。我整理了一個(gè)排查順序表按概率從高到低排列排查順序可能原因驗(yàn)證方式解決方案1Canvas未正確創(chuàng)建在wx.createCanvas()后打印返回值確保第一次調(diào)用返回上屏Canvas2繪制代碼未執(zhí)行在render函數(shù)首行加console.log檢查主循環(huán)是否啟動(dòng)3繪制坐標(biāo)超出屏幕打印繪制坐標(biāo)和Canvas尺寸檢查pixelRatio適配邏輯4顏色與背景同色臨時(shí)改繪制顏色為紅色檢查fillStyle設(shè)置5資源加載未完成檢查圖片onload回調(diào)加加載狀態(tài)管理實(shí)際排查時(shí)我習(xí)慣先在renderGame函數(shù)第一行加一個(gè)console.log(render called)如果控制臺(tái)沒有輸出說明主循環(huán)沒跑起來如果有輸出但屏幕還是白的說明繪制邏輯有問題。這個(gè)二分法能快速縮小范圍。5.2 觸摸事件不響應(yīng)的排查路徑觸摸事件不響應(yīng)通常有三個(gè)原因。第一是事件綁定時(shí)機(jī)——wx.onTouchStart必須在Canvas創(chuàng)建之后調(diào)用如果在wx.createCanvas之前綁定部分基礎(chǔ)庫版本會(huì)丟失事件。第二是層級(jí)遮擋——如果你在Canvas之上還創(chuàng)建了其他原生組件比如wx.createVideo它會(huì)攔截觸摸事件。第三是坐標(biāo)判斷邏輯錯(cuò)誤——觸摸事件觸發(fā)了但你的命中檢測(cè)沒通過。排查方法在wx.onTouchStart回調(diào)里第一行加console.log(e.touches[0].clientX, e.touches[0].clientY)確認(rèn)事件是否觸發(fā)、坐標(biāo)是否合理。如果坐標(biāo)是0或者負(fù)數(shù)說明坐標(biāo)轉(zhuǎn)換有問題如果坐標(biāo)正常但游戲沒反應(yīng)說明命中檢測(cè)邏輯需要調(diào)整。5.3 幀率波動(dòng)的優(yōu)化清單幀率波動(dòng)在純Canvas項(xiàng)目里比引擎項(xiàng)目更常見因?yàn)樗袃?yōu)化都得自己做。我按優(yōu)先級(jí)列一個(gè)優(yōu)化清單減少每幀的路徑構(gòu)建能用drawImage就不用beginPathfill。預(yù)渲染精靈是首選方案?？刂齐x屏Canvas數(shù)量不超過5個(gè)超了就合并成精靈圖集。避免每幀創(chuàng)建對(duì)象{x: 1, y: 2}這種字面量在循環(huán)里創(chuàng)建會(huì)觸發(fā)GC用對(duì)象池復(fù)用。降低繪制分辨率如果游戲畫面不需要Retina級(jí)別的清晰度把pixelRatio上限設(shè)為2能顯著降低GPU填充率壓力。批量繪制同類型元素所有食物用同一個(gè)fillStyle時(shí)可以合并路徑一次性繪制減少狀態(tài)切換。實(shí)測(cè)數(shù)據(jù)在一個(gè)有50個(gè)食物、10只螞蟻的場(chǎng)景里優(yōu)化前幀率在35~45fps波動(dòng)做了精靈預(yù)渲染和對(duì)象池之后穩(wěn)定在58~60fps。低端安卓機(jī)驍龍660級(jí)別也能跑到50fps以上。5.4 AI工具使用中的典型故障Codex這類工具在使用過程中會(huì)遇到一些環(huán)境問題。比如“無法加載組織設(shè)置”通常是網(wǎng)絡(luò)配置或賬號(hào)權(quán)限問題檢查登錄狀態(tài)和網(wǎng)絡(luò)連接即可?！澳Ｐ筒恢С帧钡膱?bào)錯(cuò)一般出現(xiàn)在工具版本和模型版本不匹配時(shí)更新到最新版通常能解決。安裝過程中如果卡在“Windows設(shè)置未完成”檢查系統(tǒng)權(quán)限和殺毒軟件攔截。這些問題的共同特點(diǎn)是它們和你的代碼無關(guān)是工具鏈本身的問題。遇到時(shí)不要懷疑自己的代碼先確認(rèn)工具環(huán)境是否正常。我的習(xí)慣是維護(hù)一個(gè)“工具環(huán)境檢查清單”每次開始新項(xiàng)目前過一遍能省掉很多無效排查時(shí)間。6. 這個(gè)項(xiàng)目后續(xù)還能怎么擴(kuò)展螞蟻搬家這個(gè)玩法本身有擴(kuò)展空間。從技術(shù)角度可以加入多螞蟻協(xié)同——玩家控制多只螞蟻需要設(shè)計(jì)簡(jiǎn)單的AI讓它們自動(dòng)尋路這會(huì)把A*算法的使用頻率拉高也是檢驗(yàn)純Canvas方案能否撐住更多實(shí)體渲染的好場(chǎng)景。從玩法角度可以加入食物類型區(qū)分——不同食物重量不同螞蟻搬運(yùn)速度不同這需要引入簡(jiǎn)單的物理模擬速度和質(zhì)量的關(guān)系但仍然是2D平面內(nèi)的計(jì)算Canvas完全能處理。從工程角度這個(gè)項(xiàng)目最有價(jià)值的擴(kuò)展方向是把AI編碼工具的使用流程標(biāo)準(zhǔn)化。比如建立一個(gè)提示詞模板庫針對(duì)“生成游戲主循環(huán)”“生成碰撞檢測(cè)”“生成觸摸交互”這些高頻任務(wù)每個(gè)任務(wù)有固定的提示詞結(jié)構(gòu)和驗(yàn)證清單。這樣下次做類似項(xiàng)目時(shí)從零到可玩demo的時(shí)間能壓縮到半天以內(nèi)。我自己在類似項(xiàng)目里的體會(huì)是純Canvas方案的上限比大多數(shù)人想象的高但它的下限也比引擎方案低——引擎幫你兜住的那些底你得自己兜。AI工具能幫你快速達(dá)到“能跑”的狀態(tài)但從“能跑”到“跑得穩(wěn)、跑得久”還是得靠對(duì)平臺(tái)特性的理解和反復(fù)的實(shí)測(cè)調(diào)優(yōu)。螞蟻搬家這個(gè)項(xiàng)目最值得參考的地方不是它用了AI而是它在“不用引擎”這個(gè)約束下把該做的細(xì)節(jié)都做到了位。