機工程拆解)
簡介面向Processing初學者與視覺編程愛好者的類FlappyBird小游戲源碼包適合用來練習繪圖、動畫循環(huán)、碰撞檢測、鍵盤輸入與面向對象組織。項目將小鳥、管道和通用邏輯拆分為獨立模塊配合圖片與音效素材較完整地呈現(xiàn)角色運動、隨機障礙生成、得分判定與游戲狀態(tài)切換的實現(xiàn)思路讀者可在其基礎上調(diào)整參數(shù)、替換素材或擴展玩法借此理解小型交互游戲從繪制到邏輯閉環(huán)的基本結構也可作為課堂示例拆解。壓縮包共12個文件以4個pde源碼為主另有3張png圖像、3個mp3與1個wav音頻及1個properties配置文件整體約2.48MB源碼、素材與項目設置相對齊全。已有1041人學習適合Processing入門者自學練手也便于教師布置圖形交互作業(yè)時參考。1. 用 Processing 復刻 FlappyBird難的不是畫鳥用 Processing 寫一個類 FlappyBird 的橫版躲避小游戲網(wǎng)上能搜到的版本大多兩百行上下圖能跑、鳥能飛可真拿去給人玩十分鐘內(nèi)必然被問三句話我明明沒碰到管子怎么就死了重開一局分數(shù)怎么還掛著上一局的為什么在我機器上特別飄、換臺電腦又變得特別難這份源碼包正面處理的就是這三件事——重力、跳躍、管道、碰撞、狀態(tài)機各自拆成互不越界的幾塊參數(shù)集中在文件頭部改一個數(shù)字就能改手感。適合兩類人剛學完 setup/draw 想找個完整小項目練手的新手以及課程設計要做橫版躲避 Demo、需要一份能講清每行代碼為什么這么寫的骨架的從業(yè)者。下面按“先把物理立住、再讓管道可復用、最后把狀態(tài)和參數(shù)收干凈”的順序拆。2. 主循環(huán)與重力把“手感”拆成四個可調(diào)參數(shù)手感這東西聽起來玄學落到代碼里其實就是四個數(shù)字重力多大、點擊給多大沖量、最大下落速度多少、點擊有沒有冷卻。四個數(shù)字定死之前先得把數(shù)據(jù)結構和主循環(huán)擺對否則后面每加一個功能都在還債。2.1 為什么用 PVector 存速度而不是一個 float vyProcessing 的坐標系原點在左上角y 軸向下為正所以“向上跳”必須給負值——這個符號是最容易寫反的地方。我一般把方向直接編進常量名里JUMP_IMPULSE寫成 -7.6 并在旁邊注釋“負值向上”比事后查 bug 便宜得多。用PVector而不是三個 float理由有三條一是位置和速度天然成對重置時pos.set(...)、vel.set(0,0)一行解決二是以后想加橫向風、管道推速、震屏偏移直接pos.add(wind)就行不用再補一堆變量三是PVector是可變對象pos.add(vel)原地修改、不產(chǎn)生新對象在每幀都跑的 draw 里不會給 GC 添麻煩。唯一要小心的是別寫成pos pos.add(vel)這種看著像“產(chǎn)生新向量”的寫法容易讓后面接手的人誤判語義。// 坐標原點在左上角y 軸向下為正向上跳必須給負值 final float GRAVITY 0.42; // 每幀60fps 基準疊加到速度上的加速度 final float JUMP_IMPULSE -7.6; // 點擊瞬間的垂直速度負值 向上 final float MAX_FALL_SPEED 11.0; // 終端速度防止掉幀時一幀穿過管道 final float BIRD_X 120; // 鳥的橫坐標固定世界向左滾動 PVector pos; PVector vel; float gravity; // 用變量而不是直接用常量方便第 6 章在線調(diào)參 void setup() { size(480, 720); frameRate(60); gravity GRAVITY; resetBird(); } void resetBird() { pos new PVector(BIRD_X, height * 0.42); vel new PVector(0, 0); }邏輯說明pos只存位置vel只存速度重力永遠不直接改pos而是先進入vel、再由vel進入pos。這個“加速度→速度→位置”的兩級積分是所有運動的基礎骨架順序寫反先加位置再加加速度會讓鳥在低幀率下出現(xiàn)明顯的臺階感。resetBird()單獨抽出來是為第 4 章的重開邏輯留接口避免重開時到處復制兩行初始化。參數(shù)說明GRAVITY決定松手后的“沉”度0.35 以下像月球漫步0.6 以上基本救不回來JUMP_IMPULSE決定一次點擊抬多高絕對值越大越“彈”MAX_FALL_SPEED是安全閥后面碰撞那章會用到它BIRD_X固定不動因為滾動的是世界不是鳥這一點跟很多橫版卷軸的做法一致能讓碰撞判定只在一個方向上變化。提示frameRate(60)只是“請求”不是承諾。窗口被遮擋、圖片過大、后臺開了別的程序實際幀率都會掉這就是下一節(jié)要處理的問題。2.2 歸一化系數(shù)與固定步長兩種讓手感不隨幀率漂移的寫法如果直接寫vel.y GRAVITY; pos.y vel.y;在 60fps 下一切正?？梢坏嶋H幀率掉到 30同樣的重力每秒只累加 30 次鳥的下落明顯變慢玩家會覺得“這游戲今天特別簡單”。這種隨設備漂移的手感是最難復現(xiàn)的 bug因為它在你機器上永遠不出現(xiàn)。寫法 A 是系數(shù)歸一化一行搞定void draw() { float k 60.0 / max(1.0, frameRate); // 以 60fps 為基準的縮放系數(shù) k constrain(k, 0.5, 3.0); // 卡頓太久時不至于一幀跳出去 vel.y gravity * k; vel.y min(vel.y, MAX_FALL_SPEED); // 終端速度 pos.y vel.y * k; }邏輯說明k的物理含義是“這一幀相當于幾個標準幀”幀率越低 k 越大重力累加得越多。constrain那行是后悔藥——窗口被最小化再還原時frameRate可能瞬間變成一個很小的值k 會變成幾十鳥一幀就飛出屏幕夾到 3 倍以內(nèi)基本能兜住。參數(shù)說明這種寫法有個理論缺陷重力和位移同時乘 k速度項實際被放大了 k2 量級的誤差幀率波動大時軌跡會有細微差別。對 FlappyBird 這種只有豎直一維運動的場景完全夠用但如果后面要加拋物線彈道、要算落點就得換寫法 B。寫法 B 是固定步長累加器把物理推進和渲染徹底解耦final float FIXED_DT 1.0 / 60.0; // 物理固定按 1/60 秒推進 float accumulator 0; int lastMillis 0; void draw() { int now millis(); float frameTime (now - lastMillis) / 1000.0; lastMillis now; frameTime min(frameTime, 0.25); // 防止窗口掛起后一次性補幾百幀 accumulator frameTime; while (accumulator FIXED_DT) { stepPhysics(FIXED_DT); accumulator - FIXED_DT; } render(); // 渲染每幀只做一次直接用 pos 畫 } void stepPhysics(float dt) { vel.y GRAVITY * 60 * dt; // GRAVITY 按“每幀”定義這里換算成每秒 vel.y min(vel.y, MAX_FALL_SPEED); pos.y vel.y * 60 * dt; }邏輯說明不管渲染幀率是多少物理永遠以 1/60 秒為單位推進一幀內(nèi)可能要跑 0 次高刷屏也可能跑 3 次卡頓但每一步的數(shù)值完全一致所以同一串點擊時間戳在任何機器上都能復現(xiàn)出同一條軌跡。min(frameTime, 0.25)是必須的否則斷點調(diào)試回來那一幀會一次性補上幾十步物理鳥直接穿模。參數(shù)說明FIXED_DT不建議小于 1/120否則一步的位移只有零點幾像素屬于浪費也不建議大于 1/45否則快速下落時單步位移過大配合第 3 章的碰撞會漏判。方案代碼量軌跡一致性適用場景系數(shù)歸一化3 行一般低幀率下有偏差單機小 Demo、只想快速跑通固定步長20 行強同輸入必同軌跡要做回放、要做自動測試、要交付2.3 跳躍沖量、終端速度與連點冷卻跳躍有兩種寫法差別比想象中大。vel.y JUMP_IMPULSE是硬置每次點擊后鳥的上升軌跡完全一致玩家能形成肌肉記憶vel.y JUMP_IMPULSE是疊加連點會累加速度鳥能一路竄到屏幕頂端。早期我圖省事用了疊加結果玩家全程狂點就能過管道形同虛設這是最典型的一次翻車。硬置還要配一個冷卻否則鼠標事件和鍵盤事件在同一幀里都觸發(fā)時等于白按一次int lastJumpMillis -1000; final int JUMP_COOLDOWN 90; // 毫秒防止同幀多輸入事件疊加 void doJump() { if (millis() - lastJumpMillis JUMP_COOLDOWN) return; lastJumpMillis millis(); vel.y JUMP_IMPULSE; // 硬置不是 } void keyPressed() { if (key ) doJump(); } void mousePressed() { doJump(); }邏輯說明冷卻窗口取 90ms 左右比人類最快連點間隔約 100ms稍短正常操作不會覺得卡但能把同一幀的重復事件吃掉。lastJumpMillis初值給 -1000 而不是 0是為了讓游戲開始時的第一次點擊不被冷卻擋住。再補兩個視覺細節(jié)。第一是終端速度它除了防止穿模還讓鳥在長時間不下落時有個穩(wěn)定姿態(tài)不會越掉越快變成自由落體。第二是傾斜角用速度映射旋轉玩家的操作反饋立刻直觀// 把速度映射成機身角度上升時抬頭下落時低頭 float angle map(vel.y, JUMP_IMPULSE, MAX_FALL_SPEED, -0.42, 1.45); angle constrain(angle, -0.42, 1.45); // -0.42rad≈-24°1.45rad≈83°這兩個數(shù)字-24° 和 83°是試出來的抬得太高像在倒著飛低得不夠又看不出俯沖。它們不影響任何邏輯純粹是讓判定和視覺對得上的心理暗示——玩家覺得“鳥頭朝下沖進管子”比“鳥平平地貼上去”更容易接受死亡。3. 管道生成與碰撞對象池、開口公式和一個收縮系數(shù)管道是這類游戲里唯一會持續(xù)增長的東西寫法不對就會出現(xiàn)“越玩越卡”和“明明沒碰到卻死了”兩大頑疾。前者是內(nèi)存問題后者是數(shù)據(jù)不同源問題兩個都得從數(shù)據(jù)結構層面解決。3.1 用對象池代替 remove/add最直覺的寫法是每幀pipes.add(new Pipe())、出屏后pipes.remove(0)。ArrayList的remove(0)會把后面所有元素整體搬移一位add在容量不足時還要擴容復制管道保持在屏幕上 3~4 根、每 2 秒輪換一次看著不頻繁但配合每幀的遍歷和第 4 章的碰撞實測每過七八根管子就有一次可感知的頓挫。改成固定長度數(shù)組加環(huán)形復用就干凈了class Pipe { float x; // 管道左邊緣的世界坐標 float gapY; // 開口中心的縱坐標 float gapH; // 開口總高度 boolean scored; // 是否已計分見 4.2 } final int PIPE_COUNT 4; Pipe[] pipes new Pipe[PIPE_COUNT]; float pipeW 78; // 管道寬度 float gapH 180; // 開口高度 float spacing 240; // 相鄰兩根管道的水平間距 void initPipes() { for (int i 0; i PIPE_COUNT; i) { pipes[i] new Pipe(); pipes[i].x width 120 i * spacing; pipes[i].gapY random(gapH * 0.6, height - gapH * 0.6); pipes[i].gapH gapH; pipes[i].scored false; } } void updatePipes(float dx) { for (Pipe p : pipes) { p.x - dx; // 世界向左滾動 if (p.x pipeW 0) { // 完全出屏才回收 p.x PIPE_COUNT * spacing; // 接到隊尾而不是 new 一個 p.gapY random(p.gapH * 0.6, height - p.gapH * 0.6); p.scored false; } } }邏輯說明回收時用p.x PIPE_COUNT * spacing而不是p.x width這是整個對象池能穩(wěn)住的關鍵。如果重置到width一旦某幀因為卡頓導致dx變大隊尾的管道會和剛回收的管道擠在一起甚至重疊加上“一整輪的間距”之后隊列的相對位置永遠均勻間距不會因為幀率波動而漂移。參數(shù)說明PIPE_COUNT取 4 是算出來的屏幕寬度 480 除以間距 240 約等于 2再多留兩根在屏幕右側待命保證任何時刻都有管子接上。pipeW取 78 是視覺寬度碰撞時用的是另一套收縮后的判定框兩者刻意不同源但共用x和gapY——只要繪制和判定讀的是同一份gapY/gapH就不會出現(xiàn)畫一套算一套的穿模。3.2 開口高度與水平間距難度曲線的三個旋鈕真正決定難度的是三個量gapH開口高度、spacing水平間距、dx每幀滾動像素。前兩個是空間后一個是時間三者可以換算成一個玩家能感知的指標——反應時間從管道進入屏幕右緣到抵達鳥的位置可用的秒數(shù) ≈ (width - BIRD_X) / (dx * 60)按 480 寬、鳥在 120、dx 取 2.2 計算大約是 2.7 秒當 dx 漲到 3.4只剩 1.76 秒。低于 0.8 秒基本就是背板而不是反應不適合作為起始難度。這個換算看著簡單但它把“我調(diào)了速度好像變難了”變成“反應窗口從 2.7 秒壓到 1.8 秒”調(diào)參時心里有數(shù)。難度遞增用一個 0~1 的進度量做線性插值30 分封頂void updateDifficulty() { float d constrain(score / 30.0, 0, 1); // 0~130 分后不再變難 gapH lerp(190, 140, d); // 開口 190 - 140 scrollSpeed lerp(2.2, 3.4, d); // 每幀像素 spacing lerp(250, 210, d); }邏輯說明lerp的三個參數(shù)是起點、終點、進度寫起來比手算start (end - start) * d清楚。注意這里只改“下一根被回收的管道”的參數(shù)已經(jīng)在屏幕上的管道保持原樣——如果每幀都去改所有管道的gapH玩家會看到管子開口像呼吸一樣收放那才是真正的玄學。參數(shù)說明gapH的下限 140 是硬邊界再低就會出現(xiàn)“鳥的判定框加上管道寬度已經(jīng)不允許任何操作余量”的情況理論上還能過實際全靠運氣。spacing的下限 210 是為了保證兩根管子不會同時在鳥的位置附近形成夾擊。3.3 碰撞AABB 加一個 0.75 收縮系數(shù)碰撞用軸對齊包圍盒AABB就夠了不要去做像素級檢測。像素級不但慢而且會把貼圖上的描邊、陰影算進去玩家看到的是“我貼著邊過去了”判定卻認為撞上這種不公平感比直接撞死更勸退。// 鳥的判定框比貼圖小 25%這是讓玩家覺得“公平”的關鍵 final float HIT_SCALE 0.75; boolean hitPipe(Pipe p) { float halfW 24 * 0.5 * HIT_SCALE; float halfH 24 * 0.5 * HIT_SCALE; // 橫向不相交直接返回省掉后面的縱向判斷 if (pos.x halfW p.x || pos.x - halfW p.x pipeW) return false; float topBottom p.gapY - p.gapH * 0.5; // 上管的底邊 float botTop p.gapY p.gapH * 0.5; // 下管的頂邊 if (pos.y - halfH topBottom) return true; // 撞上管 if (pos.y halfH botTop) return true; // 撞下管 return false; }邏輯說明先做橫向粗篩再做縱向判斷是因為橫向不相交的概率遠高于縱向提前返回能省掉大部分計算。上管的繪制高度就是topBottom下管從botTop畫到height判定和繪制共用這兩個變量所以只要gapY和gapH不被別的邏輯偷偷改掉就永遠不會出現(xiàn)“看著沒碰到卻死了”。參數(shù)說明HIT_SCALE是本項目里最值得單獨拿出來講的一個數(shù)。取 1.0 時判定框和貼圖完全重合玩家會覺得“擦邊就死”取 0.75 相當于允許鳥的像素邊緣壓進管道 3 像素左右視覺上有驚無險操作反饋立刻變好。低于 0.6 就反過來了看著撞進去卻沒死信任感崩得比撞死還快。注意判定框收縮只縮鳥不要縮管道?？s管道會讓開口看起來比實際大玩家對距離的判斷會持續(xù)失準。4. 狀態(tài)機與計分READY / PLAYING / GAME_OVER 三態(tài)怎么切把狀態(tài)和計分單拎一章是因為這類小游戲的 bug 有七成出在這里重開不清零、一次過管加兩分、死亡后還在跑物理。用布爾量拼狀態(tài)是萬惡之源。4.1 用 enum 管狀態(tài)別用三個 boolean 拼boolean playing、boolean gameOver、boolean started三個變量一起用必然出現(xiàn)playing gameOver同時為真的中間態(tài)。我見過最典型的一次是重開時忘了清gameOver鳥在 READY 界面就開始自由落體玩家還沒反應過來已經(jīng)死了。enum加switch強制每次只走一個分支這類 bug 從結構上就不存在。enum GameState { READY, PLAYING, GAME_OVER } GameState state GameState.READY; void update() { switch (state) { case READY: // 待機時鳥做上下浮動不施加重力 pos.y height * 0.42 sin(millis() / 300.0) * 8; break; case PLAYING: stepPhysics(FIXED_DT); updatePipes(scrollSpeed); updateDifficulty(); if (hitAnyPipe() || pos.y height - 12) { state GameState.GAME_OVER; } checkScore(); break; case GAME_OVER: // 只落不飛掉到接近底部就停住 if (pos.y height - 20) { stepPhysics(FIXED_DT); } break; } }邏輯說明READY 狀態(tài)下完全不碰vel鳥的位置每幀由正弦函數(shù)直接給這樣玩家看到的是一只懸停的鳥而不是一只正在下墜的鳥。PLAYING 分支里先算物理再算管道再判碰撞順序不能反——先判碰撞再移動位置會出現(xiàn)判定用的是上一幀坐標的情況表現(xiàn)為“穿過去半根才死”。GAME_OVER 分支保留物理但不接受輸入鳥會繼續(xù)下墜一段再停住這個細節(jié)讓死亡有重量感。參數(shù)說明height - 12是落地判定的閾值取 12 是鳥貼圖半高配合height - 20的停止線讓鳥落在地上而不是陷進去。millis() / 300.0里的 300 是浮動周期改小變快、改大變得更慢。4.2 計分用 scored 標志位不要用距離閾值見過不少實現(xiàn)寫成if (abs(pos.x - p.x) 5) score;這行代碼在管道每幀移動 2~3 像素的情況下會漏判一幀跨過去了或重復判閾值太大連續(xù)兩幀都滿足。正確做法是給每根管道一個“是否已計分”的布爾位條件寫成“鳥已經(jīng)越過管道的右邊緣”天然冪等。void checkScore() { for (Pipe p : pipes) { if (!p.scored pos.x p.x pipeW) { p.scored true; // 置位保證一根管道只計一次 score; } } }邏輯說明pos.x p.x pipeW是“整只鳥含判定框都過了管道右邊緣”的意思比用中心點判斷更符合直覺。p.scored在 3.1 的回收邏輯里被重置為false所以同一根管道被復用后還能再計一次分整套流程閉環(huán)。參數(shù)說明score建議單獨維護不要復用frameCount或任何全局計數(shù)。分數(shù)一旦和幀數(shù)綁在一起重開就會出問題——frameCount是自 sketch 啟動以來的累計值永遠不會歸零。4.3 重開一局要重置的清單重開是這類游戲最容易留殘影的地方。我一般寫一個resetAll()作為唯一入口把所有會變的東西列成清單一條一條對著寫而不是散落在keyPressed里。void resetAll() { score 0; scrollSpeed 2.2; gapH 190; spacing 250; resetBird(); // pos / vel initPipes(); // 管道的 x / gapY / gapH / scored lastJumpMillis -1000; stateStartFrame frameCount; state GameState.READY; }邏輯說明清單式重置的好處是新增字段時一眼能看出“這里要補一行”。管道必須走initPipes()而不是只清scored因為上一局的管道位置會留在屏幕中間重開后鳥直接撞上去。參數(shù)說明stateStartFrame是自己記的幀號用途見下。注意frameCount是自 sketch 啟動以來的全局幀數(shù)重開不會清零。任何“每 30 幀閃一次”的動畫都要寫成frameCount - stateStartFrame直接用frameCount % 30會在重開后表現(xiàn)得不規(guī)律。5. 五條血淚踩坑從“能跑”到“能玩”之間隔著什么下面這五條是照著別人代碼改或者自己從頭寫都會撞上的前三條偏畫面與性能后兩條偏邏輯判定。每條按“現(xiàn)象→原因→解決”說能對號入座就不用重走一遍。5.1 畫面與性能類第一條越玩越卡七八根管子之后明顯頓一下?，F(xiàn)象是前面幾根很順過了十來根開始每隔一兩秒卡一幀幀率顯示從 60 掉到 45 又彈回來。原因是每幀在draw()里new Pipe()或者new PVector()管道輪換時對象不斷創(chuàng)建又丟棄垃圾回收周期被打斷表現(xiàn)為規(guī)律性的頓挫。解決是把管道改成 3.1 的固定數(shù)組復用PVector只在resetBird()里創(chuàng)建一次后續(xù)全部用set()和add()原地修改。改完再測幀率曲線會變成一條直線。第二條第一幀圖片黑塊或者鳥身后拖著一條殘影?，F(xiàn)象是啟動瞬間鳥的位置是一塊黑色矩形或者飛行時背后留下一串半透明殘像。原因有兩個一是loadImage()寫在draw()里第一幀圖片還沒解碼完就畫了二是draw()開頭漏了background()上一幀沒被覆蓋。解決是把所有l(wèi)oadImage()挪進setup()并檢查返回值是否為 null同時在draw()第一行無條件調(diào)用background()。如果確實需要拖影效果用半透明矩形疊一層別指望不清屏。第三條判定框和看到的鳥對不上明明擦過去了卻說撞上?，F(xiàn)象是視覺上鳥和管道還有一兩個像素的間隙游戲卻判定死亡或者反過來。原因通常是渲染用了P2D或做了scale()縮放而碰撞判定還在原始坐標系里算。解決是把碰撞計算統(tǒng)一放在世界坐標里做需要縮放或旋轉時用pushMatrix()/popMatrix()把變換包起來畫完就彈棧絕不讓變換泄漏到判定邏輯里。5.2 邏輯與輸入類第四條鳥從管道中間穿過去沒觸發(fā)死亡?，F(xiàn)象是偶爾一次下落特別快鳥直接出現(xiàn)在管道另一側判定完全沒反應。原因是掉幀導致單幀位移超過了判定框高度——vel.y達到 20 以上時一幀就能移動 20 像素而鳥的判定框高度只有 18 像素中間那一小段被整幀跳過了。解決分兩層先把MAX_FALL_SPEED壓到 11 以內(nèi)保證單幀位移小于判定框高度再在stepPhysics里做子步進位移大于半高就拆成多次小步每步都判一次碰撞。第五條一次過管加了兩分或者重開一局分數(shù)接著上一局算?，F(xiàn)象有兩種但根子是同一個。前者是計分條件寫成了“鳥在管道范圍內(nèi)”這個條件連續(xù)多幀為真每幀都加一次分后者是score沒進resetAll()。解決是把計分改成 4.2 的標志位寫法條件收緊到“越過右邊緣”并把score 0明確寫進重置清單。順手把scored也一起重置否則復用的管道會帶著上一局的計分狀態(tài)。還有一個容易被忽略的輸入問題想實現(xiàn)“按住鼠標連跳”的人會發(fā)現(xiàn)按住不動鳥不飛。mousePressed()函數(shù)是按下瞬間觸發(fā)一次按住不會重復調(diào)用這是符合預期的要連跳得自己判斷mousePressed這個布爾變量并在draw()里按冷卻節(jié)奏觸發(fā)doJump()。這個坑跟判定無關但很多人第一次做都會卡在這兒。6. 把參數(shù)擰成一張表調(diào)手感、驗證與一份可復現(xiàn)的自檢流程前面所有常量都是“我覺得合適”的值真正交付前必須按目標設備調(diào)一輪。我的習慣是把可調(diào)參數(shù)從final常量挪到普通成員變量用一個調(diào)試面板實時改邊玩邊調(diào)比改一次重跑一次快十倍。參數(shù)起始值調(diào)整步長觀察什么gravity0.42±0.03松手后下墜的“沉”度太快會來不及點JUMP_IMPULSE-7.6±0.3一次點擊抬升的高度太小會被管道憋死MAX_FALL_SPEED11±1掉幀時會不會穿管超過判定框半高就危險gapH190→140±10新手第一次能不能過140 是硬下限spacing250→210±10兩根管之間的喘息時間scrollSpeed2.2→3.4±0.1整體節(jié)奏3.4 時反應窗口約 1.8 秒// 調(diào)試期用方向鍵實時改參數(shù)改完按 r 重開驗證 void keyPressed() { if (key CODED keyCode UP) gravity 0.03; if (key CODED keyCode DOWN) gravity - 0.03; if (key CODED keyCode LEFT) JUMP_IMPULSE 0.3; // 注意負值加是變?nèi)?if (key CODED keyCode RIGHT) JUMP_IMPULSE - 0.3; if (key r) resetAll(); if (key p) saveFrame(frames/frame-####.png); // 逐幀存圖做軌跡比對 doJump(); // 空格也走跳躍 }這段代碼里JUMP_IMPULSE的方向最容易搞混它是負值0.3實際是讓跳躍變?nèi)?。調(diào)試面板一定要在屏幕上把當前數(shù)值打印出來text畫在左上角否則調(diào)著調(diào)著就不知道自己在哪個值上了。調(diào)完之后要驗證不能靠“我感覺變難了”。我用的辦法是固定隨機種子加腳本化點擊randomSeed(42)保證每局管道布局一致然后用一個計數(shù)器每隔固定幀數(shù)調(diào)一次doJump()看能不能穩(wěn)定通過前 10 根管道。調(diào)參前后各跑一遍通過根數(shù)的變化就是可比的基線。這套流程不玄學比反復手動試玩靠譜得多也方便把“這一版手感更好”這種主觀判斷變成“同樣的自動操作多過了三根管”的客觀記錄。從那以后我每次交這類小游戲之前都會先固定隨機種子跑一遍 30 根管道的自動點擊回放再手動玩三局兩邊的結論要是對不上八成就是判定框和繪制不同源去查gapY有沒有被別的地方改過基本一查一個準。希望幫到你。本文還有配套的精品資源點擊獲取 Processing復刻FlappyBird：物理、碰撞與狀態(tài)機工程拆解
簡介面向Processing初學者與視覺編程愛好者的類FlappyBird小游戲源碼包適合用來練習繪圖、動畫循環(huán)、碰撞檢測、鍵盤輸入與面向對象組織。項目將小鳥、管道和通用邏輯拆分為獨立模塊配合圖片與音效素材較完整地呈現(xiàn)角色運動、隨機障礙生成、得分判定與游戲狀態(tài)切換的實現(xiàn)思路讀者可在其基礎上調(diào)整參數(shù)、替換素材或擴展玩法借此理解小型交互游戲從繪制到邏輯閉環(huán)的基本結構也可作為課堂示例拆解。壓縮包共12個文件以4個pde源碼為主另有3張png圖像、3個mp3與1個wav音頻及1個properties配置文件整體約2.48MB源碼、素材與項目設置相對齊全。已有1041人學習適合Processing入門者自學練手也便于教師布置圖形交互作業(yè)時參考。1. 用 Processing 復刻 FlappyBird難的不是畫鳥用 Processing 寫一個類 FlappyBird 的橫版躲避小游戲網(wǎng)上能搜到的版本大多兩百行上下圖能跑、鳥能飛可真拿去給人玩十分鐘內(nèi)必然被問三句話我明明沒碰到管子怎么就死了重開一局分數(shù)怎么還掛著上一局的為什么在我機器上特別飄、換臺電腦又變得特別難這份源碼包正面處理的就是這三件事——重力、跳躍、管道、碰撞、狀態(tài)機各自拆成互不越界的幾塊參數(shù)集中在文件頭部改一個數(shù)字就能改手感。適合兩類人剛學完 setup/draw 想找個完整小項目練手的新手以及課程設計要做橫版躲避 Demo、需要一份能講清每行代碼為什么這么寫的骨架的從業(yè)者。下面按“先把物理立住、再讓管道可復用、最后把狀態(tài)和參數(shù)收干凈”的順序拆。2. 主循環(huán)與重力把“手感”拆成四個可調(diào)參數(shù)手感這東西聽起來玄學落到代碼里其實就是四個數(shù)字重力多大、點擊給多大沖量、最大下落速度多少、點擊有沒有冷卻。四個數(shù)字定死之前先得把數(shù)據(jù)結構和主循環(huán)擺對否則后面每加一個功能都在還債。2.1 為什么用 PVector 存速度而不是一個 float vyProcessing 的坐標系原點在左上角y 軸向下為正所以“向上跳”必須給負值——這個符號是最容易寫反的地方。我一般把方向直接編進常量名里JUMP_IMPULSE寫成 -7.6 并在旁邊注釋“負值向上”比事后查 bug 便宜得多。用PVector而不是三個 float理由有三條一是位置和速度天然成對重置時pos.set(...)、vel.set(0,0)一行解決二是以后想加橫向風、管道推速、震屏偏移直接pos.add(wind)就行不用再補一堆變量三是PVector是可變對象pos.add(vel)原地修改、不產(chǎn)生新對象在每幀都跑的 draw 里不會給 GC 添麻煩。唯一要小心的是別寫成pos pos.add(vel)這種看著像“產(chǎn)生新向量”的寫法容易讓后面接手的人誤判語義。// 坐標原點在左上角y 軸向下為正向上跳必須給負值 final float GRAVITY 0.42; // 每幀60fps 基準疊加到速度上的加速度 final float JUMP_IMPULSE -7.6; // 點擊瞬間的垂直速度負值 向上 final float MAX_FALL_SPEED 11.0; // 終端速度防止掉幀時一幀穿過管道 final float BIRD_X 120; // 鳥的橫坐標固定世界向左滾動 PVector pos; PVector vel; float gravity; // 用變量而不是直接用常量方便第 6 章在線調(diào)參 void setup() { size(480, 720); frameRate(60); gravity GRAVITY; resetBird(); } void resetBird() { pos new PVector(BIRD_X, height * 0.42); vel new PVector(0, 0); }邏輯說明pos只存位置vel只存速度重力永遠不直接改pos而是先進入vel、再由vel進入pos。這個“加速度→速度→位置”的兩級積分是所有運動的基礎骨架順序寫反先加位置再加加速度會讓鳥在低幀率下出現(xiàn)明顯的臺階感。resetBird()單獨抽出來是為第 4 章的重開邏輯留接口避免重開時到處復制兩行初始化。參數(shù)說明GRAVITY決定松手后的“沉”度0.35 以下像月球漫步0.6 以上基本救不回來JUMP_IMPULSE決定一次點擊抬多高絕對值越大越“彈”MAX_FALL_SPEED是安全閥后面碰撞那章會用到它BIRD_X固定不動因為滾動的是世界不是鳥這一點跟很多橫版卷軸的做法一致能讓碰撞判定只在一個方向上變化。提示frameRate(60)只是“請求”不是承諾。窗口被遮擋、圖片過大、后臺開了別的程序實際幀率都會掉這就是下一節(jié)要處理的問題。2.2 歸一化系數(shù)與固定步長兩種讓手感不隨幀率漂移的寫法如果直接寫vel.y GRAVITY; pos.y vel.y;在 60fps 下一切正?？梢坏嶋H幀率掉到 30同樣的重力每秒只累加 30 次鳥的下落明顯變慢玩家會覺得“這游戲今天特別簡單”。這種隨設備漂移的手感是最難復現(xiàn)的 bug因為它在你機器上永遠不出現(xiàn)。寫法 A 是系數(shù)歸一化一行搞定void draw() { float k 60.0 / max(1.0, frameRate); // 以 60fps 為基準的縮放系數(shù) k constrain(k, 0.5, 3.0); // 卡頓太久時不至于一幀跳出去 vel.y gravity * k; vel.y min(vel.y, MAX_FALL_SPEED); // 終端速度 pos.y vel.y * k; }邏輯說明k的物理含義是“這一幀相當于幾個標準幀”幀率越低 k 越大重力累加得越多。constrain那行是后悔藥——窗口被最小化再還原時frameRate可能瞬間變成一個很小的值k 會變成幾十鳥一幀就飛出屏幕夾到 3 倍以內(nèi)基本能兜住。參數(shù)說明這種寫法有個理論缺陷重力和位移同時乘 k速度項實際被放大了 k2 量級的誤差幀率波動大時軌跡會有細微差別。對 FlappyBird 這種只有豎直一維運動的場景完全夠用但如果后面要加拋物線彈道、要算落點就得換寫法 B。寫法 B 是固定步長累加器把物理推進和渲染徹底解耦final float FIXED_DT 1.0 / 60.0; // 物理固定按 1/60 秒推進 float accumulator 0; int lastMillis 0; void draw() { int now millis(); float frameTime (now - lastMillis) / 1000.0; lastMillis now; frameTime min(frameTime, 0.25); // 防止窗口掛起后一次性補幾百幀 accumulator frameTime; while (accumulator FIXED_DT) { stepPhysics(FIXED_DT); accumulator - FIXED_DT; } render(); // 渲染每幀只做一次直接用 pos 畫 } void stepPhysics(float dt) { vel.y GRAVITY * 60 * dt; // GRAVITY 按“每幀”定義這里換算成每秒 vel.y min(vel.y, MAX_FALL_SPEED); pos.y vel.y * 60 * dt; }邏輯說明不管渲染幀率是多少物理永遠以 1/60 秒為單位推進一幀內(nèi)可能要跑 0 次高刷屏也可能跑 3 次卡頓但每一步的數(shù)值完全一致所以同一串點擊時間戳在任何機器上都能復現(xiàn)出同一條軌跡。min(frameTime, 0.25)是必須的否則斷點調(diào)試回來那一幀會一次性補上幾十步物理鳥直接穿模。參數(shù)說明FIXED_DT不建議小于 1/120否則一步的位移只有零點幾像素屬于浪費也不建議大于 1/45否則快速下落時單步位移過大配合第 3 章的碰撞會漏判。方案代碼量軌跡一致性適用場景系數(shù)歸一化3 行一般低幀率下有偏差單機小 Demo、只想快速跑通固定步長20 行強同輸入必同軌跡要做回放、要做自動測試、要交付2.3 跳躍沖量、終端速度與連點冷卻跳躍有兩種寫法差別比想象中大。vel.y JUMP_IMPULSE是硬置每次點擊后鳥的上升軌跡完全一致玩家能形成肌肉記憶vel.y JUMP_IMPULSE是疊加連點會累加速度鳥能一路竄到屏幕頂端。早期我圖省事用了疊加結果玩家全程狂點就能過管道形同虛設這是最典型的一次翻車。硬置還要配一個冷卻否則鼠標事件和鍵盤事件在同一幀里都觸發(fā)時等于白按一次int lastJumpMillis -1000; final int JUMP_COOLDOWN 90; // 毫秒防止同幀多輸入事件疊加 void doJump() { if (millis() - lastJumpMillis JUMP_COOLDOWN) return; lastJumpMillis millis(); vel.y JUMP_IMPULSE; // 硬置不是 } void keyPressed() { if (key ) doJump(); } void mousePressed() { doJump(); }邏輯說明冷卻窗口取 90ms 左右比人類最快連點間隔約 100ms稍短正常操作不會覺得卡但能把同一幀的重復事件吃掉。lastJumpMillis初值給 -1000 而不是 0是為了讓游戲開始時的第一次點擊不被冷卻擋住。再補兩個視覺細節(jié)。第一是終端速度它除了防止穿模還讓鳥在長時間不下落時有個穩(wěn)定姿態(tài)不會越掉越快變成自由落體。第二是傾斜角用速度映射旋轉玩家的操作反饋立刻直觀// 把速度映射成機身角度上升時抬頭下落時低頭 float angle map(vel.y, JUMP_IMPULSE, MAX_FALL_SPEED, -0.42, 1.45); angle constrain(angle, -0.42, 1.45); // -0.42rad≈-24°1.45rad≈83°這兩個數(shù)字-24° 和 83°是試出來的抬得太高像在倒著飛低得不夠又看不出俯沖。它們不影響任何邏輯純粹是讓判定和視覺對得上的心理暗示——玩家覺得“鳥頭朝下沖進管子”比“鳥平平地貼上去”更容易接受死亡。3. 管道生成與碰撞對象池、開口公式和一個收縮系數(shù)管道是這類游戲里唯一會持續(xù)增長的東西寫法不對就會出現(xiàn)“越玩越卡”和“明明沒碰到卻死了”兩大頑疾。前者是內(nèi)存問題后者是數(shù)據(jù)不同源問題兩個都得從數(shù)據(jù)結構層面解決。3.1 用對象池代替 remove/add最直覺的寫法是每幀pipes.add(new Pipe())、出屏后pipes.remove(0)。ArrayList的remove(0)會把后面所有元素整體搬移一位add在容量不足時還要擴容復制管道保持在屏幕上 3~4 根、每 2 秒輪換一次看著不頻繁但配合每幀的遍歷和第 4 章的碰撞實測每過七八根管子就有一次可感知的頓挫。改成固定長度數(shù)組加環(huán)形復用就干凈了class Pipe { float x; // 管道左邊緣的世界坐標 float gapY; // 開口中心的縱坐標 float gapH; // 開口總高度 boolean scored; // 是否已計分見 4.2 } final int PIPE_COUNT 4; Pipe[] pipes new Pipe[PIPE_COUNT]; float pipeW 78; // 管道寬度 float gapH 180; // 開口高度 float spacing 240; // 相鄰兩根管道的水平間距 void initPipes() { for (int i 0; i PIPE_COUNT; i) { pipes[i] new Pipe(); pipes[i].x width 120 i * spacing; pipes[i].gapY random(gapH * 0.6, height - gapH * 0.6); pipes[i].gapH gapH; pipes[i].scored false; } } void updatePipes(float dx) { for (Pipe p : pipes) { p.x - dx; // 世界向左滾動 if (p.x pipeW 0) { // 完全出屏才回收 p.x PIPE_COUNT * spacing; // 接到隊尾而不是 new 一個 p.gapY random(p.gapH * 0.6, height - p.gapH * 0.6); p.scored false; } } }邏輯說明回收時用p.x PIPE_COUNT * spacing而不是p.x width這是整個對象池能穩(wěn)住的關鍵。如果重置到width一旦某幀因為卡頓導致dx變大隊尾的管道會和剛回收的管道擠在一起甚至重疊加上“一整輪的間距”之后隊列的相對位置永遠均勻間距不會因為幀率波動而漂移。參數(shù)說明PIPE_COUNT取 4 是算出來的屏幕寬度 480 除以間距 240 約等于 2再多留兩根在屏幕右側待命保證任何時刻都有管子接上。pipeW取 78 是視覺寬度碰撞時用的是另一套收縮后的判定框兩者刻意不同源但共用x和gapY——只要繪制和判定讀的是同一份gapY/gapH就不會出現(xiàn)畫一套算一套的穿模。3.2 開口高度與水平間距難度曲線的三個旋鈕真正決定難度的是三個量gapH開口高度、spacing水平間距、dx每幀滾動像素。前兩個是空間后一個是時間三者可以換算成一個玩家能感知的指標——反應時間從管道進入屏幕右緣到抵達鳥的位置可用的秒數(shù) ≈ (width - BIRD_X) / (dx * 60)按 480 寬、鳥在 120、dx 取 2.2 計算大約是 2.7 秒當 dx 漲到 3.4只剩 1.76 秒。低于 0.8 秒基本就是背板而不是反應不適合作為起始難度。這個換算看著簡單但它把“我調(diào)了速度好像變難了”變成“反應窗口從 2.7 秒壓到 1.8 秒”調(diào)參時心里有數(shù)。難度遞增用一個 0~1 的進度量做線性插值30 分封頂void updateDifficulty() { float d constrain(score / 30.0, 0, 1); // 0~130 分后不再變難 gapH lerp(190, 140, d); // 開口 190 - 140 scrollSpeed lerp(2.2, 3.4, d); // 每幀像素 spacing lerp(250, 210, d); }邏輯說明lerp的三個參數(shù)是起點、終點、進度寫起來比手算start (end - start) * d清楚。注意這里只改“下一根被回收的管道”的參數(shù)已經(jīng)在屏幕上的管道保持原樣——如果每幀都去改所有管道的gapH玩家會看到管子開口像呼吸一樣收放那才是真正的玄學。參數(shù)說明gapH的下限 140 是硬邊界再低就會出現(xiàn)“鳥的判定框加上管道寬度已經(jīng)不允許任何操作余量”的情況理論上還能過實際全靠運氣。spacing的下限 210 是為了保證兩根管子不會同時在鳥的位置附近形成夾擊。3.3 碰撞AABB 加一個 0.75 收縮系數(shù)碰撞用軸對齊包圍盒AABB就夠了不要去做像素級檢測。像素級不但慢而且會把貼圖上的描邊、陰影算進去玩家看到的是“我貼著邊過去了”判定卻認為撞上這種不公平感比直接撞死更勸退。// 鳥的判定框比貼圖小 25%這是讓玩家覺得“公平”的關鍵 final float HIT_SCALE 0.75; boolean hitPipe(Pipe p) { float halfW 24 * 0.5 * HIT_SCALE; float halfH 24 * 0.5 * HIT_SCALE; // 橫向不相交直接返回省掉后面的縱向判斷 if (pos.x halfW p.x || pos.x - halfW p.x pipeW) return false; float topBottom p.gapY - p.gapH * 0.5; // 上管的底邊 float botTop p.gapY p.gapH * 0.5; // 下管的頂邊 if (pos.y - halfH topBottom) return true; // 撞上管 if (pos.y halfH botTop) return true; // 撞下管 return false; }邏輯說明先做橫向粗篩再做縱向判斷是因為橫向不相交的概率遠高于縱向提前返回能省掉大部分計算。上管的繪制高度就是topBottom下管從botTop畫到height判定和繪制共用這兩個變量所以只要gapY和gapH不被別的邏輯偷偷改掉就永遠不會出現(xiàn)“看著沒碰到卻死了”。參數(shù)說明HIT_SCALE是本項目里最值得單獨拿出來講的一個數(shù)。取 1.0 時判定框和貼圖完全重合玩家會覺得“擦邊就死”取 0.75 相當于允許鳥的像素邊緣壓進管道 3 像素左右視覺上有驚無險操作反饋立刻變好。低于 0.6 就反過來了看著撞進去卻沒死信任感崩得比撞死還快。注意判定框收縮只縮鳥不要縮管道?？s管道會讓開口看起來比實際大玩家對距離的判斷會持續(xù)失準。4. 狀態(tài)機與計分READY / PLAYING / GAME_OVER 三態(tài)怎么切把狀態(tài)和計分單拎一章是因為這類小游戲的 bug 有七成出在這里重開不清零、一次過管加兩分、死亡后還在跑物理。用布爾量拼狀態(tài)是萬惡之源。4.1 用 enum 管狀態(tài)別用三個 boolean 拼boolean playing、boolean gameOver、boolean started三個變量一起用必然出現(xiàn)playing gameOver同時為真的中間態(tài)。我見過最典型的一次是重開時忘了清gameOver鳥在 READY 界面就開始自由落體玩家還沒反應過來已經(jīng)死了。enum加switch強制每次只走一個分支這類 bug 從結構上就不存在。enum GameState { READY, PLAYING, GAME_OVER } GameState state GameState.READY; void update() { switch (state) { case READY: // 待機時鳥做上下浮動不施加重力 pos.y height * 0.42 sin(millis() / 300.0) * 8; break; case PLAYING: stepPhysics(FIXED_DT); updatePipes(scrollSpeed); updateDifficulty(); if (hitAnyPipe() || pos.y height - 12) { state GameState.GAME_OVER; } checkScore(); break; case GAME_OVER: // 只落不飛掉到接近底部就停住 if (pos.y height - 20) { stepPhysics(FIXED_DT); } break; } }邏輯說明READY 狀態(tài)下完全不碰vel鳥的位置每幀由正弦函數(shù)直接給這樣玩家看到的是一只懸停的鳥而不是一只正在下墜的鳥。PLAYING 分支里先算物理再算管道再判碰撞順序不能反——先判碰撞再移動位置會出現(xiàn)判定用的是上一幀坐標的情況表現(xiàn)為“穿過去半根才死”。GAME_OVER 分支保留物理但不接受輸入鳥會繼續(xù)下墜一段再停住這個細節(jié)讓死亡有重量感。參數(shù)說明height - 12是落地判定的閾值取 12 是鳥貼圖半高配合height - 20的停止線讓鳥落在地上而不是陷進去。millis() / 300.0里的 300 是浮動周期改小變快、改大變得更慢。4.2 計分用 scored 標志位不要用距離閾值見過不少實現(xiàn)寫成if (abs(pos.x - p.x) 5) score;這行代碼在管道每幀移動 2~3 像素的情況下會漏判一幀跨過去了或重復判閾值太大連續(xù)兩幀都滿足。正確做法是給每根管道一個“是否已計分”的布爾位條件寫成“鳥已經(jīng)越過管道的右邊緣”天然冪等。void checkScore() { for (Pipe p : pipes) { if (!p.scored pos.x p.x pipeW) { p.scored true; // 置位保證一根管道只計一次 score; } } }邏輯說明pos.x p.x pipeW是“整只鳥含判定框都過了管道右邊緣”的意思比用中心點判斷更符合直覺。p.scored在 3.1 的回收邏輯里被重置為false所以同一根管道被復用后還能再計一次分整套流程閉環(huán)。參數(shù)說明score建議單獨維護不要復用frameCount或任何全局計數(shù)。分數(shù)一旦和幀數(shù)綁在一起重開就會出問題——frameCount是自 sketch 啟動以來的累計值永遠不會歸零。4.3 重開一局要重置的清單重開是這類游戲最容易留殘影的地方。我一般寫一個resetAll()作為唯一入口把所有會變的東西列成清單一條一條對著寫而不是散落在keyPressed里。void resetAll() { score 0; scrollSpeed 2.2; gapH 190; spacing 250; resetBird(); // pos / vel initPipes(); // 管道的 x / gapY / gapH / scored lastJumpMillis -1000; stateStartFrame frameCount; state GameState.READY; }邏輯說明清單式重置的好處是新增字段時一眼能看出“這里要補一行”。管道必須走initPipes()而不是只清scored因為上一局的管道位置會留在屏幕中間重開后鳥直接撞上去。參數(shù)說明stateStartFrame是自己記的幀號用途見下。注意frameCount是自 sketch 啟動以來的全局幀數(shù)重開不會清零。任何“每 30 幀閃一次”的動畫都要寫成frameCount - stateStartFrame直接用frameCount % 30會在重開后表現(xiàn)得不規(guī)律。5. 五條血淚踩坑從“能跑”到“能玩”之間隔著什么下面這五條是照著別人代碼改或者自己從頭寫都會撞上的前三條偏畫面與性能后兩條偏邏輯判定。每條按“現(xiàn)象→原因→解決”說能對號入座就不用重走一遍。5.1 畫面與性能類第一條越玩越卡七八根管子之后明顯頓一下?，F(xiàn)象是前面幾根很順過了十來根開始每隔一兩秒卡一幀幀率顯示從 60 掉到 45 又彈回來。原因是每幀在draw()里new Pipe()或者new PVector()管道輪換時對象不斷創(chuàng)建又丟棄垃圾回收周期被打斷表現(xiàn)為規(guī)律性的頓挫。解決是把管道改成 3.1 的固定數(shù)組復用PVector只在resetBird()里創(chuàng)建一次后續(xù)全部用set()和add()原地修改。改完再測幀率曲線會變成一條直線。第二條第一幀圖片黑塊或者鳥身后拖著一條殘影?，F(xiàn)象是啟動瞬間鳥的位置是一塊黑色矩形或者飛行時背后留下一串半透明殘像。原因有兩個一是loadImage()寫在draw()里第一幀圖片還沒解碼完就畫了二是draw()開頭漏了background()上一幀沒被覆蓋。解決是把所有l(wèi)oadImage()挪進setup()并檢查返回值是否為 null同時在draw()第一行無條件調(diào)用background()。如果確實需要拖影效果用半透明矩形疊一層別指望不清屏。第三條判定框和看到的鳥對不上明明擦過去了卻說撞上?，F(xiàn)象是視覺上鳥和管道還有一兩個像素的間隙游戲卻判定死亡或者反過來。原因通常是渲染用了P2D或做了scale()縮放而碰撞判定還在原始坐標系里算。解決是把碰撞計算統(tǒng)一放在世界坐標里做需要縮放或旋轉時用pushMatrix()/popMatrix()把變換包起來畫完就彈棧絕不讓變換泄漏到判定邏輯里。5.2 邏輯與輸入類第四條鳥從管道中間穿過去沒觸發(fā)死亡?，F(xiàn)象是偶爾一次下落特別快鳥直接出現(xiàn)在管道另一側判定完全沒反應。原因是掉幀導致單幀位移超過了判定框高度——vel.y達到 20 以上時一幀就能移動 20 像素而鳥的判定框高度只有 18 像素中間那一小段被整幀跳過了。解決分兩層先把MAX_FALL_SPEED壓到 11 以內(nèi)保證單幀位移小于判定框高度再在stepPhysics里做子步進位移大于半高就拆成多次小步每步都判一次碰撞。第五條一次過管加了兩分或者重開一局分數(shù)接著上一局算?，F(xiàn)象有兩種但根子是同一個。前者是計分條件寫成了“鳥在管道范圍內(nèi)”這個條件連續(xù)多幀為真每幀都加一次分后者是score沒進resetAll()。解決是把計分改成 4.2 的標志位寫法條件收緊到“越過右邊緣”并把score 0明確寫進重置清單。順手把scored也一起重置否則復用的管道會帶著上一局的計分狀態(tài)。還有一個容易被忽略的輸入問題想實現(xiàn)“按住鼠標連跳”的人會發(fā)現(xiàn)按住不動鳥不飛。mousePressed()函數(shù)是按下瞬間觸發(fā)一次按住不會重復調(diào)用這是符合預期的要連跳得自己判斷mousePressed這個布爾變量并在draw()里按冷卻節(jié)奏觸發(fā)doJump()。這個坑跟判定無關但很多人第一次做都會卡在這兒。6. 把參數(shù)擰成一張表調(diào)手感、驗證與一份可復現(xiàn)的自檢流程前面所有常量都是“我覺得合適”的值真正交付前必須按目標設備調(diào)一輪。我的習慣是把可調(diào)參數(shù)從final常量挪到普通成員變量用一個調(diào)試面板實時改邊玩邊調(diào)比改一次重跑一次快十倍。參數(shù)起始值調(diào)整步長觀察什么gravity0.42±0.03松手后下墜的“沉”度太快會來不及點JUMP_IMPULSE-7.6±0.3一次點擊抬升的高度太小會被管道憋死MAX_FALL_SPEED11±1掉幀時會不會穿管超過判定框半高就危險gapH190→140±10新手第一次能不能過140 是硬下限spacing250→210±10兩根管之間的喘息時間scrollSpeed2.2→3.4±0.1整體節(jié)奏3.4 時反應窗口約 1.8 秒// 調(diào)試期用方向鍵實時改參數(shù)改完按 r 重開驗證 void keyPressed() { if (key CODED keyCode UP) gravity 0.03; if (key CODED keyCode DOWN) gravity - 0.03; if (key CODED keyCode LEFT) JUMP_IMPULSE 0.3; // 注意負值加是變?nèi)?if (key CODED keyCode RIGHT) JUMP_IMPULSE - 0.3; if (key r) resetAll(); if (key p) saveFrame(frames/frame-####.png); // 逐幀存圖做軌跡比對 doJump(); // 空格也走跳躍 }這段代碼里JUMP_IMPULSE的方向最容易搞混它是負值0.3實際是讓跳躍變?nèi)?。調(diào)試面板一定要在屏幕上把當前數(shù)值打印出來text畫在左上角否則調(diào)著調(diào)著就不知道自己在哪個值上了。調(diào)完之后要驗證不能靠“我感覺變難了”。我用的辦法是固定隨機種子加腳本化點擊randomSeed(42)保證每局管道布局一致然后用一個計數(shù)器每隔固定幀數(shù)調(diào)一次doJump()看能不能穩(wěn)定通過前 10 根管道。調(diào)參前后各跑一遍通過根數(shù)的變化就是可比的基線。這套流程不玄學比反復手動試玩靠譜得多也方便把“這一版手感更好”這種主觀判斷變成“同樣的自動操作多過了三根管”的客觀記錄。從那以后我每次交這類小游戲之前都會先固定隨機種子跑一遍 30 根管道的自動點擊回放再手動玩三局兩邊的結論要是對不上八成就是判定框和繪制不同源去查gapY有沒有被別的地方改過基本一查一個準。希望幫到你。本文還有配套的精品資源點擊獲取