簡介這是一份基于C和EasyX圖形庫開發(fā)的推箱子小游戲項目文檔面向C/C初學者與游戲編程入門者主要解決從零開發(fā)2D小游戲時涉及的圖形繪制、地圖建模和按鍵交互問題。壓縮包內(nèi)共1個docx文檔大小約799KB內(nèi)容包含完整源代碼、地圖二維數(shù)組定義、碰撞檢測邏輯、音效播放設置等關鍵部分便于在課程設計或自學時直接對照閱讀。目前已有1150人學習下載。文檔以EasyX的graphics.h為核心展示了用數(shù)值區(qū)分墻體、地板、箱子、目的地與玩家的地圖設計思路并通過putimage完成游戲場景渲染同時逐步分析地圖初始化與角色移動等函數(shù)的職責劃分、玩家移動時對前后兩格狀態(tài)的判斷、推箱子的合法條件以及勝利檢測等擴展玩法讀者既可逐段理解實現(xiàn)原理也能在此基礎上改造地圖與關卡達到鞏固C語法和邏輯思維的目的。1. 基于 C 和 EasyX 的推箱子為什么說這是算法入門最該做的小項目很多人在學完 C 語法、看過幾篇 STL 教程之后會陷入一個典型的困境語法都認識但拿到一個需求不知道怎么下手。推箱子這個小游戲恰好卡在這個節(jié)點上——它不需要網(wǎng)絡、不需要數(shù)據(jù)庫、不需要復雜的工程架構但要跑通一個完整版本你必須把二維數(shù)組、鍵控邏輯、碰撞檢測、勝負判定全部串起來。而 EasyX 圖形庫把繪圖和鍵盤輸入封裝得足夠薄讓你能把注意力放在游戲邏輯本身而不是趕在 OpenGL 或 Win32 消息循環(huán)里掙扎。這大概也是為什么“基于 C 和 EasyX 寫推箱子”會成為這么多學校的大作業(yè)選題——它不是玩具是把 C 功底和基礎數(shù)據(jù)結構打成實戰(zhàn)能力的磨刀石。你的地圖本質(zhì)上是一張二維矩陣人的每一步移動都是對矩陣狀態(tài)的合法改寫而 BFS 最少步數(shù)求解器又會讓這款小游戲變成你驗證圖論算法的活體實驗臺。如果你能獨立完成這個項目并把細節(jié)踩平BFS、DFS、狀態(tài)搜索這些算法就不再是卷子上的分數(shù)線而是你親手調(diào)試過的代碼路徑。2. 推箱子到底在做什么把游戲規(guī)則拆成三個可編碼的模塊2.1 地圖建模用二維數(shù)組定義“墻、地、箱子、目標、人”推箱子的核心數(shù)據(jù)結構就是一張由字符或枚舉填充的二維矩陣。常見做法是定義一個vectorvectorchar或vectorstring用不同的字符代表五種元素#代表墻、 代表空地、$代表箱子、.代表目標點、代表玩家。這里有一個非常關鍵的設計細節(jié)——目標點在被箱子占著的時候它在地上留下的標記不能被覆蓋掉否則你無法判斷勝利條件。所以很多實現(xiàn)里會引入*表示“箱子上有目標點”表示“人站在目標點上”這種狀態(tài)提升是推箱子實現(xiàn)中第一個值得你反復體會的抽象技巧。我在自己的實現(xiàn)里用的是枚舉類型enum Cell { WALL, FLOOR, BOX, TARGET, PLAYER, BOX_ON_TARGET, PLAYER_ON_TARGET }。為什么不用字符因為字符在地圖解析時很好用但進入游戲邏輯后枚舉讓 switch 和 if 的判斷變得更安全不容易因為手滑打錯字符而翻車。地圖文件則直接用純文本每行字符串對應矩陣一行加載時逐字符映射到枚舉順便記錄玩家的初始坐標。為了調(diào)試方便我建議在內(nèi)存里維護兩張地圖——一張是原始關卡圖用于重置一張是當前游戲狀態(tài)圖用于渲染和邏輯這樣按 R 鍵重開一局就只是做一次深拷貝不需要重新讀文件。2.2 移動邏輯坐標變換與三步合法性校驗玩家的每一次移動本質(zhì)上是對“目的坐標”和“目的坐標的下一個坐標”做檢查。以向上移動為例player.x - 1是玩家的下一步坐標nextplayer.x - 2是再往前一格的坐標next2。合法性判斷分三種情況next是墻直接拒絕next是空地或目標點玩家直接走過去next是箱子或箱上目標點則必須繼續(xù)看next2只有next2是空地或目標點不是墻、不是箱子時箱子才能被推動。這段邏輯看起來簡單但我見過太多新手在這里寫出又臭又長的 if 嵌套。我的做法是把方向統(tǒng)一抽象成偏移量數(shù)組dx[4] {-1, 1, 0, 0}和dy[4] {0, 0, -1, 1}然后寫一個movePlayer(dx, dy)函數(shù)對上下左右四個方向一視同仁。這樣你就不用復制四遍幾乎相同的代碼了。判斷箱子能不能動我封裝了一個canPush(boxX, boxY, dx, dy)返回布爾值讓主邏輯保持一行if (canPush) doPush(...)的清爽結構。注意箱子推動后原位置如果本來就是目標點需要恢復成 TARGET 而不是 FLOOR這個細節(jié)漏掉的話你在后面做勝利判定時會發(fā)現(xiàn)箱子始終“少一個”。2.3 勝負判定與渲染刷新把狀態(tài)變化及時畫到屏幕上勝利條件非常明確所有箱子都落在目標點上。你不需要每幀遍歷整個地圖去數(shù)箱子數(shù)量只需要在每次箱子移動后判斷被移動的箱子是否停在了目標點上同時維護一個全局計數(shù)boxesRemaining箱子一旦到位就減一一旦被推離目標點就加一。當boxesRemaining 0時觸發(fā)勝利畫面。這種增量判定比全量掃描更高效也更符合 EasyX 這種即時刷新模型的需求。渲染部分EasyX 提供的loadimage和putimage足夠用了。我一般會提前加載好五種圖片墻、地、箱子、目標、人并在每一幀循環(huán)里用cleardevice()清屏然后按矩陣重新繪制。這里有個性能認知要糾正一下推箱子地圖通常 10x10 左右即使每幀全量重繪也絕對跑得滿 60FPS完全沒必要做局部臟矩形刷新。真正值得注意的反而是BeginBatchDraw和EndBatchDraw的配對使用——不加批量繪制的話箱子移動的時候畫面會有肉眼可見的閃爍這個問題會在后面避坑章節(jié)單獨討論。3. 搭建 C 和 EasyX 開發(fā)環(huán)境VS Code 與 Visual Studio 的取舍和配置細節(jié)3.1 EasyX 只支持 Visual Studio 系但你可以用 VS Code 寫代碼再交給 MSVC 編譯先潑一盆冷水EasyX 是一個基于 Windows GDI 的圖形庫它的頭文件和庫文件是定向提供給 Microsoft Visual C 工具鏈的官方安裝包本身就只檢測 Visual Studio 或 Visual Studio Build Tools 的環(huán)境。這意味著網(wǎng)上常見的“VS Code 配置 C/C 環(huán)境跑 EasyX”不是直接選 g 編譯器就能解決的因為 MinGW 的頭文件路徑里沒有graphics.h而 EasyX 在 2021 年之后的版本對 MinGW 的支持也非常僵硬。所以常見做法是在 VS Code 里寫代碼然后用 Visual Studio 的 MSVC 編譯器來構建或者干脆直接裝一個 Visual Studio Community 用 IDE 跑。這里我推薦一條相對平滑的路徑先單獨安裝 Visual Studio Build Tools勾選“使用 C 的桌面開發(fā)”工作負載。這樣你不需要打開龐大的 VS IDE 就能拿到 MSVC 編譯器。然后在 VS Code 里安裝 C/C 擴展配置tasks.json時把command指向cl.exe的完整路徑。但要注意MSVC 不是像 g 那樣一條命令就能用的它依賴一系列環(huán)境變量INCLUDE、LIB、PATH常見做法是打開“x64 Native Tools Command Prompt”運行code命令啟動 VS Code這樣集成終端自動繼承了 MSVC 環(huán)境再在tasks.json里調(diào)cl /std:c17 /EHsc /I EasyX目錄 xxx.cpp /link user32.lib gdi32.lib。3.2 如果你不想折騰 VS Code直接 Visual Studio EasyX 安裝包是零配置路線如果你是非要用 VS Code 不可但又不想在 tasks.json 里折騰 cl.exe 的環(huán)境變量還有一個更省事的變通方案用 VS Code 寫代碼和調(diào)試但構建和運行交給一個.bat腳本。腳本里先call C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\VsDevCmd.bat -archx64然后執(zhí)行cl編譯命令。這樣做的核心原因是 MSVC 的 cl.exe 對當前目錄和頭文件搜索路徑極度敏感直接用 VS Code 的默認終端調(diào) cl 很容易報“無法打開包括文件: graphics.h: No such file or directory”。這不是你代碼的問題是編譯環(huán)境沒被激活的經(jīng)典翻車點。EasyX 本身的安裝則非常無腦——從官網(wǎng)下載安裝包并運行它會自動識別系統(tǒng)里已有的 Visual Studio 版本并寫入頭文件和庫文件的引用路徑。安裝完后你不需要手動把graphics.h拷貝到任何地方也不需要手動配置附加依賴項因為 EasyX 安裝程序已經(jīng)幫你在 IDE 的全局屬性里掛好了鏈接配置。這里唯一要記住的是EasyX 提供的頭文件有兩種引用方式#include graphics.h是傳統(tǒng) 2D 繪圖接口#include easyx.h是新版接口。如果你看到了#include graphics.h的教程那多半是舊項目不影響使用但建議優(yōu)先用尖括號版。3.3 執(zhí)行流程與目錄組織可維護的單文件到多文件演進很多教程會讓你把全部代碼塞進一個main.cpp——這對教學可以但我要給你的建議是至少拆成三個文件再動手map.h和map.cpp負責地圖加載、關卡解析和碰撞檢測game.cpp負責玩家移動邏輯和勝負判定main.cpp只放 EasyX 窗口初始化和主循環(huán)。這樣做的好處很直接——你的推箱子游戲做到中期一定會想加“下一關”“重新開始”“步數(shù)統(tǒng)計”如果全部堆在一個文件里函數(shù)之間互相耦合改一個功能要牽連全局。拆文件之后map.cpp只暴露loadLevel(int id)、isValidMove(int x, int y)這類接口game.cpp只關心邏輯狀態(tài)。文件拆分的另一個好處是支持增量編譯。地圖文件我建議單獨建一個levels.txt用分隔不同關卡加載時用ifstream讀取并按分隔符切分。地圖的坐標系在文件里是從第 0 行開始的但在屏幕上渲染時我會統(tǒng)一加一個TILE_SIZE常量EasyX 下推薦 64 像素做偏移這樣地圖數(shù)據(jù)和渲染坐標互相獨立后面你要調(diào)整窗口大小或者縮放地圖就只需要改一個常量。4. 核心代碼實現(xiàn)地圖加載、移動控制和 BFS 自動求解器4.1 地圖加載模塊從文本文件到內(nèi)存矩陣下面是我常用的一組加載代碼它把levels.txt中按分隔的關卡切分出來并把字符映射到枚舉矩陣。// map.cpp #include map.h #include fstream #include sstream bool GameMap::loadFromFile(const std::string path, int levelId) { std::ifstream file(path); if (!file.is_open()) return false; std::string content((std::istreambuf_iteratorchar(file)), std::istreambuf_iteratorchar()); std::stringstream ss(content); std::string segment; int currentId 0; while (std::getline(ss, segment, )) { // 去掉可能出現(xiàn)的換行符殘留 if (segment.size() 3) continue; if (currentId levelId) { parseSegment(segment); return true; } currentId; } return false; } void GameMap::parseSegment(const std::string segment) { std::stringstream lineStream(segment); std::string line; grid.clear(); playerPos {0, 0}; while (std::getline(lineStream, line)) { if (line.empty() || line[0] \r) continue; std::vectorCell row; for (char ch : line) { switch (ch) { case #: row.push_back(WALL); break; case : row.push_back(FLOOR); break; case $: row.push_back(BOX); break; case .: row.push_back(TARGET); break; case : row.push_back(PLAYER); playerPos {static_castint(row.size() - 1), static_castint(grid.size())}; break; case *: row.push_back(BOX_ON_TARGET); break; case : row.push_back(PLAYER_ON_TARGET); playerPos {static_castint(row.size() - 1), static_castint(grid.size())}; break; default: row.push_back(WALL); } } if (!row.empty()) grid.push_back(row); } initState grid; }核心邏輯說明loadFromFile用getline(ss, segment, )按字符切分所以你在關卡的結束標記處寫會被拆成三截而我用segment.size() 3跳過空段。parseSegment中讀取行時每一行末尾的\r在 Windows 文本模式下會被自動去除但如果是 Git 換行符設置導致文件里混入了\r那一行字符串會明顯異常所以代碼里主動對\r做了判斷。initState這個成員用于重開關卡時恢復初始矩陣比重新讀文件快了不止一個量級。參數(shù)調(diào)整建議grid的類型是std::vectorstd::vectorCell如果你的關卡很大比如 20x20每次深拷貝initState會有一些開銷但推箱子的典型關卡在 10x10 到 15x15 之間完全不用擔心。如果你要支持多個關卡來回切換你需要維護一個std::vectorGridState的數(shù)組而不是單個initState。4.2 玩家移動與箱子推動增量狀態(tài)切換// game.cpp bool GameLogic::tryMove(int dx, int dy) { int px map.playerPos.x dx; int py map.playerPos.y dy; Cell nextCell map.grid[py][px]; if (nextCell WALL) return false; // 如果前方是箱子再檢查箱子前方 if (nextCell BOX || nextCell BOX_ON_TARGET) { int bx px dx; int by py dy; Cell beyondCell map.grid[by][bx]; if (beyondCell WALL || beyondCell BOX || beyondCell BOX_ON_TARGET) { return false; } // 移動箱子先恢復箱子的原位置 map.grid[py][px] (nextCell BOX_ON_TARGET) ? TARGET : FLOOR; // 箱子新位置如果是目標點標記為 BOX_ON_TARGET map.grid[by][bx] (beyondCell TARGET) ? BOX_ON_TARGET : BOX; // 更新勝利計數(shù) if (nextCell BOX_ON_TARGET) boxesPlaced--; if (beyondCell TARGET) boxesPlaced; } // 移動玩家原位置如果是目標點恢復 TARGET Cell currentPlayerCell map.grid[map.playerPos.y][map.playerPos.x]; map.grid[map.playerPos.y][map.playerPos.x] (currentPlayerCell PLAYER_ON_TARGET) ? TARGET : FLOOR; // 玩家新位置如果踩到目標點標記 PLAYER_ON_TARGET map.grid[py][px] (nextCell TARGET) ? PLAYER_ON_TARGET : PLAYER; map.playerPos {px, py}; steps; return true; }這段代碼的關鍵在“先恢復后設置”的順序。移動箱子時你必須在覆蓋(py, px)之前把這個位置原本的BOX_ON_TARGET還原成TARGET否則箱子雖然走了但那個目標點被永遠錯誤地標記成了地板最后勝利判定會少一個目標點。其次boxesPlaced的增減邏輯是“先減后加”如果箱子原本就在目標點上先把它移出目標點計數(shù)減一再判斷新位置是否是目標點是則加一。還有一個我現(xiàn)在覺得非常值得強調(diào)的細節(jié)這里判斷箱子前方用的是“不能是墻、不能是箱子”但不要忘了BOX_ON_TARGET本質(zhì)上也還是箱子你如果把 “箱子已在目標點” 當成普通目標點去踩箱子會被穿透。這大概是推箱子新手最容易遇到的“箱子穿墻”類玄學 bug根源就在于沒有把BOX_ON_TARGET當箱子處理。4.3 BFS 自動求解器驗證你的推箱子關卡是否真的有解當你做完基本游戲后一個常見的需求是驗證自制關卡有沒有解。這里我直接上 BFS 狀態(tài)搜索——把“玩家位置 所有箱子位置”作為狀態(tài)節(jié)點搜索方向就是四個移動。注意 BFS 的具體實現(xiàn)是快速驗證可行性的捷徑但不是最優(yōu)解因為它默認每個節(jié)點的權重相同只能保證找“最少步數(shù)”而不是“最短路徑損耗”。// solver.cpp #include queue #include set #include tuple struct State { int playerX, playerY; std::vectorstd::pairint,int boxPositions; int steps; }; bool operator(const State a, const State b) { if (a.playerX ! b.playerX) return a.playerX b.playerX; if (a.playerY ! b.playerY) return a.playerY b.playerY; return a.boxPositions b.boxPositions; } int bfsShortest(GameMap map) { std::queueState q; std::setState visited; State start {map.playerPos.x, map.playerPos.y, /*收集箱子坐標*/ {}, 0}; q.push(start); visited.insert(start); int dx[4] {-1, 1, 0, 0}; int dy[4] {0, 0, -1, 1}; while (!q.empty()) { State cur q.front(); q.pop(); // 勝利判定每個箱子都在目標點 if (allBoxesOnTarget(cur.boxPositions, map)) return cur.steps; for (int i 0; i 4; i) { int nx cur.playerX dx[i]; int ny cur.playerY dy[i]; // 復用 GameLogic 的碰撞判定如果合法就生成新狀態(tài) // 新狀態(tài)要注意如果人推了箱子boxPositions 中對應箱子的坐標要更新 } } return -1; // 無解 }參數(shù)說明這里State的operator重載是給std::set用的因為std::set默認用比較器。boxPositions必須排序后才比較否則同一組箱子坐標在不同順序下會被誤認為不同狀態(tài)BFS 就無法去重。實際項目里我一般會把箱子坐標壓成一個 64 位整數(shù)編碼(x 16) | y然后按整體比較性能更好但可讀性差教學代碼里保持operator更容易理解。搜索空間的上限是玩家位置不超過地圖格子數(shù)每個箱子位置不超過地圖格子數(shù)理論上最壞情況是爆炸性組合。但對于標準推箱子關卡BFS 能在幾秒內(nèi)出結果。如果你發(fā)現(xiàn)求解器一直跑不出來多半是狀態(tài)去重不完整BOX 和 BOX_ON_TARGET 沒有歸一化或者 BFS 遍歷了循環(huán)移動路徑。5. 推箱子落地的 6 個常見坑數(shù)組越界、非法移動和渲染順序5.1 越界崩潰地圖邊緣的訪問越界不報錯但行為詭異現(xiàn)象玩家把箱子推到地圖最邊緣程序偶爾閃退或者畫面出現(xiàn)雪花狀噪點而不是穩(wěn)定崩潰。原因tryMove里檢查nextCell時直接索引了grid[py][px]如果py或px超出了grid的行數(shù)或列數(shù)這是未定義行為。在 Debug 模式下可能會觸發(fā)斷言彈窗在 Release 模式下可能讀到相鄰內(nèi)存數(shù)據(jù)導致箱子“飛到”墻里或者消失。解決在所有索引前加上邊界守衛(wèi)。我習慣寫一個宏或內(nèi)聯(lián)函數(shù)bool isInside(int x, int y) { return y 0 y grid.size() x 0 x grid[0].size(); }。然后在tryMove最前面判斷不在邊界內(nèi)直接return false。不要覺得這是多余——推箱子玩家最喜歡做的事就是故意把箱子往墻角懟你的代碼必須對這種操作零容忍。5.2 箱子推穿墻把“箱子在目標點上”當成普通地板現(xiàn)象箱子明明已經(jīng)在目標點上*人走到箱子旁邊推它箱子“穿過”墻繼續(xù)移動。原因在判斷箱子前方beyondCell時只寫了if (beyondCell WALL || beyondCell BOX) return false;漏掉了BOX_ON_TARGET。由于BOX_ON_TARGET在地圖邏輯上是“目標點 箱子”的復合體你不能拿它當作普通地板。解決把BOX_ON_TARGET加入不可通過列表。這類問題最典型的特征是“只在目標點上的箱子能穿墻”如果你在用 EasyX 調(diào)試時發(fā)現(xiàn)這種玄學你要立刻意識到是復合狀態(tài)沒處理干凈。更穩(wěn)健的做法是給Cell加一個輔助函數(shù)bool isBox(Cell c) { return c BOX || c BOX_ON_TARGET; }讓所有箱子判定統(tǒng)一走這個函數(shù)避免到處手寫兩個條件。5.3 畫面閃爍每一幀單次繪制造成的撕裂感現(xiàn)象箱子每移動一格畫面就像眨了一下眼尤其連續(xù)快速移動時閃爍嚴重。原因EasyX 默認是單緩沖繪制每次putimage直接寫顯存畫面刷新過程中就會閃。窗口越大地圖圖塊越多閃爍越明顯。解決在窗口初始化后調(diào)用BeginBatchDraw()每幀所有繪制結束后調(diào)用EndBatchDraw()或者FlushBatchDraw()。BeginBatchDraw讓所有繪圖操作先寫到內(nèi)存中的緩沖畫布上最后一次交付給顯存整個過程對用戶不可見。我自己的經(jīng)驗是批繪制對 EasyX 性能提升是肉眼級的——箱子移動從“眨眼”變成“順滑”代碼只加兩行沒有副作用。5.4 屏幕坐標和地圖坐標混淆用錯坐標系導致人物飛到天花板現(xiàn)象鼠標點擊或鍵盤移動后玩家移動的位置和按鍵方向完全對不上上變成了斜移。原因grid的行索引是y列索引是x但在 EasyX 繪制時putimage(x * TILE_SIZE, y * TILE_SIZE, ...)的x是列、y是行。如果你在移動邏輯里把行當成了x列當成了y畫出來的人物軌跡就是轉置的。解決在代碼注釋里強制標注grid[y][x]先 y 后 x保持一致。函數(shù)參數(shù)命名也要統(tǒng)一比如movePlayer(int dx, int dy)不要用movePlayer(int x, int y)卻傳入了行列。這種 bug 一般在第一次顯示人物動起來之后 5 分鐘內(nèi)就會發(fā)現(xiàn)但排查成本不低——你會在邏輯里反復打日志找半天最后發(fā)現(xiàn)只是變量名誤導了自己。最好的預防是繪制函數(shù)和邏輯函數(shù)共用同一個坐標解釋約定。5.5 重開一局恢復不干凈重置后箱子和人疊在同一格現(xiàn)象按 R 鍵重開當前關卡結果畫面上出現(xiàn)一個人踩在箱子上或者地圖上多了一個箱子少了一個人。原因重置時直接執(zhí)行grid initState但玩家位置playerPos沒有同步重置。如果在initState被賦值之后你又修改了成員變量的初始化順序或者parseSegment里對玩家坐標賦值發(fā)生在initState拷貝之前就會導致玩家的初始位置記錄錯誤。解決重置函數(shù)里不僅要恢復grid還要強制恢復playerPos startPlayerPos而且要單獨記錄startPlayerPos而不是從initState里重新解析。我見過的更隱蔽變體是initState是在parseSegment末尾賦值的但parseSegment里playerPos是最后才賦值的于是initState里的玩家坐標還是(0,0)。解決方法是把startPlayerPos放在加載流程的最前面初始化或者直接在parseSegment的分支里同步更新startPlayerPos。5.6 關卡文件解析時漏掉空白行導致地圖變形現(xiàn)象不同的人用不同編輯器編輯levels.txt結果有的人關卡加載出來地圖錯位墻行數(shù)比預期少一行。原因Windows 的文本文件換行是\r\n而某些代碼編輯器尤其 Linux 風格配置的 VS Code會以\n結尾讀入后每行末尾帶著一個\r。std::getline默認只去掉\n保留\r導致你比較行首字符時沒問題但做字符串長度判斷時出錯。如果關卡的某一行末尾恰好是空格這個空格會被替換成意想不到的位置。解決讀取每一行時用if (!line.empty() line.back() \r) line.pop_back();統(tǒng)一清理。更進一步我建議你建立關卡文件的統(tǒng)一約定所有行必須等寬也就是每一行字符串的size()必須一致加載時做一次校驗不一致直接報錯。這比在游戲里出現(xiàn)奇怪碰撞再排查要節(jié)省大量時間。6. 從“能玩”到“好用”步數(shù)統(tǒng)計、操作回退和關卡校驗的三個進階技巧6.1 操作歷史棧實現(xiàn)撤銷操作的正確姿勢最簡單可靠的撤銷方案是維護一個std::vectorGridState歷史棧每次移動前把當前grid和playerPos壓入棧撤銷時從棧頂彈出一個GridState并恢復整個狀態(tài)。棧的深度最多 100 左右就足夠因為推箱子的核心樂趣在于規(guī)劃步數(shù)而不是無限悔棋限制棧深還能避免內(nèi)存占用失控。關鍵點是撤銷操作不要走tryMove的反向邏輯實驗因為反向邏輯不僅要處理玩家的移動還得正確處理箱子從目標點被推走后的狀態(tài)恢復稍有遺漏就會產(chǎn)生“箱子數(shù)量守恒被破壞”的修補麻煩。直接恢復快照是最省心的代價只是一次深拷貝而推箱子地圖撐死幾百個格子深拷貝開銷在微秒級別完全可以忽略。如果你對內(nèi)存潔癖特別嚴重可以只在箱子被推動時才壓棧玩家單純走路的步驟不壓?！@樣歷史記錄更精簡撤銷也更像“回到上一步?jīng)Q策點”。6.2 加裝 BFS 求解器做關卡合法性驗證讓自制關卡不交白卷在做關卡編輯器時用第 4.3 節(jié)的 BFS 求解器對每一關做預檢判斷是否有解。這個操作極其重要因為你想出一個看似精妙的陷阱地圖結果玩家把所有箱子推到死局之后發(fā)現(xiàn)死活無解那你這個關卡設計就是失敗的。BFS 的返回值如果小于 0直接把關卡標記成“無解”并拒絕加載。另一個價值點是BFS 返回的最少步數(shù)可以作為玩家成績的參考基線。比如你在界面上顯示“作者最少 38 步過關”那玩家會不斷嘗試刷新這個數(shù)字。不過要提醒的是BFS 的最少步數(shù)是把“每一步移動”算一次如果你的游戲邏輯把“推箱子的一步”也算一步那玩家的實際步數(shù)會和 BFS 的參考值有偏差因為玩家推著箱子走兩步時BFS 里會記錄成兩次移動但你的步數(shù)統(tǒng)計可能只算了一步。為了避免這種偏差請在游戲內(nèi)統(tǒng)一一次物理移動算一步不管有沒有推箱子這樣才和 BFS 結果可比。6.3 死亡局判定用狀態(tài)壓縮檢測“所有箱子都無法再移動”推箱子真正勸退玩家的瞬間是玩到中盤發(fā)現(xiàn)所有箱子都被推到墻邊死角還要手動重開。你可以在玩家每走一步后調(diào)用一個簡單檢測對每個箱子檢查它的四個鄰居、以及它鄰居的鄰居如果所有方向都無法再推動前方是墻/箱子/邊界并且該箱子不在目標點上那這一局已經(jīng)徹底無解直接彈提示“死局是否重開”。這個啟發(fā)式判定不是完備的有一些非死鎖但無法完成的局面它不能識別但已經(jīng)足夠攔截掉絕大多數(shù)“物理死局”。要做得更完備就得完整跑一遍 BFS 狀態(tài)搜索重量級但可以在后臺線程做不影響玩家操作。我個人的建議是死局判定做成對話框確認不要強制重開因為有的高手就喜歡在看似無解的局面里尋找翻身路徑你一刀切反而打擊探索熱情。這個細節(jié)雖然短但非常影響游戲口碑——玩家對一個推箱子版本的評價很大程度上取決于它在“卡住”時的友好度。最后一個我自己的習慣推箱子不是寫完移動邏輯就算完的產(chǎn)品級代碼。如果你要把它放進作品集請一定記得封裝游戲狀態(tài)接口把邏輯和渲染分離——這樣后續(xù)換 Qt、換成 SFML 做跨平臺版核心的移動、BFS、存檔系統(tǒng)不用重寫。我當時做完 C/EasyX 版本后把邏輯部分抽出來換成 Qt 界面只花了一個下午而同一批同學把邏輯和繪制揉在一個main.cpp里的重寫時等于從零開始。這個教訓希望幫到你。本文還有配套的精品資源點擊獲取