實戰(zhàn)：雙緩沖繪制與DFS生成算法解析)
簡介這是一套使用MFC編寫的簡單迷宮游戲完整工程面向初學(xué)Windows程序設(shè)計或C圖形界面的開發(fā)者演示如何基于MFC框架搭建可交互的迷宮小游戲。資源共45個文件壓縮包約2.13MB其中包含7個頭文件與6個C源文件實現(xiàn)文檔/視圖架構(gòu)、迷宮邏輯與玩家控制、資源腳本與位圖/圖標(biāo)文件以及可直接運行的exe程序和步驟PNG截圖便于對照源碼理解界面構(gòu)建、消息映射與繪圖過程。游戲涉及二維數(shù)組存儲迷宮、深度優(yōu)先或廣度優(yōu)先路徑搜索等經(jīng)典算法通過鍵盤或鼠標(biāo)操作完成尋路適合用來學(xué)習(xí)面向?qū)ο蠓庋b和Windows事件驅(qū)動機制。已有378人瀏覽學(xué)習(xí)。借助這份資料可快速上手MFC工程結(jié)構(gòu)并根據(jù)提示修改迷宮地圖、自定義關(guān)卡是一個能反復(fù)研讀的練手范例。1. MFC迷宮游戲從拖控件到自繪的第一道坎很多人學(xué) MFC 是從對話框拖按鈕開始的拖一個 Button、拖一個 Edit 控件雙擊生成消息處理函數(shù)以為這就是 Windows 桌面開發(fā)的全部。但用 MFC 做一個簡單的迷宮游戲會把你的認(rèn)知拉回正確的軌道上迷宮游戲沒有現(xiàn)成控件可用你得自己定義數(shù)據(jù)結(jié)構(gòu)存迷宮、自己寫繪制代碼把格子畫出來、自己處理鍵盤消息讓玩家動起來。這一趟走完你對 CWnd、CDC、消息映射這三個 MFC 核心機制的理解會扎實很多。這個項目非常適合作為學(xué)完對話框之后的第二個練手程序也是面試時能拿得出手的“真寫過代碼”的證明。本文按我實際做這個迷宮的思路來拆解從數(shù)據(jù)結(jié)構(gòu)選型講到繪制和避坑全程可復(fù)現(xiàn)。2. 迷宮怎么生成才像迷宮數(shù)據(jù)結(jié)構(gòu)與 DFS 遞歸回溯選型2.1 迷宮格子怎么存位運算而不是二維 bool迷宮游戲的第一件事不是畫圖是決定迷宮在內(nèi)存里長什么樣。最常見的做法是給每個格子存“四面墻是否存在”。初學(xué)者容易寫成兩個二維數(shù)組bool wallUp[ROWS][COLS]、bool wallRight[ROWS][COLS]四個方向四個數(shù)組訪問起來啰嗦擴展一個斜向墻就改結(jié)構(gòu)。我一般用一個結(jié)構(gòu)體加上位標(biāo)記// 每個格子的墻用 BYTE 的四個位表示1 表示該方向有墻 struct Cell { BYTE walls; // bit0上墻, bit1右墻, bit2下墻, bit3左墻 }; #define W_UP 0x01 #define W_RIGHT 0x02 #define W_DOWN 0x04 #define W_LEFT 0x08 Cell maze[ROWS][COLS];這里ROWS和COLS我用宏或者const int定死比如 16 行 12 列。不用vectorvectorCell是因為固定尺寸迷宮用 C 數(shù)組更直觀訪問連續(xù)內(nèi)存也更快等你后面加縮放、加存檔再換容器不遲。初始化時把每個Cell.walls置為W_UP | W_RIGHT | W_DOWN | W_LEFT表示所有墻都在后面生成過程就是不斷拆墻。用位運算而不是四個 bool 的好處在移動檢測時看得最清楚判斷“玩家想往上走是否被擋住”只需要if (maze[r][c].walls W_UP)一行。四個方向的判斷都是同一套邏輯不會出現(xiàn)wallUp[r][c] wallRight[r][c]這種越寫越亂的局面。位運算在 MFC 里也常見讀慣了GetStyle() WS_CHILD這種寫法的人對這種風(fēng)格不會陌生。2.2 DFS 遞歸回溯 vs 隨機 Prim生成選型和對比迷宮生成算法有兩大類一類是深度優(yōu)先遞歸回溯一類是隨機 Prim。兩種都能生成“完美迷宮”也就是任意兩點之間有且僅有一條路徑的迷宮。我在做這個簡單迷宮時選了 DFS 遞歸回溯因為它代碼量最小、邏輯最好講生成出來的迷宮主路長、岔路深玩起來更有“闖關(guān)感”。兩種算法對比在實際效果上的差異很明顯對比項DFS 遞歸回溯隨機 Prim生成思路沿一條路走到黑撞墻后回退每次從墻集合里隨機挑一面墻拆分支形態(tài)分支少、主路長、胡同長而深分支均勻、迷宮區(qū)域更“碎”實現(xiàn)代碼量約 30 行無額外容器需要維護墻候選集合約 50 行生成速度O(ROWS*COLS)很快同樣 O(ROWS*COLS)但常數(shù)更大玩家體驗一條主路走到底方向感強道路交織更容易迷路如果你只想讓迷宮生成得“看起來均勻”Prim 更好但游戲性上DFS 生成的大迷宮更有挑戰(zhàn)性因為它的路徑轉(zhuǎn)折多、死胡同深玩家經(jīng)常走進一個長胡同發(fā)現(xiàn)到頭了轉(zhuǎn)身出來時已經(jīng)分不清方向。這正是迷宮游戲需要的體驗。而且 DFS 遞歸回溯是理解圖遍歷的經(jīng)典入門題寫完這個算法你去看其他遞歸回溯的代碼會輕松很多。另一個選 DFS 的原因是 MFC 程序里遞歸調(diào)用棧本身就夠用。16x12 的迷宮遞歸深度最多兩百多層完全不用擔(dān)心棧溢出。如果你把迷宮擴到 100x100我建議改用顯式棧的迭代版 DFS或者在項目屬性里加大?？臻g但那個量級已經(jīng)不是“簡單迷宮”的范疇了。2.3 用 DFS 生成一張 16x12 迷宮代碼與參數(shù)說明生成函數(shù)的核心邏輯是從起點格開始隨機挑選一個未訪問過的相鄰格拆掉兩格之間的墻遞歸進入該格。四個方向的處理我用一個dirs數(shù)組做隨機洗牌而不是寫四段 if這樣代碼能復(fù)用同一套拆墻邏輯。void CMazeGameDlg::GenerateMaze(int r, int c) { visited[r][c] true; // visited 是 BOOL 二維數(shù)組全局或成員變量 // 四個方向用數(shù)組表示{上, 右, 下, 左} 對應(yīng)的行列變化 int dr[4] { -1, 0, 1, 0 }; int dc[4] { 0, 1, 0, -1 }; // 隨機打亂方向順序保證每次生成的迷宮不一樣 int dirs[4] { 0, 1, 2, 3 }; for (int i 3; i 0; i--) { int j rand() % (i 1); std::swap(dirs[i], dirs[j]); } for (int k 0; k 4; k) { int nr r dr[dirs[k]]; int nc c dc[dirs[k]]; if (nr 0 || nr ROWS || nc 0 || nc COLS) continue; // 越界 if (visited[nr][nc]) continue; // 已經(jīng)訪問過跳過 // 拆掉當(dāng)前格與目標(biāo)格之間的墻 if (dirs[k] 0) { // 目標(biāo)在上方 maze[r][c].walls ~W_UP; maze[nr][nc].walls ~W_DOWN; } else if (dirs[k] 1) { // 目標(biāo)在右方 maze[r][c].walls ~W_RIGHT; maze[nr][nc].walls ~W_LEFT; } else if (dirs[k] 2) { // 目標(biāo)在下方 maze[r][c].walls ~W_DOWN; maze[nr][nc].walls ~W_UP; } else { // 目標(biāo)在左方 maze[r][c].walls ~W_LEFT; maze[nr][nc].walls ~W_RIGHT; } GenerateMaze(nr, nc); // 遞歸進入下一個格子 } }調(diào)用時從(0, 0)開始GenerateMaze(0, 0)算法跑完整張迷宮里所有格子都連成了一條通路而且保證沒有環(huán)路。關(guān)鍵參數(shù)就兩個一個是迷宮尺寸ROWS/COLS我取 16x12 是為了配合每個格子 20 像素的繪制尺寸最終窗口客戶區(qū)大約 320x240不需要滾動條另一個是隨機數(shù)種子建議在OnInitDialog里調(diào)用srand((unsigned)time(NULL))否則每次運行生成的是同一張迷宮玩一遍就膩了。這里的“先拆墻、再遞歸”和“先標(biāo)記 visited、再進入”有一個順序上的講究必須在遞歸調(diào)用之前就把兩格之間的墻拆掉。原因很簡單遞歸進入鄰格之后可能馬上又從鄰格往回走到當(dāng)前格如果墻沒拆就會形成一堵格格不入的斷墻迷宮看起來有一條路、實際走不通。3. 畫格子與走格子雙緩沖繪制和鍵盤移動的完整實現(xiàn)3.1 為什么要雙緩沖閃爍的根源和 OnEraseBkgnd迷宮生成完接下來的問題是把它畫到窗口上。直接在OnPaint里拿CPaintDC畫墻、畫地板窗口一刷新就會狂閃。原因每個 MFC 初學(xué)者都遇過窗口在重繪時先擦背景再畫前景擦是白屏畫是迷宮兩個動作交替人眼看到的是一亮一暗的“頻閃”。窗口越大、繪制邏輯越重閃爍越明顯。解決思路是雙緩沖先在一張內(nèi)存位圖上把迷宮完整畫好再一次BitBlt把整張圖拷貝到窗口上。這樣用戶看不到“畫了一半”的中間狀態(tài)只看到最終結(jié)果。雙緩沖是 Windows 繪圖里最基礎(chǔ)也最有效的性能手段在迷宮、游戲、自定義控件里都是必用方案。配合雙緩沖還要做一件事把背景擦除干掉。MFC 的默認(rèn)窗口類會在WM_ERASEBKGND消息里用背景色刷一遍窗口這就是閃爍的另一個源頭。標(biāo)準(zhǔn)做法是重寫OnEraseBkgnd直接返回 TRUE 告訴系統(tǒng)“背景你已經(jīng)處理完了別擦”。BOOL CMazeGameDlg::OnEraseBkgnd(CDC* pDC) { // 返回 TRUE 阻止系統(tǒng)默認(rèn)擦背景避免閃屏 return TRUE; }注意這個函數(shù)在類向?qū)Ю锟床坏叫枰謩釉谙⒂成淅锛覱N_WM_ERASEBKGND()。加上之后背景擦除被禁用所有刷新都在內(nèi)存 DC 中完成再BitBlt上屏。3.2 OnPaint 里畫墻、玩家與終點核心繪制代碼繪制代碼放在OnPaint里用CPaintDC獲取窗口 DC再創(chuàng)建兼容 DC 和位圖作為緩沖。這里有一個細(xì)節(jié)CreateCompatibleBitmap的尺寸要和客戶區(qū)一致如果你讓窗口可以縮放則每次重繪要重新創(chuàng)建位圖比較麻煩。做簡單迷宮我建議禁掉窗口縮放固定尺寸代碼干凈很多。void CMazeGameDlg::OnPaint() { CPaintDC dc(this); // 窗口 DC CRect rc; GetClientRect(rc); // 創(chuàng)建內(nèi)存 DC 和位圖做雙緩沖 CDC memDC; memDC.CreateCompatibleDC(dc); CBitmap bmp; bmp.CreateCompatibleBitmap(dc, rc.Width(), rc.Height()); CBitmap* pOldBmp memDC.SelectObject(bmp); // 背景色 memDC.FillSolidRect(rc, RGB(240, 240, 240)); // 畫迷宮先地板后墻保證邊界線干凈 for (int r 0; r ROWS; r) { for (int c 0; c COLS; c) { int x c * CELL_SIZE; int y r * CELL_SIZE; // 地板 memDC.FillSolidRect(x, y, CELL_SIZE, CELL_SIZE, RGB(255, 255, 255)); // 四個方向的墻畫 2 像素寬右/下方向多畫 1 像素防止漏縫 if (maze[r][c].walls W_UP) memDC.FillSolidRect(x, y, CELL_SIZE 1, 2, RGB(60, 60, 60)); if (maze[r][c].walls W_RIGHT) memDC.FillSolidRect(x CELL_SIZE - 1, y, 2, CELL_SIZE 1, RGB(60, 60, 60)); if (maze[r][c].walls W_DOWN) memDC.FillSolidRect(x, y CELL_SIZE - 1, CELL_SIZE 1, 2, RGB(60, 60, 60)); if (maze[r][c].walls W_LEFT) memDC.FillSolidRect(x, y, 2, CELL_SIZE 1, RGB(60, 60, 60)); } } // 畫終點右下角格子里畫一個綠色方塊 CBrush greenBrush(RGB(0, 180, 0)); CBrush* pOldBrush memDC.SelectObject(greenBrush); int ex (COLS - 1) * CELL_SIZE CELL_SIZE / 4; int ey (ROWS - 1) * CELL_SIZE CELL_SIZE / 4; memDC.Rectangle(ex, ey, ex CELL_SIZE / 2, ey CELL_SIZE / 2); memDC.SelectObject(pOldBrush); // 還原畫刷 // 畫玩家當(dāng)前格子中心的藍色圓 CBrush blueBrush(RGB(0, 120, 255)); pOldBrush memDC.SelectObject(blueBrush); int px playerCol * CELL_SIZE CELL_SIZE / 4; int py playerRow * CELL_SIZE CELL_SIZE / 4; memDC.Ellipse(px, py, px CELL_SIZE / 2, py CELL_SIZE / 2); memDC.SelectObject(pOldBrush); // 一次拷貝到窗口 dc.BitBlt(0, 0, rc.Width(), rc.Height(), memDC, 0, 0, SRCCOPY); // 清理先把舊位圖選回來再刪對象 memDC.SelectObject(pOldBmp); bmp.DeleteObject(); }參數(shù)說明CELL_SIZE設(shè) 20迷宮格子 20x20 像素墻厚 2 像素。兩點值得注意。第一右邊和下邊的墻畫得比格子邊界多 1 像素是因為相鄰兩個格子各自畫墻時如果不做重疊處理格子之間會出現(xiàn)一條白色細(xì)縫視覺上就是墻“斷”了。這是血淚經(jīng)驗我最早畫出來滿屏白線排查半天發(fā)現(xiàn)是邊界差 1 像素。第二先畫地板再畫墻順序不能反。如果先畫墻地板會把墻蓋掉一半出現(xiàn)鋸齒邊。繪制順序是窗口自繪的通用紀(jì)律尤其在做地圖、棋盤這類網(wǎng)格圖形時。另外畫完玩家后有一行SelectObject還原舊畫刷這步很多人忽略。在內(nèi)存 DC 里不還原問題不大但如果連續(xù)繪制多次或者后續(xù)使用同一個 DC舊對象不還原會導(dǎo)致 GDI 對象泄漏。MFC 的CDC析構(gòu)時雖然會清理但養(yǎng)成“Select 了就要 Select 回來”的習(xí)慣能少踩很多坑。3.3 PreTranslateMessage 里的鍵盤移動與碰撞檢測玩家移動需要響應(yīng)鍵盤方向鍵。MFC 對話框程序有幾種做法重寫OnKeyDown、在PreTranslateMessage里攔截虛鍵消息。我推薦用PreTranslateMessage一個核心原因是對話框里如果有按鈕或其他控件焦點不在對話框本身時WM_KEYDOWN不一定會走到對話框的OnKeyDown表現(xiàn)為“點了一下按鈕之后方向鍵失靈了”。而PreTranslateMessage在消息被分發(fā)到任何窗口之前先過一道手方向鍵在這里攔截最穩(wěn)。BOOL CMazeGameDlg::PreTranslateMessage(MSG* pMsg) { if (pMsg-message WM_KEYDOWN) { UINT key (UINT)pMsg-wParam; int nr playerRow; int nc playerCol; if (key VK_UP) nr--; else if (key VK_DOWN) nr; else if (key VK_LEFT) nc--; else if (key VK_RIGHT) nc; else return CDialogEx::PreTranslateMessage(pMsg); // 其他鍵走默認(rèn) // 先判斷目標(biāo)位置是否在迷宮范圍內(nèi) if (nr 0 nr ROWS nc 0 nc COLS) { // 判斷當(dāng)前格與目標(biāo)格之間的墻是否擋住移動 bool blocked false; if (key VK_UP (maze[playerRow][playerCol].walls W_UP)) blocked true; if (key VK_DOWN (maze[playerRow][playerCol].walls W_DOWN)) blocked true; if (key VK_LEFT (maze[playerRow][playerCol].walls W_LEFT)) blocked true; if (key VK_RIGHT (maze[playerRow][playerCol].walls W_RIGHT)) blocked true; if (!blocked) { playerRow nr; playerCol nc; stepCount; // 步數(shù)統(tǒng)計后面可用 Invalidate(FALSE); // 僅重繪客戶區(qū)不擦背景 } } return TRUE; // 方向鍵已處理不再分發(fā) } return CDialogEx::PreTranslateMessage(pMsg); }這段的碰撞檢測只檢查“當(dāng)前格子在自己移動方向上的墻”不需要查目標(biāo)格子的反向墻因為兩格之間的墻在生成時是同步拆掉的墻的狀態(tài)永遠(yuǎn)成對存在。這是一個依賴算法保證的簡化DFS 生成時拆了當(dāng)前格的上墻必然拆了目標(biāo)格的下墻所以單向判定足夠。Invalidate(FALSE)的參數(shù)FALSE表示重繪時不擦背景。配合前面OnEraseBkgnd返回 TRUE整個刷新路徑里沒有任何擦背景的步驟玩家移動時畫面干凈利落。如果你不傳 FALSE默認(rèn)是擦背景移動時會有白閃但這在雙緩沖之下影響不大只是養(yǎng)成寫 FALSE 的習(xí)慣總沒錯。玩家的初始位置是(0, 0)終點是(ROWS-1, COLS-1)。如果你玩著玩著發(fā)現(xiàn)“起點和終點居然通不了”那不是移動代碼的問題是生成算法里墻拆錯了回到 2.3 檢查拆墻邏輯。4. MFC 迷宮開發(fā)的 5 個常見坑現(xiàn)象、原因、解決4.1 內(nèi)存泄漏CString 的 GetBuffer 和 new 出來的迷宮數(shù)組現(xiàn)象程序運行完Visual Studio 輸出窗口顯示Detected memory leaks!一堆帶{1234}塊號的分配記錄定位半天也不知道是哪里的。原因兩個高頻來源。第一有人用new動態(tài)創(chuàng)建二維數(shù)組int** maze new int*[ROWS]釋放時只寫了delete[] maze沒有逐行delete[] maze[i]導(dǎo)致每一行的數(shù)組都泄漏。第二MFC 里CString::GetBuffer(len)之后忘記調(diào)用ReleaseBuffer()CString 內(nèi)部緩沖區(qū)不完整析構(gòu)時可能觸發(fā)斷言或泄漏。迷宮項目里用CString做“步數(shù)提示”或“勝利提示”時最容易踩這個。解決迷宮數(shù)組直接改成std::vectorstd::vectorCell在OnInitDialog里resize好析構(gòu)自動釋放一行維護代碼都不用寫。CString必須用GetBuffer的場合一定配對ReleaseBuffer。寫完后開著內(nèi)存泄漏檢測跑三局游戲輸出窗口還能看到泄漏就繼續(xù)查查干凈再提交。這條簡直是血淚經(jīng)驗我早期寫的 MFC 程序十個有八個掛著泄漏運行一晚上內(nèi)存漲幾百兆。4.2 窗口閃爍缺了 WM_ERASEBKGND 開關(guān)現(xiàn)象迷宮畫出來了但每次Invalidate觸發(fā)重繪窗口先白屏閃一下然后才顯示新畫面?？焖侔捶较蜴I移動玩家時畫面閃得眼睛疼。原因OnPaint里雖然有雙緩沖但系統(tǒng)默認(rèn)仍然在繪圖前擦除背景WM_ERASEBKGND用背景色把客戶區(qū)刷成白色然后再走OnPaint畫迷宮。雙緩沖解決的是“繪制過程可見”背景擦除解決的是“舊畫面殘留”兩個都要處理只做雙緩沖就漏了一半。解決在消息映射里加ON_WM_ERASEBKGND()然后重寫B(tài)OOL CMazeGameDlg::OnEraseBkgnd(CDC* pDC) { return TRUE; // 告訴系統(tǒng)背景已經(jīng)處理好跳過擦除 }改完之后再做快速鍵盤移動測試畫面應(yīng)該沒有白閃。如果仍有輕微閃爍檢查Invalidate調(diào)用是否傳了FALSE傳TRUE會強制擦除背景和上面的設(shè)置互相抵消。4.3 坐標(biāo)映射錯位白線、縫隙與 CELL_SIZE 不一致現(xiàn)象迷宮畫出來后墻壁之間散布著很多細(xì)白線或者玩家明明走到了某個位置卻被判定撞墻感覺格子邊界和視覺邊界對不上。原因兩個層面的問題。白線是畫墻時右、下兩個方向沒有做 1 像素重疊相鄰格子各畫各的墻中間留了一條約 1 像素的空白。判定錯位則是因為繪制用了CELL_SIZE做坐標(biāo)換算但實際畫圖時某個地方用了別的尺寸比如把窗口客戶區(qū)縮放后按比例計算格子大小移動邏輯卻還在用常量CELL_SIZE兩邊數(shù)值不一致。解決畫墻時按 3.2 的做法右邊墻 X 坐標(biāo)用x CELL_SIZE - 1、寬度2下邊墻同理多畫 1 像素。更省事的方法是畫整條線段而不是畫矩形直接用MoveTo/LineTo把墻當(dāng)作線繪制但線的寬度控制沒有矩形直觀。邊界判定問題最簡單的方案是固定窗口大小不要允許縮放OnInitDialog里調(diào)用SetWindowPos把窗口設(shè)成剛好放下迷宮再加一圈邊距的大小讓CELL_SIZE成為唯一尺寸來源。沒有縮放就沒有換算沒有換算就沒有錯位。4.4 Unicode 字符集CString 和 char* 混用帶來的報錯現(xiàn)象代碼里寫CString str 移動步數(shù): stepCount;編譯報錯或者把CString傳給某個char*參數(shù)的函數(shù)時輸出亂碼更夸張的情況是安安靜靜地編譯通過、運行結(jié)果全是亂碼。原因Visual Studio 的 MFC 項目默認(rèn)字符集是 UnicodeCString在 Unicode 下內(nèi)部存的是寬字符和char*不是一回事。字符串字面量移動步數(shù)在 Unicode 項目里是const char[]賦值給CString時發(fā)生隱式轉(zhuǎn)換但如果你反過來把CString強轉(zhuǎn)給char*那只是把指針硬掰過去了數(shù)據(jù)完全不對。解決所有字符串字面量統(tǒng)一寫成_T(移動步數(shù))或L移動步數(shù)格式化用CString::Format而不是字符串拼接CString strMsg; strMsg.Format(_T(移動步數(shù): %d), stepCount); SetWindowText(strMsg);這個坑的隱蔽之處在于小規(guī)模測試時混用char*和CString往往不報錯因為有些重載函數(shù)同時接受兩種參數(shù)編譯過了就以為沒事。等到中文路徑、中文提示全部亂碼的時候才反應(yīng)過來是字符集問題。建議整個項目統(tǒng)一使用 CString 和_T()宏一句char*都不要出現(xiàn)。4.5 方向鍵失靈焦點被控件吃掉現(xiàn)象程序剛啟動時方向鍵能控制玩家移動但一旦用鼠標(biāo)點過別的按鈕或者編輯框方向鍵就完全沒有反應(yīng)了點回窗口空白處又恢復(fù)。原因?qū)υ捒蚶锼锌丶际亲哟翱诿總€子窗口都能獲得焦點。方向鍵的WM_KEYDOWN消息會發(fā)給當(dāng)前擁有焦點的窗口如果焦點在一個按鈕上按鈕把方向鍵消息自己處理掉了對話框的OnKeyDown根本收不到。這就是為什么我把移動邏輯放在PreTranslateMessage里它在消息分發(fā)的最前端攔截跟焦點無關(guān)。解決如 3.3 所示重寫PreTranslateMessage在方向鍵消息到達任何控件之前先處理處理完返回TRUE阻止繼續(xù)分發(fā)。同時把對話框本身設(shè)為默認(rèn)焦點OnInitDialog里調(diào)用SetFocus到迷宮繪圖區(qū)域。如果你用視圖類而不是對話框類則要用OnKeyDown配合SetFocus處理但原理一樣焦點是鍵盤消息的分發(fā)依據(jù)截獲位置要選在焦點機制的上游。5. 進階技巧連通性驗證、難度梯度與撤銷一步迷宮寫完之后怎么證明它真的是一張可解迷宮拿人肉跑一遍太慢我在調(diào)試階段會寫一個驗證函數(shù)從起點用 BFS 搜索到終點搜到了說明路是通的同時把最短路徑長度也算出來和玩家實際步數(shù)對比就能判斷玩家繞了多遠(yuǎn)。void CMazeGameDlg::ValidateMaze() { // 用 BFS 從起點找終點同時記錄步數(shù) int dist[ROWS][COLS]; memset(dist, -1, sizeof(dist)); std::queuestd::pairint, int q; q.push({0, 0}); dist[0][0] 0; int dr[4] { -1, 0, 1, 0 }; int dc[4] { 0, 1, 0, -1 }; while (!q.empty()) { auto [r, c] q.front(); q.pop(); for (int d 0; d 4; d) { // 當(dāng)前位置的墻決定了能否向 d 方向走 if ((maze[r][c].walls (1 d)) ! 0) continue; int nr r dr[d]; int nc c dc[d]; if (nr 0 || nr ROWS || nc 0 || nc COLS) continue; if (dist[nr][nc] ! -1) continue; dist[nr][nc] dist[r][c] 1; q.push({nr, nc}); } } TRACE(_T(終點最短步數(shù): %d\n), dist[ROWS - 1][COLS - 1]); }這個驗證函數(shù)建議每次修改迷宮生成算法后都跑一遍只花幾毫秒能攔住大部分“看著連通實際走不通”的情況。生成質(zhì)量還可以用死路比例衡量——統(tǒng)計四面都有墻、只有三面墻入口除外的格子數(shù)量死路太多說明算法參數(shù)需要調(diào)比如把 DFS 的隨機方向洗牌改得更激進。迷宮本體做完了我往這個小項目里加過兩個小功能成本很低但很提升完成度。一個是計時器SetTimer每 1 秒觸發(fā)一次WM_TIMER在窗口標(biāo)題欄顯示已用時間玩家到達終點后KillTimer停表配合步數(shù)統(tǒng)計做一個簡單的“步數(shù)時間”雙指標(biāo)。另一個是后悔藥維護一個std::stackstd::pairint, int保存歷史位置按 Backspace 鍵時把playerRow/playerCol恢復(fù)為棧頂值并彈棧實現(xiàn)撤銷一步。這個功能對測試特別有用走到絕路想回頭看看不用自己慢慢原路摸回去。做這個小迷宮的過程里我最大的一個習(xí)慣收獲是每次改完代碼先跑驗證函數(shù)看最短路徑步數(shù)再手動玩一局最后看輸出窗口有沒有泄漏三步全過才算完。不要急著加新功能基礎(chǔ)的東西寧可慢一點也要穩(wěn)。希望幫到你。本文還有配套的精品資源點擊獲取 MFC迷宮游戲開發(fā)實戰(zhàn)：雙緩沖繪制與DFS生成算法解析
簡介這是一套使用MFC編寫的簡單迷宮游戲完整工程面向初學(xué)Windows程序設(shè)計或C圖形界面的開發(fā)者演示如何基于MFC框架搭建可交互的迷宮小游戲。資源共45個文件壓縮包約2.13MB其中包含7個頭文件與6個C源文件實現(xiàn)文檔/視圖架構(gòu)、迷宮邏輯與玩家控制、資源腳本與位圖/圖標(biāo)文件以及可直接運行的exe程序和步驟PNG截圖便于對照源碼理解界面構(gòu)建、消息映射與繪圖過程。游戲涉及二維數(shù)組存儲迷宮、深度優(yōu)先或廣度優(yōu)先路徑搜索等經(jīng)典算法通過鍵盤或鼠標(biāo)操作完成尋路適合用來學(xué)習(xí)面向?qū)ο蠓庋b和Windows事件驅(qū)動機制。已有378人瀏覽學(xué)習(xí)。借助這份資料可快速上手MFC工程結(jié)構(gòu)并根據(jù)提示修改迷宮地圖、自定義關(guān)卡是一個能反復(fù)研讀的練手范例。1. MFC迷宮游戲從拖控件到自繪的第一道坎很多人學(xué) MFC 是從對話框拖按鈕開始的拖一個 Button、拖一個 Edit 控件雙擊生成消息處理函數(shù)以為這就是 Windows 桌面開發(fā)的全部。但用 MFC 做一個簡單的迷宮游戲會把你的認(rèn)知拉回正確的軌道上迷宮游戲沒有現(xiàn)成控件可用你得自己定義數(shù)據(jù)結(jié)構(gòu)存迷宮、自己寫繪制代碼把格子畫出來、自己處理鍵盤消息讓玩家動起來。這一趟走完你對 CWnd、CDC、消息映射這三個 MFC 核心機制的理解會扎實很多。這個項目非常適合作為學(xué)完對話框之后的第二個練手程序也是面試時能拿得出手的“真寫過代碼”的證明。本文按我實際做這個迷宮的思路來拆解從數(shù)據(jù)結(jié)構(gòu)選型講到繪制和避坑全程可復(fù)現(xiàn)。2. 迷宮怎么生成才像迷宮數(shù)據(jù)結(jié)構(gòu)與 DFS 遞歸回溯選型2.1 迷宮格子怎么存位運算而不是二維 bool迷宮游戲的第一件事不是畫圖是決定迷宮在內(nèi)存里長什么樣。最常見的做法是給每個格子存“四面墻是否存在”。初學(xué)者容易寫成兩個二維數(shù)組bool wallUp[ROWS][COLS]、bool wallRight[ROWS][COLS]四個方向四個數(shù)組訪問起來啰嗦擴展一個斜向墻就改結(jié)構(gòu)。我一般用一個結(jié)構(gòu)體加上位標(biāo)記// 每個格子的墻用 BYTE 的四個位表示1 表示該方向有墻 struct Cell { BYTE walls; // bit0上墻, bit1右墻, bit2下墻, bit3左墻 }; #define W_UP 0x01 #define W_RIGHT 0x02 #define W_DOWN 0x04 #define W_LEFT 0x08 Cell maze[ROWS][COLS];這里ROWS和COLS我用宏或者const int定死比如 16 行 12 列。不用vectorvectorCell是因為固定尺寸迷宮用 C 數(shù)組更直觀訪問連續(xù)內(nèi)存也更快等你后面加縮放、加存檔再換容器不遲。初始化時把每個Cell.walls置為W_UP | W_RIGHT | W_DOWN | W_LEFT表示所有墻都在后面生成過程就是不斷拆墻。用位運算而不是四個 bool 的好處在移動檢測時看得最清楚判斷“玩家想往上走是否被擋住”只需要if (maze[r][c].walls W_UP)一行。四個方向的判斷都是同一套邏輯不會出現(xiàn)wallUp[r][c] wallRight[r][c]這種越寫越亂的局面。位運算在 MFC 里也常見讀慣了GetStyle() WS_CHILD這種寫法的人對這種風(fēng)格不會陌生。2.2 DFS 遞歸回溯 vs 隨機 Prim生成選型和對比迷宮生成算法有兩大類一類是深度優(yōu)先遞歸回溯一類是隨機 Prim。兩種都能生成“完美迷宮”也就是任意兩點之間有且僅有一條路徑的迷宮。我在做這個簡單迷宮時選了 DFS 遞歸回溯因為它代碼量最小、邏輯最好講生成出來的迷宮主路長、岔路深玩起來更有“闖關(guān)感”。兩種算法對比在實際效果上的差異很明顯對比項DFS 遞歸回溯隨機 Prim生成思路沿一條路走到黑撞墻后回退每次從墻集合里隨機挑一面墻拆分支形態(tài)分支少、主路長、胡同長而深分支均勻、迷宮區(qū)域更“碎”實現(xiàn)代碼量約 30 行無額外容器需要維護墻候選集合約 50 行生成速度O(ROWS*COLS)很快同樣 O(ROWS*COLS)但常數(shù)更大玩家體驗一條主路走到底方向感強道路交織更容易迷路如果你只想讓迷宮生成得“看起來均勻”Prim 更好但游戲性上DFS 生成的大迷宮更有挑戰(zhàn)性因為它的路徑轉(zhuǎn)折多、死胡同深玩家經(jīng)常走進一個長胡同發(fā)現(xiàn)到頭了轉(zhuǎn)身出來時已經(jīng)分不清方向。這正是迷宮游戲需要的體驗。而且 DFS 遞歸回溯是理解圖遍歷的經(jīng)典入門題寫完這個算法你去看其他遞歸回溯的代碼會輕松很多。另一個選 DFS 的原因是 MFC 程序里遞歸調(diào)用棧本身就夠用。16x12 的迷宮遞歸深度最多兩百多層完全不用擔(dān)心棧溢出。如果你把迷宮擴到 100x100我建議改用顯式棧的迭代版 DFS或者在項目屬性里加大?？臻g但那個量級已經(jīng)不是“簡單迷宮”的范疇了。2.3 用 DFS 生成一張 16x12 迷宮代碼與參數(shù)說明生成函數(shù)的核心邏輯是從起點格開始隨機挑選一個未訪問過的相鄰格拆掉兩格之間的墻遞歸進入該格。四個方向的處理我用一個dirs數(shù)組做隨機洗牌而不是寫四段 if這樣代碼能復(fù)用同一套拆墻邏輯。void CMazeGameDlg::GenerateMaze(int r, int c) { visited[r][c] true; // visited 是 BOOL 二維數(shù)組全局或成員變量 // 四個方向用數(shù)組表示{上, 右, 下, 左} 對應(yīng)的行列變化 int dr[4] { -1, 0, 1, 0 }; int dc[4] { 0, 1, 0, -1 }; // 隨機打亂方向順序保證每次生成的迷宮不一樣 int dirs[4] { 0, 1, 2, 3 }; for (int i 3; i 0; i--) { int j rand() % (i 1); std::swap(dirs[i], dirs[j]); } for (int k 0; k 4; k) { int nr r dr[dirs[k]]; int nc c dc[dirs[k]]; if (nr 0 || nr ROWS || nc 0 || nc COLS) continue; // 越界 if (visited[nr][nc]) continue; // 已經(jīng)訪問過跳過 // 拆掉當(dāng)前格與目標(biāo)格之間的墻 if (dirs[k] 0) { // 目標(biāo)在上方 maze[r][c].walls ~W_UP; maze[nr][nc].walls ~W_DOWN; } else if (dirs[k] 1) { // 目標(biāo)在右方 maze[r][c].walls ~W_RIGHT; maze[nr][nc].walls ~W_LEFT; } else if (dirs[k] 2) { // 目標(biāo)在下方 maze[r][c].walls ~W_DOWN; maze[nr][nc].walls ~W_UP; } else { // 目標(biāo)在左方 maze[r][c].walls ~W_LEFT; maze[nr][nc].walls ~W_RIGHT; } GenerateMaze(nr, nc); // 遞歸進入下一個格子 } }調(diào)用時從(0, 0)開始GenerateMaze(0, 0)算法跑完整張迷宮里所有格子都連成了一條通路而且保證沒有環(huán)路。關(guān)鍵參數(shù)就兩個一個是迷宮尺寸ROWS/COLS我取 16x12 是為了配合每個格子 20 像素的繪制尺寸最終窗口客戶區(qū)大約 320x240不需要滾動條另一個是隨機數(shù)種子建議在OnInitDialog里調(diào)用srand((unsigned)time(NULL))否則每次運行生成的是同一張迷宮玩一遍就膩了。這里的“先拆墻、再遞歸”和“先標(biāo)記 visited、再進入”有一個順序上的講究必須在遞歸調(diào)用之前就把兩格之間的墻拆掉。原因很簡單遞歸進入鄰格之后可能馬上又從鄰格往回走到當(dāng)前格如果墻沒拆就會形成一堵格格不入的斷墻迷宮看起來有一條路、實際走不通。3. 畫格子與走格子雙緩沖繪制和鍵盤移動的完整實現(xiàn)3.1 為什么要雙緩沖閃爍的根源和 OnEraseBkgnd迷宮生成完接下來的問題是把它畫到窗口上。直接在OnPaint里拿CPaintDC畫墻、畫地板窗口一刷新就會狂閃。原因每個 MFC 初學(xué)者都遇過窗口在重繪時先擦背景再畫前景擦是白屏畫是迷宮兩個動作交替人眼看到的是一亮一暗的“頻閃”。窗口越大、繪制邏輯越重閃爍越明顯。解決思路是雙緩沖先在一張內(nèi)存位圖上把迷宮完整畫好再一次BitBlt把整張圖拷貝到窗口上。這樣用戶看不到“畫了一半”的中間狀態(tài)只看到最終結(jié)果。雙緩沖是 Windows 繪圖里最基礎(chǔ)也最有效的性能手段在迷宮、游戲、自定義控件里都是必用方案。配合雙緩沖還要做一件事把背景擦除干掉。MFC 的默認(rèn)窗口類會在WM_ERASEBKGND消息里用背景色刷一遍窗口這就是閃爍的另一個源頭。標(biāo)準(zhǔn)做法是重寫OnEraseBkgnd直接返回 TRUE 告訴系統(tǒng)“背景你已經(jīng)處理完了別擦”。BOOL CMazeGameDlg::OnEraseBkgnd(CDC* pDC) { // 返回 TRUE 阻止系統(tǒng)默認(rèn)擦背景避免閃屏 return TRUE; }注意這個函數(shù)在類向?qū)Ю锟床坏叫枰謩釉谙⒂成淅锛覱N_WM_ERASEBKGND()。加上之后背景擦除被禁用所有刷新都在內(nèi)存 DC 中完成再BitBlt上屏。3.2 OnPaint 里畫墻、玩家與終點核心繪制代碼繪制代碼放在OnPaint里用CPaintDC獲取窗口 DC再創(chuàng)建兼容 DC 和位圖作為緩沖。這里有一個細(xì)節(jié)CreateCompatibleBitmap的尺寸要和客戶區(qū)一致如果你讓窗口可以縮放則每次重繪要重新創(chuàng)建位圖比較麻煩。做簡單迷宮我建議禁掉窗口縮放固定尺寸代碼干凈很多。void CMazeGameDlg::OnPaint() { CPaintDC dc(this); // 窗口 DC CRect rc; GetClientRect(rc); // 創(chuàng)建內(nèi)存 DC 和位圖做雙緩沖 CDC memDC; memDC.CreateCompatibleDC(dc); CBitmap bmp; bmp.CreateCompatibleBitmap(dc, rc.Width(), rc.Height()); CBitmap* pOldBmp memDC.SelectObject(bmp); // 背景色 memDC.FillSolidRect(rc, RGB(240, 240, 240)); // 畫迷宮先地板后墻保證邊界線干凈 for (int r 0; r ROWS; r) { for (int c 0; c COLS; c) { int x c * CELL_SIZE; int y r * CELL_SIZE; // 地板 memDC.FillSolidRect(x, y, CELL_SIZE, CELL_SIZE, RGB(255, 255, 255)); // 四個方向的墻畫 2 像素寬右/下方向多畫 1 像素防止漏縫 if (maze[r][c].walls W_UP) memDC.FillSolidRect(x, y, CELL_SIZE 1, 2, RGB(60, 60, 60)); if (maze[r][c].walls W_RIGHT) memDC.FillSolidRect(x CELL_SIZE - 1, y, 2, CELL_SIZE 1, RGB(60, 60, 60)); if (maze[r][c].walls W_DOWN) memDC.FillSolidRect(x, y CELL_SIZE - 1, CELL_SIZE 1, 2, RGB(60, 60, 60)); if (maze[r][c].walls W_LEFT) memDC.FillSolidRect(x, y, 2, CELL_SIZE 1, RGB(60, 60, 60)); } } // 畫終點右下角格子里畫一個綠色方塊 CBrush greenBrush(RGB(0, 180, 0)); CBrush* pOldBrush memDC.SelectObject(greenBrush); int ex (COLS - 1) * CELL_SIZE CELL_SIZE / 4; int ey (ROWS - 1) * CELL_SIZE CELL_SIZE / 4; memDC.Rectangle(ex, ey, ex CELL_SIZE / 2, ey CELL_SIZE / 2); memDC.SelectObject(pOldBrush); // 還原畫刷 // 畫玩家當(dāng)前格子中心的藍色圓 CBrush blueBrush(RGB(0, 120, 255)); pOldBrush memDC.SelectObject(blueBrush); int px playerCol * CELL_SIZE CELL_SIZE / 4; int py playerRow * CELL_SIZE CELL_SIZE / 4; memDC.Ellipse(px, py, px CELL_SIZE / 2, py CELL_SIZE / 2); memDC.SelectObject(pOldBrush); // 一次拷貝到窗口 dc.BitBlt(0, 0, rc.Width(), rc.Height(), memDC, 0, 0, SRCCOPY); // 清理先把舊位圖選回來再刪對象 memDC.SelectObject(pOldBmp); bmp.DeleteObject(); }參數(shù)說明CELL_SIZE設(shè) 20迷宮格子 20x20 像素墻厚 2 像素。兩點值得注意。第一右邊和下邊的墻畫得比格子邊界多 1 像素是因為相鄰兩個格子各自畫墻時如果不做重疊處理格子之間會出現(xiàn)一條白色細(xì)縫視覺上就是墻“斷”了。這是血淚經(jīng)驗我最早畫出來滿屏白線排查半天發(fā)現(xiàn)是邊界差 1 像素。第二先畫地板再畫墻順序不能反。如果先畫墻地板會把墻蓋掉一半出現(xiàn)鋸齒邊。繪制順序是窗口自繪的通用紀(jì)律尤其在做地圖、棋盤這類網(wǎng)格圖形時。另外畫完玩家后有一行SelectObject還原舊畫刷這步很多人忽略。在內(nèi)存 DC 里不還原問題不大但如果連續(xù)繪制多次或者后續(xù)使用同一個 DC舊對象不還原會導(dǎo)致 GDI 對象泄漏。MFC 的CDC析構(gòu)時雖然會清理但養(yǎng)成“Select 了就要 Select 回來”的習(xí)慣能少踩很多坑。3.3 PreTranslateMessage 里的鍵盤移動與碰撞檢測玩家移動需要響應(yīng)鍵盤方向鍵。MFC 對話框程序有幾種做法重寫OnKeyDown、在PreTranslateMessage里攔截虛鍵消息。我推薦用PreTranslateMessage一個核心原因是對話框里如果有按鈕或其他控件焦點不在對話框本身時WM_KEYDOWN不一定會走到對話框的OnKeyDown表現(xiàn)為“點了一下按鈕之后方向鍵失靈了”。而PreTranslateMessage在消息被分發(fā)到任何窗口之前先過一道手方向鍵在這里攔截最穩(wěn)。BOOL CMazeGameDlg::PreTranslateMessage(MSG* pMsg) { if (pMsg-message WM_KEYDOWN) { UINT key (UINT)pMsg-wParam; int nr playerRow; int nc playerCol; if (key VK_UP) nr--; else if (key VK_DOWN) nr; else if (key VK_LEFT) nc--; else if (key VK_RIGHT) nc; else return CDialogEx::PreTranslateMessage(pMsg); // 其他鍵走默認(rèn) // 先判斷目標(biāo)位置是否在迷宮范圍內(nèi) if (nr 0 nr ROWS nc 0 nc COLS) { // 判斷當(dāng)前格與目標(biāo)格之間的墻是否擋住移動 bool blocked false; if (key VK_UP (maze[playerRow][playerCol].walls W_UP)) blocked true; if (key VK_DOWN (maze[playerRow][playerCol].walls W_DOWN)) blocked true; if (key VK_LEFT (maze[playerRow][playerCol].walls W_LEFT)) blocked true; if (key VK_RIGHT (maze[playerRow][playerCol].walls W_RIGHT)) blocked true; if (!blocked) { playerRow nr; playerCol nc; stepCount; // 步數(shù)統(tǒng)計后面可用 Invalidate(FALSE); // 僅重繪客戶區(qū)不擦背景 } } return TRUE; // 方向鍵已處理不再分發(fā) } return CDialogEx::PreTranslateMessage(pMsg); }這段的碰撞檢測只檢查“當(dāng)前格子在自己移動方向上的墻”不需要查目標(biāo)格子的反向墻因為兩格之間的墻在生成時是同步拆掉的墻的狀態(tài)永遠(yuǎn)成對存在。這是一個依賴算法保證的簡化DFS 生成時拆了當(dāng)前格的上墻必然拆了目標(biāo)格的下墻所以單向判定足夠。Invalidate(FALSE)的參數(shù)FALSE表示重繪時不擦背景。配合前面OnEraseBkgnd返回 TRUE整個刷新路徑里沒有任何擦背景的步驟玩家移動時畫面干凈利落。如果你不傳 FALSE默認(rèn)是擦背景移動時會有白閃但這在雙緩沖之下影響不大只是養(yǎng)成寫 FALSE 的習(xí)慣總沒錯。玩家的初始位置是(0, 0)終點是(ROWS-1, COLS-1)。如果你玩著玩著發(fā)現(xiàn)“起點和終點居然通不了”那不是移動代碼的問題是生成算法里墻拆錯了回到 2.3 檢查拆墻邏輯。4. MFC 迷宮開發(fā)的 5 個常見坑現(xiàn)象、原因、解決4.1 內(nèi)存泄漏CString 的 GetBuffer 和 new 出來的迷宮數(shù)組現(xiàn)象程序運行完Visual Studio 輸出窗口顯示Detected memory leaks!一堆帶{1234}塊號的分配記錄定位半天也不知道是哪里的。原因兩個高頻來源。第一有人用new動態(tài)創(chuàng)建二維數(shù)組int** maze new int*[ROWS]釋放時只寫了delete[] maze沒有逐行delete[] maze[i]導(dǎo)致每一行的數(shù)組都泄漏。第二MFC 里CString::GetBuffer(len)之后忘記調(diào)用ReleaseBuffer()CString 內(nèi)部緩沖區(qū)不完整析構(gòu)時可能觸發(fā)斷言或泄漏。迷宮項目里用CString做“步數(shù)提示”或“勝利提示”時最容易踩這個。解決迷宮數(shù)組直接改成std::vectorstd::vectorCell在OnInitDialog里resize好析構(gòu)自動釋放一行維護代碼都不用寫。CString必須用GetBuffer的場合一定配對ReleaseBuffer。寫完后開著內(nèi)存泄漏檢測跑三局游戲輸出窗口還能看到泄漏就繼續(xù)查查干凈再提交。這條簡直是血淚經(jīng)驗我早期寫的 MFC 程序十個有八個掛著泄漏運行一晚上內(nèi)存漲幾百兆。4.2 窗口閃爍缺了 WM_ERASEBKGND 開關(guān)現(xiàn)象迷宮畫出來了但每次Invalidate觸發(fā)重繪窗口先白屏閃一下然后才顯示新畫面?？焖侔捶较蜴I移動玩家時畫面閃得眼睛疼。原因OnPaint里雖然有雙緩沖但系統(tǒng)默認(rèn)仍然在繪圖前擦除背景WM_ERASEBKGND用背景色把客戶區(qū)刷成白色然后再走OnPaint畫迷宮。雙緩沖解決的是“繪制過程可見”背景擦除解決的是“舊畫面殘留”兩個都要處理只做雙緩沖就漏了一半。解決在消息映射里加ON_WM_ERASEBKGND()然后重寫B(tài)OOL CMazeGameDlg::OnEraseBkgnd(CDC* pDC) { return TRUE; // 告訴系統(tǒng)背景已經(jīng)處理好跳過擦除 }改完之后再做快速鍵盤移動測試畫面應(yīng)該沒有白閃。如果仍有輕微閃爍檢查Invalidate調(diào)用是否傳了FALSE傳TRUE會強制擦除背景和上面的設(shè)置互相抵消。4.3 坐標(biāo)映射錯位白線、縫隙與 CELL_SIZE 不一致現(xiàn)象迷宮畫出來后墻壁之間散布著很多細(xì)白線或者玩家明明走到了某個位置卻被判定撞墻感覺格子邊界和視覺邊界對不上。原因兩個層面的問題。白線是畫墻時右、下兩個方向沒有做 1 像素重疊相鄰格子各畫各的墻中間留了一條約 1 像素的空白。判定錯位則是因為繪制用了CELL_SIZE做坐標(biāo)換算但實際畫圖時某個地方用了別的尺寸比如把窗口客戶區(qū)縮放后按比例計算格子大小移動邏輯卻還在用常量CELL_SIZE兩邊數(shù)值不一致。解決畫墻時按 3.2 的做法右邊墻 X 坐標(biāo)用x CELL_SIZE - 1、寬度2下邊墻同理多畫 1 像素。更省事的方法是畫整條線段而不是畫矩形直接用MoveTo/LineTo把墻當(dāng)作線繪制但線的寬度控制沒有矩形直觀。邊界判定問題最簡單的方案是固定窗口大小不要允許縮放OnInitDialog里調(diào)用SetWindowPos把窗口設(shè)成剛好放下迷宮再加一圈邊距的大小讓CELL_SIZE成為唯一尺寸來源。沒有縮放就沒有換算沒有換算就沒有錯位。4.4 Unicode 字符集CString 和 char* 混用帶來的報錯現(xiàn)象代碼里寫CString str 移動步數(shù): stepCount;編譯報錯或者把CString傳給某個char*參數(shù)的函數(shù)時輸出亂碼更夸張的情況是安安靜靜地編譯通過、運行結(jié)果全是亂碼。原因Visual Studio 的 MFC 項目默認(rèn)字符集是 UnicodeCString在 Unicode 下內(nèi)部存的是寬字符和char*不是一回事。字符串字面量移動步數(shù)在 Unicode 項目里是const char[]賦值給CString時發(fā)生隱式轉(zhuǎn)換但如果你反過來把CString強轉(zhuǎn)給char*那只是把指針硬掰過去了數(shù)據(jù)完全不對。解決所有字符串字面量統(tǒng)一寫成_T(移動步數(shù))或L移動步數(shù)格式化用CString::Format而不是字符串拼接CString strMsg; strMsg.Format(_T(移動步數(shù): %d), stepCount); SetWindowText(strMsg);這個坑的隱蔽之處在于小規(guī)模測試時混用char*和CString往往不報錯因為有些重載函數(shù)同時接受兩種參數(shù)編譯過了就以為沒事。等到中文路徑、中文提示全部亂碼的時候才反應(yīng)過來是字符集問題。建議整個項目統(tǒng)一使用 CString 和_T()宏一句char*都不要出現(xiàn)。4.5 方向鍵失靈焦點被控件吃掉現(xiàn)象程序剛啟動時方向鍵能控制玩家移動但一旦用鼠標(biāo)點過別的按鈕或者編輯框方向鍵就完全沒有反應(yīng)了點回窗口空白處又恢復(fù)。原因?qū)υ捒蚶锼锌丶际亲哟翱诿總€子窗口都能獲得焦點。方向鍵的WM_KEYDOWN消息會發(fā)給當(dāng)前擁有焦點的窗口如果焦點在一個按鈕上按鈕把方向鍵消息自己處理掉了對話框的OnKeyDown根本收不到。這就是為什么我把移動邏輯放在PreTranslateMessage里它在消息分發(fā)的最前端攔截跟焦點無關(guān)。解決如 3.3 所示重寫PreTranslateMessage在方向鍵消息到達任何控件之前先處理處理完返回TRUE阻止繼續(xù)分發(fā)。同時把對話框本身設(shè)為默認(rèn)焦點OnInitDialog里調(diào)用SetFocus到迷宮繪圖區(qū)域。如果你用視圖類而不是對話框類則要用OnKeyDown配合SetFocus處理但原理一樣焦點是鍵盤消息的分發(fā)依據(jù)截獲位置要選在焦點機制的上游。5. 進階技巧連通性驗證、難度梯度與撤銷一步迷宮寫完之后怎么證明它真的是一張可解迷宮拿人肉跑一遍太慢我在調(diào)試階段會寫一個驗證函數(shù)從起點用 BFS 搜索到終點搜到了說明路是通的同時把最短路徑長度也算出來和玩家實際步數(shù)對比就能判斷玩家繞了多遠(yuǎn)。void CMazeGameDlg::ValidateMaze() { // 用 BFS 從起點找終點同時記錄步數(shù) int dist[ROWS][COLS]; memset(dist, -1, sizeof(dist)); std::queuestd::pairint, int q; q.push({0, 0}); dist[0][0] 0; int dr[4] { -1, 0, 1, 0 }; int dc[4] { 0, 1, 0, -1 }; while (!q.empty()) { auto [r, c] q.front(); q.pop(); for (int d 0; d 4; d) { // 當(dāng)前位置的墻決定了能否向 d 方向走 if ((maze[r][c].walls (1 d)) ! 0) continue; int nr r dr[d]; int nc c dc[d]; if (nr 0 || nr ROWS || nc 0 || nc COLS) continue; if (dist[nr][nc] ! -1) continue; dist[nr][nc] dist[r][c] 1; q.push({nr, nc}); } } TRACE(_T(終點最短步數(shù): %d\n), dist[ROWS - 1][COLS - 1]); }這個驗證函數(shù)建議每次修改迷宮生成算法后都跑一遍只花幾毫秒能攔住大部分“看著連通實際走不通”的情況。生成質(zhì)量還可以用死路比例衡量——統(tǒng)計四面都有墻、只有三面墻入口除外的格子數(shù)量死路太多說明算法參數(shù)需要調(diào)比如把 DFS 的隨機方向洗牌改得更激進。迷宮本體做完了我往這個小項目里加過兩個小功能成本很低但很提升完成度。一個是計時器SetTimer每 1 秒觸發(fā)一次WM_TIMER在窗口標(biāo)題欄顯示已用時間玩家到達終點后KillTimer停表配合步數(shù)統(tǒng)計做一個簡單的“步數(shù)時間”雙指標(biāo)。另一個是后悔藥維護一個std::stackstd::pairint, int保存歷史位置按 Backspace 鍵時把playerRow/playerCol恢復(fù)為棧頂值并彈棧實現(xiàn)撤銷一步。這個功能對測試特別有用走到絕路想回頭看看不用自己慢慢原路摸回去。做這個小迷宮的過程里我最大的一個習(xí)慣收獲是每次改完代碼先跑驗證函數(shù)看最短路徑步數(shù)再手動玩一局最后看輸出窗口有沒有泄漏三步全過才算完。不要急著加新功能基礎(chǔ)的東西寧可慢一點也要穩(wěn)。希望幫到你。本文還有配套的精品資源點擊獲取