簡介JAVA ME 經(jīng)典飛行射擊游戲《9688雷霆戰(zhàn)機》的個人移植源碼包面向希望從實戰(zhàn)代碼理解 J2ME/MIDP 移動游戲開發(fā)的入門與進階學(xué)習(xí)者。內(nèi)容圍繞 MIDlet 主類入口、GameLoop 游戲循環(huán)、飛機/敵機/子彈對象模型、碰撞檢測與狀態(tài)機管理展開并涉及 Canvas 繪圖、鍵盤或觸摸事件響應(yīng)、圖像預(yù)加載及音頻播放等環(huán)節(jié)可幫助讀者建立較完整的小型移動游戲框架認知。壓縮包約 4.4MB文件總數(shù)顯示為 0、類型明細暫未提供源碼與工具屬性較明確包體以完整工程移植內(nèi)容為主。已有 1139 人學(xué)習(xí)或下載說明其在同類 J2ME 學(xué)習(xí)材料中有一定參考熱度。通過閱讀和調(diào)試這套移植代碼讀者可揣摩幀率控制、內(nèi)存分配與資源緩存等受限設(shè)備上的優(yōu)化思路也能練習(xí)代碼閱讀、問題定位和模塊拆解方法適合作為課程設(shè)計或個人練手的對照樣本。1. 一臺舊功能機里的飛行射擊這套 J2ME 雷霆戰(zhàn)機源碼在跑什么手里那臺 240×320 的舊按鍵機還能開機但能裝進去的游戲已經(jīng)不多了。這份個人移植的 J2ME 雷霆戰(zhàn)機源碼做的事就是讓一臺 Java ME 功能機重新跑起完整的豎版飛行射擊——飛機左右穿梭、子彈成排往外噴、敵機一波接一波分數(shù)寫進 RMS關(guān)機再開還在。整套工程不依賴任何第三方游戲引擎全靠 MIDP 自帶的 Canvas、GameAPI、RMS 和 Media API 拼起來用老式的 J2ME 開發(fā)工具包WTK導(dǎo)入就能編出 JAR。它適合三類人手里有舊機器想復(fù)刻點東西的、想看清 J2ME 游戲主循環(huán)到底怎么寫的、以及接手了一個老 JAR 要做二次開發(fā)的。代碼量不大但結(jié)構(gòu)完整從 MIDlet 生命周期到子彈對象池回收都留著清晰的切口改起來不用翻半天。2. 工程骨架與目錄結(jié)構(gòu)MIDlet 入口、Canvas 主循環(huán)和資源怎么擺先看骨架。J2ME 項目和普通 Java 工程最大的差別在于它必須有一個明確的「應(yīng)用入口」和一份聲明式的描述文件打包器靠這兩樣?xùn)|西才能把一堆 class 變成一個能裝進手機的 JAR。2.1 一份能直接導(dǎo)入 WTK 的目錄長什么樣這套源碼的目錄是標準的老式 J2ME 布局沒有 Maven 也沒有 Gradle純靠 IDE 的工程描述和 Ant 腳本src/ com/game/midlet/GameMIDlet.java MIDlet 入口管生命周期 com/game/core/GameCanvas.java 主循環(huán)、按鍵、繪制 com/game/core/Entity.java 實體基類坐標/速度/半徑 com/game/core/BulletPool.java 子彈對象池 com/game/core/EnemyManager.java 敵機波次調(diào)度 com/game/core/ScoreStore.java RMS 最高分 com/game/core/Res.java 圖片資源統(tǒng)一加載與緩存 res/ player.png enemy.png bullet.png bg.png bgm.mid shoot.wav META-INF/MANIFEST.MF Game.jad build.xmlsrc下面按職責(zé)分了 midlet 和 core 兩個包這個分層對 J2ME 來說已經(jīng)夠用了。res里的圖片必須是 PNG這是 MIDP 規(guī)范里唯一被強制支持的位圖格式別指望塞 JPG 進去。Game.jad是 Java 應(yīng)用描述文件很多機型在安裝時會先讀 JAD 再決定要不要下載 JAR里面的字段和 MANIFEST 必須對得上。2.2 MIDlet 生命周期startApp 里只做一件事入口類承擔(dān)的工作比想象中少。J2ME 的 MIDlet 有startApp、pauseApp、destroyApp三個狀態(tài)回調(diào)最容易踩的坑是把資源加載和線程啟動都堆在startApp里結(jié)果用戶按了掛機鍵再切回來第二份線程就起來了畫面越跑越快。import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; import javax.microedition.lcdui.Display; public class GameMIDlet extends MIDlet { private GameCanvas canvas; private Display display; protected void startApp() throws MIDletStateChangeException { if (canvas null) { display Display.getDisplay(this); Res.loadAll(); // 素材只在這里加載一次全部進靜態(tài)緩存 canvas new GameCanvas(this); canvas.startLoop(); // 主循環(huán)線程跟著 Canvas 走 } display.setCurrent(canvas); // 切回來只是重新設(shè)為當(dāng)前屏幕 } protected void pauseApp() { if (canvas ! null) canvas.pauseLoop(); // 掛機就停線程省電 } protected void destroyApp(boolean unconditional) { if (canvas ! null) canvas.stopLoop(); } public void exit() { // 游戲內(nèi)菜單調(diào)用 destroyApp(true); notifyDestroyed(); } }startApp里用canvas null做了一次性判斷這是整套代碼里最值錢的一行。J2ME 設(shè)備在來電、切換后臺、開蓋合蓋時都會反復(fù)觸發(fā)startApp和pauseApp如果不做這個判斷每次切回來就是一個新 Canvas 加一個新線程內(nèi)存和幀率一起崩。pauseLoop只是把running標志置 false 并讓線程自然退出循環(huán)不調(diào)Thread.stop()——那個方法在 CLDC 上行為不確定屬于血淚經(jīng)驗。參數(shù)上notifyDestroyed()是告訴運行環(huán)境「我自己要退了」必須主動調(diào)否則部分機型會認為應(yīng)用異常退出并彈提示。Res.loadAll()放在 Canvas 創(chuàng)建之前保證第一幀繪制時所有Image都已經(jīng)就位避免第一幀出現(xiàn)空指針。2.3 JAD 與 MANIFEST 里的關(guān)鍵字段JAR 裝不上手機八成是這兩個文件的問題。核心字段就這幾個MIDlet-Name: ThunderShooter MIDlet-Version: 1.0.0 MIDlet-Vendor: Personal MIDlet-1: Thunder, /player.png, com.game.midlet.GameMIDlet MicroEdition-Configuration: CLDC-1.1 MicroEdition-Profile: MIDP-2.0MIDlet-1的格式是「顯示名, 圖標路徑, 入口類全名」三段用英文逗號加空格分隔少一個空格某些機型就解析失敗。MicroEdition-Configuration和MicroEdition-Profile直接決定了這臺機器愿不愿意裝你的包寫 CLDC-1.1 意味著放棄 CLDC-1.0 的老機器寫 CLDC-1.0 則用不了浮點和部分集合 API。這套源碼選了 CLDC-1.1 MIDP-2.0是個務(wù)實的取舍——覆蓋不了最早那批單色機但換來了Image.createRGBImage和Manager這些必備能力。# 老式 WTK 的標準打包流程三步缺一不可 javac -bootclasspath $WTK/lib/cldcapi11.jar:$WTK/lib/midpapi20.jar \ -d classes $(find src -name *.java) $WTK/bin/preverify -classpath $WTK/lib/cldcapi11.jar:$WTK/lib/midpapi20.jar -d classes classes jar cfm ThunderShooter.jar META-INF/MANIFEST.MF -C classes . -C res .preverify這一步是 J2ME 獨有的它在每個 class 里插入棧映射信息供設(shè)備上的 KVM 做字節(jié)碼校驗。跳過它模擬器可能照跑真機上直接報校驗錯誤。構(gòu)建腳本里把它寫成 Ant 的一個exectarget 就行別手動敲命令太長容易漏 classpath。3. 核心玩法拆解從主循環(huán)到子彈與敵機的碰撞判定骨架搭好之后真正決定手感的是主循環(huán)和實體管理。這部分代碼不多但每一處都能直接換成「卡不卡」和「判定準不準」。3.1 幀循環(huán)里的 update 與 draw 分離J2ME 沒有游戲引擎的requestAnimationFrame最穩(wěn)的做法是自建線程加固定步長。這套代碼把邏輯更新和繪制徹底分開update只改數(shù)據(jù)paint只讀數(shù)據(jù)中間不互相調(diào)用。public class GameCanvas extends Canvas implements Runnable { private static final int FRAME_MS 40; // 25 FPS功能機的舒適區(qū) private volatile boolean running false; private Thread loopThread; private long lastTick; public void startLoop() { if (running) return; running true; lastTick System.currentTimeMillis(); loopThread new Thread(this); loopThread.start(); } public void pauseLoop() { running false; } public void run() { while (running) { long now System.currentTimeMillis(); int delta (int) (now - lastTick); if (delta FRAME_MS) { try { Thread.sleep(FRAME_MS - delta); } catch (InterruptedException e) { } continue; } lastTick now; update(delta); repaint(); serviceRepaints(); // 立刻刷別讓重繪消息在事件隊列里排隊 } } }FRAME_MS 40對應(yīng) 25 幀這是老機器的甜點值。往 30 幀調(diào)33ms不是不行但繪制一幀如果超時System.currentTimeMillis()的差值會越滾越大表現(xiàn)為「走兩步卡一下」。差值累積的處理方式是不補幀直接把lastTick重置到當(dāng)前時間寧可掉幀也不讓邏輯跳步。volatile修飾running是因為這個字段跨線程讀寫沒有它暫停指令在部分虛擬機上不會被主循環(huán)看到。repaint()加serviceRepaints()連用是 Canvas 的經(jīng)典寫法前者只是把重繪請求丟進事件隊列后者強制同步執(zhí)行到paint完成。少寫后面那一句畫面會滯后一到兩幀彈幕密集時感覺特別明顯。3.2 實體與對象池別讓內(nèi)存在彈幕里抖射擊游戲最怕的不是算力不夠是 GC 在關(guān)鍵時刻來一下。一局下來幾千發(fā)子彈如果每發(fā)都new Bullet()CLDC 上那個小堆幾秒鐘就撐不住。這套代碼的解法是固定容量對象池一次分配永不擴容。public class BulletPool { private final Bullet[] pool; private int liveCount; // [0, liveCount) 是活躍子彈 public BulletPool(int capacity) { pool new Bullet[capacity]; for (int i 0; i capacity; i) { pool[i] new Bullet(); // 啟動時一次性 new 完 } } public void spawn(int x, int y, int vx, int vy, int dmg) { if (liveCount pool.length) return; // 池滿直接丟棄絕不擴容 Bullet b pool[liveCount]; b.reset(x, y, vx, vy, dmg); } public void update(int delta) { for (int i liveCount - 1; i 0; i--) { Bullet b pool[i]; b.x b.vx * delta / 1000; b.y b.vy * delta / 1000; if (b.y -16 || b.y 400 || b.dead) { pool[i] pool[--liveCount]; // 尾元素覆蓋O(1) 回收 pool[liveCount] b; } } } }倒序遍歷是這份回收邏輯能成立的前提。pool[i] pool[--liveCount]把最后一個活躍子彈挪到當(dāng)前位置然后liveCount減一被回收的b則回到數(shù)組尾部等待復(fù)用。因為是倒序被挪過來的那個元素索引一定小于當(dāng)前的i下一輪不會重復(fù)處理。如果寫成正序挪過來的元素會被跳過子彈就「穿?！癸w過去不消失。capacity的取值我一般按「最壞情況下屏幕同屏子彈數(shù)」的 1.5 倍來定這套代碼給的是 64。滿池時丟棄而不是擴容這個設(shè)計是刻意的——寧可少一發(fā)子彈也不能在戰(zhàn)斗中觸發(fā)一次數(shù)組復(fù)制。敵機那邊同理EnemyManager里也是固定數(shù)組加波次調(diào)度不用Vector。3.3 碰撞判定圓形距離平方比矩形更貼合彈幕判定用矩形包圍盒是最省事的但豎版射擊游戲里機身窄、彈幕斜飛矩形框會在視覺上明明沒碰到的時候判定命中玩家感受很差。這套代碼用的是圓形判定只比較距離的平方省掉開方。public class Entity { public int x, y; // 左上角坐標 public int halfW, halfH; // 半寬半高用于繪制 public int cx, cy; // 判定圓心一般略小于視覺中心 public int radius; // 判定半徑 public void syncCenter() { cx x halfW; cy y halfH; } } public class Collision { public static boolean overlap(Entity a, Entity b) { int dx a.cx - b.cx; int dy a.cy - b.cy; int r a.radius b.radius; return dx * dx dy * dy r * r; // 比較平方不做開方 } }radius通常設(shè)成視覺尺寸的 0.6 到 0.7 倍這叫「寬容判定」玩家被擦彈擦過去不算死手感會好很多。自機受傷判定要比敵機更小一圈因為自機是玩家唯一在意的對象判定越寬容越舒服而敵機被打中的判定可以放大到 1.0讓射擊更有反饋感。syncCenter必須在坐標變化后調(diào)用或者干脆把cx/cy算成x halfW的 getter避免忘了同步導(dǎo)致判定錯位——這是個特別隱蔽的 bug畫面上全都對就是打不中。每幀的檢測順序是自機子彈 × 敵機 → 敵機子彈 × 自機 → 敵機 × 自機。前兩組是 O(m×n) 的雙層循環(huán)靠數(shù)量控制子彈池 64、敵機池 24保證在 CLDC 上也不卡。想再省一點可以按屏幕縱向分三段只跟同一段內(nèi)的對象比實測能砍掉約六成計算量。3.4 敵機波次與難度曲線波次調(diào)度沒寫成狀態(tài)機用的是一個很土但好調(diào)的結(jié)構(gòu)數(shù)據(jù)表加游標。// 每一波起始時刻(ms)、敵機數(shù)量、生成間隔(ms)、橫向起始位置、移動模式 private static final int[][] WAVES { { 0, 5, 800, 40, 0 }, // 模式0直線下落 { 6000, 8, 600, 100, 1 }, // 模式1正弦橫移 {13000, 12, 400, 20, 2 }, // 模式2斜向俯沖 {21000, 16, 300, 60, 3 }, // 模式3追蹤自機 };把難度寫成表的好處是調(diào)平衡的時候不用改代碼邏輯。想讓它更兇把間隔從 800 調(diào)到 500、數(shù)量加兩架重新編譯就行。游標推進的邏輯在EnemyManager.update里當(dāng)前波次的生成數(shù)量耗盡且場上敵機清空后才推下一波中間留一段空窗給玩家喘氣。這個「清空再推進」的條件如果不加波次會疊在一起第三關(guān)就能直接勸退。4. 屏幕與按鍵適配跨機型移植最容易翻車的一層同一份 JAR在 128×160 的機器上正常在 240×320 的機器上飛出屏幕在 176×208 的機器上按鍵全亂——這是移植 J2ME 游戲最典型的一天。適配層不做前面寫得再好也白搭。4.1 分辨率適配邏輯坐標系加一次性重采樣MIDP 的drawImage不支持縮放這是硬約束。想畫一張能適應(yīng)多種屏幕的圖只有兩條路運行時自己重采樣或者按固定邏輯分辨率畫、四周留黑邊。這套代碼兩條都用了。先看繪制時的坐標系換算private static final int LOGIC_W 240; private static final int LOGIC_H 320; protected void paint(Graphics g) { int sw getWidth(); int sh getHeight(); // 以邏輯分辨率為基準計算居中偏移不做非整數(shù)縮放 int ox (sw - LOGIC_W) / 2; int oy (sh - LOGIC_H) / 2; g.setColor(0x000010); g.fillRect(0, 0, sw, sh); // 先鋪滿底色防止邊緣露出臟像素 g.translate(ox, oy); // 之后所有繪制都用邏輯坐標 g.setClip(0, 0, LOGIC_W, LOGIC_H); // 裁剪掉超出的部分別畫到屏幕外 drawBg(g); enemies.draw(g); bullets.draw(g); player.draw(g); drawHud(g); g.translate(-ox, -oy); // 還原給后續(xù)可能的全屏繪制讓路 }g.translate加setClip這個組合是整段的核心。邏輯坐標統(tǒng)一按 240×320 算屏幕比它大的時候居中兩邊鋪深色底比它小的時候裁剪掉邊緣保證玩家不會被看不見的敵機打死。translate必須成對還原否則 HUD 和后續(xù)的全屏效果會畫到偏移位置上去這個 bug 排查起來特別費勁因為邏輯層的數(shù)據(jù)全是對的。屏幕比邏輯分辨率大的時候如果就這么留黑邊會很丑。更徹底的做法是啟動時把整套素材按比例重采樣一次// 啟動時按目標尺寸把素材重采樣一遍運行時零開銷 public static Image scaleImage(Image src, int dstW, int dstH) { int sw src.getWidth(); int sh src.getHeight(); int[] srcPx new int[sw * sh]; src.getRGB(srcPx, 0, sw, 0, 0, sw, sh); // 需要 MIDP 2.0 int[] dstPx new int[dstW * dstH]; for (int y 0; y dstH; y) { int sy y * sh / dstH; for (int x 0; x dstW; x) { dstPx[y * dstW x] srcPx[sy * sw x * sw / dstW]; // 最近鄰插值 } } return Image.createRGBImage(dstPx, dstW, dstH, true); }最近鄰插值出來的圖會有鋸齒但 J2ME 上沒得選——雙線性要浮點運算CLDC 1.0 直接不支持。createRGBImage的第四個參數(shù)processAlpha傳true才會保留透明通道傳false會得到一張黑底圖這個參數(shù)值錢。重采樣只發(fā)生在啟動時算力代價可以接受千萬別放進paint里一幀幾次重采樣能讓幀率掉到個位數(shù)。4.2 按鍵映射getGameAction 的返回值不一定靠得住Canvas.getGameAction(keyCode)理論上把物理鍵翻譯成UP/DOWN/LEFT/RIGHT/FIRE這些抽象動作實際上部分機型對方向鍵返回 0還有一批機器把方向鍵直接映射成數(shù)字鍵 2/4/6/8。只寫 switch 不寫兜底用戶會發(fā)現(xiàn)飛機紋絲不動。protected void keyPressed(int keyCode) { int action getGameAction(keyCode); switch (action) { case Canvas.UP: player.moveUp(); break; case Canvas.DOWN: player.moveDown(); break; case Canvas.LEFT: player.moveLeft(); break; case Canvas.RIGHT: player.moveRight(); break; case Canvas.FIRE: player.fire(); break; default: // 兜底部分機型方向鍵不映射游戲動作只報數(shù)字鍵 if (keyCode Canvas.KEY_NUM2) player.moveUp(); else if (keyCode Canvas.KEY_NUM8) player.moveDown(); else if (keyCode Canvas.KEY_NUM4) player.moveLeft(); else if (keyCode Canvas.KEY_NUM6) player.moveRight(); else if (keyCode Canvas.KEY_NUM5) player.fire(); break; } }這套兜底覆蓋了絕大多數(shù)功能機的鍵位習(xí)慣。還有個更細的問題某些機器的左軟鍵對應(yīng)-6、右軟鍵對應(yīng)-7取值是負數(shù)用getGameAction同樣返回 0需要單獨判斷。別指望一次寫完全部機型最實際的做法是在游戲里塞一個隱藏的「按鍵調(diào)試」界面把keyCode和getGameAction的返回值直接打在屏幕上裝機實測時看一眼就知道該補哪一行。4.3 觸屏與鍵盤雙支持MIDP 2.0 之后不少機器有了觸摸屏。這套代碼同時實現(xiàn)了pointerPressed但它不直接和鍵盤邏輯混在一起而是把觸摸坐標換算成邏輯坐標后交給同一套移動接口protected void pointerPressed(int px, int py) { int lx px - offsetX; // 屏幕坐標 - 邏輯坐標 int ly py - offsetY; if (isInsideFireButton(lx, ly)) { player.fire(); } else { player.moveTo(lx, ly - 20); // 手指上方留 20 像素別被手指擋住 } }py - 20這個偏移量是上手之后改的手指落點和玩家以為的位置有偏差直接moveTo會讓飛機貼著手指下沿。操作方式上鍵盤機是「按住方向鍵持續(xù)移動」觸屏是「拖哪走哪」兩套邏輯共用player.moveTo和player.moveBy兩個方法互不干擾。5. 避坑與排查真機上那五個最想砸手機的瞬間模擬器跑通只是開始真機才是驗收場。以下五條都是這套源碼在移植過程中實際遇到過的問題按「現(xiàn)象、原因、解決」的順序?qū)懹龅酵钪苯映?.1 白屏與花屏圖片和屏幕尺寸的坑現(xiàn)象一模擬器正常裝到真機啟動后一片白幾秒后自動退出。原因基本鎖定在圖片資源上——導(dǎo)出的 PNG 帶了 32 位 alpha 通道或者用了真機解碼器不認的非索引色格式。CLDC 上的 PNG 解碼器實現(xiàn)差異很大越老的機器越挑。解決辦法是把所有素材重新導(dǎo)出成 8 位索引色 PNG透明部分用純色鍵比如 0xFF00FF填充繪制時用drawRegion配合色鍵摳掉同時把單張圖控制在 128×128 以內(nèi)部分機型對單圖尺寸有硬上限。現(xiàn)象二畫面能出來但整體偏到一邊右邊一條黑。這是getWidth()返回的寬度和實際可視寬度不一致導(dǎo)致的某些滑蓋機在合蓋狀態(tài)下報的是內(nèi)屏寬度。解決方式是在sizeChanged(int w, int h)回調(diào)里重新計算偏移量而不是在構(gòu)造函數(shù)里算一次就存成常量。這個回調(diào)在屏幕旋轉(zhuǎn)和開合蓋時都會觸發(fā)是唯一可靠的時機。5.2 崩潰與內(nèi)存CLDC 的 API 紅線現(xiàn)象三玩到第三關(guān)黑屏退出日志里是OutOfMemoryError。兩個來源一是每幀new實體二是同一張圖被反復(fù)Image.createImage加載。前者的解法是第 3 章講的對象池后者更隱蔽EnemyManager里每種敵機如果各自加載一次貼圖同屏五架就是五份位圖在堆里。正確做法是建立Res類在startApp里把所有Image一次性 load 進靜態(tài)字段之后全局共用同一份引用?，F(xiàn)象四編譯通過真機一運行就NoSuchMethodError。說明用了 CLDC 1.0 里沒有的 API但編譯時的 classpath 指向了 CLDC 1.1 的庫。常見嫌疑人是Float.valueOf、String.format、java.util.regex和Collections.sort的部分重載。查法很簡單把工程配置里的 Configuration 改成 CLDC-1.0 再完整編譯一次編譯不過的地方就是雷區(qū)。真要用浮點就自己用整數(shù)放大一百倍來模擬別賭目標機型支持。5.3 交互與存檔按鍵、RMS、音效三連坑現(xiàn)象五方向鍵完全沒反應(yīng)但確認鍵能開火。就是 4.2 節(jié)講的getGameAction返回 0加上數(shù)字鍵兜底即可。順帶一提有些機器在keyPressed里收到的是重復(fù)事件按住方向鍵會以極快頻率觸發(fā)導(dǎo)致飛機瞬移到邊界——加一個keyReleased里清標志、keyPressed里判重的簡單鎖就能壓住。現(xiàn)象六最高分重啟后歸零。RecordStore寫完沒關(guān)是頭號原因部分機型的數(shù)據(jù)要等closeRecordStore()才落盤代碼里必須在finally里關(guān)。第二個原因是 RMS 的作用域跟 MIDlet 套件綁定改了MIDlet-Name或者換了簽名之前存的數(shù)據(jù)就等于沒了——所以名字這東西定了就別動。穩(wěn)妥的寫法是加載失敗一律返回 0存檔失敗直接吞掉異常絕對不能讓存檔問題把整個游戲拖崩。音效是同類問題里的第三顆雷。Manager.createPlayer在缺少 MMAPI 支持的機器上會拋異常甚至直接NoClassDefFoundError。整個播放邏輯必須包在 try-catch 里并且先用Manager.isTypeSupported(audio/midi)探一下不支持就靜音降級游戲照跑。6. 二次開發(fā)改造換一套美術(shù)、加一種武器之后怎么驗證改造這套源碼最省力的順序是「先換皮、再改數(shù)值、最后加機制」因為三者的驗證成本是遞增的。換皮只需要看不崩加機制要玩得爽中間隔著幾十次真機重啟。6.1 換皮改動面其實只有三處美術(shù)替換不要動代碼邏輯只碰三個地方res目錄下的 PNG 文件、Res.java里的尺寸常量、Entity子類里的halfW/halfH/radius。自機的機身窄radius給 6 到 8 就夠敵機體積大可以給到 14。改完一定要把BulletPool的容量重新算一遍——新美術(shù)如果讓子彈變大同屏能容納的數(shù)量就變了池子還是 64 的話會在密集彈幕時開始丟子彈表現(xiàn)為「明明在射但打不中」。6.2 加一種武器從對象池容量到渲染順序加激光武器的最小改動路徑是這樣的在BulletPool外面再開一個LaserPool容量小一點8 條足夠因為它們判定粗、存在時間長。渲染順序上激光要畫在普通子彈下面、背景上面否則會蓋住自機。數(shù)值上激光給「持續(xù)傷害」而不是「單次傷害」就需要在Entity上加一個dmgPerTick字段配合update(delta)按毫秒累加避免高幀率時傷害翻倍。做完這一步別忘了難度曲線也得跟著調(diào)——加了強力武器第四波的敵機數(shù)量不漲游戲就變成割草了。6.3 真機驗證清單改完別急著打包按這張表過一遍能省掉大量返工驗證項怎么驗不通過先看哪里冷啟動裝完直接開不看任何界面Res.loadAll是否在 Canvas 之前掛機切回按掛機鍵 30 秒再切回startApp的canvas null判斷滿屏彈幕打到第三波觀察是否掉幀BulletPool容量與FRAME_MS判定手感貼臉躲彈看是否被誤判radius取值與syncCenter調(diào)用存檔打出最高分退出重進closeRecordStore是否在 finally靜音降級在不支持 MIDI 的機器上跑音效 try-catch 是否完整這套流程我從第二個移植項目開始就沒斷過。早期吃過虧模擬器上一切正常真機裝上去第一波敵人還沒出完就白屏了回頭查了整整兩天才發(fā)現(xiàn)是某張圖的 alpha 通道問題。從那以后我每次改完一個副本都強制在真機上把所有波次跑滿一輪再打包不管改的是一行數(shù)值還是一次換膚。希望幫到你。本文還有配套的精品資源點擊獲取