簡(jiǎn)介一份基于MFC開發(fā)的掃雷游戲完整源碼包面向C初學(xué)者與Windows界面編程愛好者旨在展示如何使用MFC框架構(gòu)建經(jīng)典小游戲的完整流程。包內(nèi)共71個(gè)文件涵蓋bmp位圖資源用于雷區(qū)、笑臉等圖標(biāo)、cpp/h源碼實(shí)現(xiàn)對(duì)話框、自定義按鈕及游戲邏輯、dll動(dòng)態(tài)庫與可直接運(yùn)行的exe壓縮包大小約2.7MB結(jié)構(gòu)清晰便于按模塊查閱。代碼包含CMyDialog、CMyButton等關(guān)鍵類通過消息映射機(jī)制處理點(diǎn)擊事件實(shí)現(xiàn)雷區(qū)隨機(jī)生成、數(shù)字計(jì)算、計(jì)時(shí)統(tǒng)計(jì)與勝負(fù)判斷并配套工程文件、調(diào)試信息和說明文檔。已有475人學(xué)習(xí)下載適合用于理解MFC的消息循環(huán)、控件封裝和游戲狀態(tài)管理也可作為課程設(shè)計(jì)或入門實(shí)戰(zhàn)項(xiàng)目的參考模板。1. MFC掃雷這份源碼到底值不值得你花時(shí)間啃“MFC掃雷”這個(gè)題目在高校課程設(shè)計(jì)和入職筆試?yán)锍霈F(xiàn)的頻率高得驚人。一份含源碼的MFC掃雷程序表面是個(gè)游戲?qū)嶋H把Windows桌面開發(fā)最核心的三件事全練到了消息機(jī)制怎么驅(qū)動(dòng)界面、GDI怎么把數(shù)據(jù)畫出來、程序狀態(tài)怎么維護(hù)不崩。如果你正對(duì)著源碼不知道從哪看起或者自己動(dòng)手寫的時(shí)候一布雷就炸、一重繪就閃這篇文章就是按我做這類小工程的復(fù)盤順序來的。適合三類人要交MFC課設(shè)的學(xué)生、剛接手老MFC維護(hù)項(xiàng)目的程序員、以及想通過小游戲把Windows消息映射徹底搞明白的桌面開發(fā)者。2. 拆解MFC掃雷工程消息映射、類的分工先把骨架看明白2.1 為什么掃雷適合當(dāng)MFC練手消息、繪制、定時(shí)器一次全碰到有人問我桌面軟件開發(fā)用MFC還是Qt我的回答一直是新項(xiàng)目選Qt沒毛病但存量市場(chǎng)和課設(shè)題目里MFC依然活躍。MFC這套東西學(xué)了不虧因?yàn)槟阋獙W(xué)的不是那幾個(gè)封裝好的類而是它底下的Windows消息機(jī)制。掃雷這個(gè)小游戲恰好把MFC里最常見的幾樣?xùn)|西全占了窗口類、消息映射宏、GDI繪圖、定時(shí)器、狀態(tài)欄。貪吃蛇也能練MFC但它只需要定時(shí)器和方向鍵沒法體現(xiàn)鼠標(biāo)右鍵的邏輯計(jì)算器能練對(duì)話框但繪制太簡(jiǎn)單。掃雷的輸入是左鍵翻開、右鍵插旗輸出是格子顏色和數(shù)字中間夾著遞歸展開、布雷、計(jì)時(shí)三塊邏輯復(fù)雜度恰到好處。這也是為什么這么多年課設(shè)題目里它一直沒被替換掉。網(wǎng)上MFC教程不算少但很多教程講完消息映射就停在“彈個(gè)對(duì)話框”的層次真正能落地成完整游戲的源碼反而稀缺。拿到一份工程第一件事不是按F5編譯而是先看它的文件結(jié)構(gòu)和類劃分這決定了你后面三天是順利還是反復(fù)翻車。2.2 工程該建哪幾個(gè)類CWinApp、CFrameWnd與邏輯類的邊界一個(gè)結(jié)構(gòu)清晰的MFC掃雷工程至少拆成三個(gè)類而且每個(gè)類的職責(zé)必須單一。我見過最糟糕的寫法是所有代碼塞在視圖類的OnPaint和OnLButtonDown里布雷、遞歸、繪制全揉在一起改一個(gè)數(shù)字顏色要找半天。這種代碼我一般直接建議重寫。常見的做法是這樣的類基類職責(zé)CScanMineAppCWinApp程序入口創(chuàng)建主窗口CMainFrameCFrameWnd窗口生命周期、消息分發(fā)、GDI繪制CMineGame普通C類棋盤數(shù)據(jù)、布雷、翻開邏輯、勝負(fù)判斷CScanMineApp是全局唯一的應(yīng)用對(duì)象負(fù)責(zé)在InitInstance里new出主窗口。CMainFrame是窗口的化身所有鼠標(biāo)消息、繪制消息最終都落到它頭上。CMineGame是純粹的算法類里面不出現(xiàn)任何HWND、CDC它只管二維數(shù)組和狀態(tài)計(jì)算。為什么要單獨(dú)拆一個(gè)CMineGame出來因?yàn)檫壿嫼徒缑骜詈显谝黄鸷竽銢]法單獨(dú)測(cè)試算法。布雷對(duì)不對(duì)、遞歸展開會(huì)不會(huì)死循環(huán)、勝利判定邊界有沒有漏洞這些問題在沒有窗口的情況下用命令行就能驗(yàn)證。等邏輯類穩(wěn)定了再做界面接入出問題時(shí)能立刻定位到是算法錯(cuò)還是繪制錯(cuò)不用對(duì)著黑匣子猜。2.3 最小可跑的MFC窗口骨架從InitInstance到消息映射宏掃雷界面的起點(diǎn)是一個(gè)能創(chuàng)建窗口、能接收鼠標(biāo)消息的框架?；趩挝臋n還是基于對(duì)話框都能做掃雷我習(xí)慣用CFrameWnd直接派生因?yàn)樗葘?duì)話框少了模板生成的怪代碼結(jié)構(gòu)更直白。最小骨架如下// ScanMineApp.h class CScanMineApp : public CWinApp { public: virtual BOOL InitInstance(); }; // ScanMineApp.cpp BEGIN_MESSAGE_MAP(CScanMineApp, CWinApp) END_MESSAGE_MAP() BOOL CScanMineApp::InitInstance() { // 創(chuàng)建主窗口第二個(gè)參數(shù)是窗口標(biāo)題 CMainFrame* pFrame new CMainFrame; pFrame-Create(NULL, _T(MFC掃雷)); m_pMainWnd pFrame; pFrame-ShowWindow(SW_SHOW); // 顯示窗口 return TRUE; // 返回TRUE才會(huì)進(jìn)入消息循環(huán) }這段代碼里pFrame-Create(NULL, ...)的第一個(gè)參數(shù)是窗口類名傳NULL表示使用MFC默認(rèn)注冊(cè)的窗口類m_pMainWnd是CWinApp的成員指向主窗口框架退出時(shí)會(huì)用它做清理。注意InitInstance返回FALSE會(huì)導(dǎo)致程序直接退出這是個(gè)常見的低級(jí)錯(cuò)誤點(diǎn)。窗口類本身長(zhǎng)這樣重點(diǎn)是消息映射宏// MainFrame.h class CMainFrame : public CFrameWnd { public: CMainFrame(); protected: afx_msg void OnPaint(); // 繪制 afx_msg void OnLButtonDown(UINT nFlags, CPoint point); afx_msg void OnRButtonDown(UINT nFlags, CPoint point); DECLARE_MESSAGE_MAP() }; // MainFrame.cpp BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd) ON_WM_PAINT() ON_WM_LBUTTONDOWN() ON_WM_RBUTTONDOWN() END_MESSAGE_MAP()afx_msg其實(shí)是個(gè)空宏只是告訴讀代碼的人“這是消息處理函數(shù)”。真正起作用的是BEGIN_MESSAGE_MAP和ON_WM_XXX之間的配對(duì)它把Windows消息ID比如WM_LBUTTONDOWN綁定到對(duì)應(yīng)的成員函數(shù)。MFC收到鼠標(biāo)點(diǎn)擊后會(huì)查這張表找到OnLButtonDown去調(diào)用。消息映射是MFC的命根子也是掃雷程序里最值得反復(fù)看的機(jī)制。你在Win32時(shí)代要自己寫switch (message)分支MFC用宏表替你做了這件事。后面的繪制、鼠標(biāo)左右鍵處理全都掛在這張表上。先把這個(gè)骨架跑通再往里面加棋盤等于地基已經(jīng)打牢。3. 布雷與翻開算法第一次點(diǎn)擊不炸、遞歸展開不崩的核心實(shí)現(xiàn)3.1 用二維數(shù)組還是vector存棋盤數(shù)據(jù)結(jié)構(gòu)怎么定掃雷棋盤不管是9x9初級(jí)還是16x30高級(jí)本質(zhì)都是二維網(wǎng)格。存法上有兩種流派固定大小的二維數(shù)組bool board[9][9]或者動(dòng)態(tài)的一維std::vectorCell手動(dòng)換算下標(biāo)。我推薦后者因?yàn)閽呃淄ǔＳ谐跫?jí)、中級(jí)、高級(jí)三檔棋盤尺寸是玩家選的固定數(shù)組要么浪費(fèi)空間要么寫死尺寸無法擴(kuò)展。每個(gè)格子用一個(gè)結(jié)構(gòu)體描述字段要分開別把多個(gè)狀態(tài)塞進(jìn)一個(gè)int里按位運(yùn)算struct Cell { bool isMine; // 是否是雷 bool isRevealed; // 是否已被翻開 bool isFlagged; // 是否被插旗 int neighbor; // 周邊8格雷的數(shù)量-1表示是雷 };neighbor初始化為0布雷結(jié)束后統(tǒng)一計(jì)算。用-1標(biāo)記雷格這樣渲染時(shí)拿到neighbor -1直接畫地雷圖標(biāo)不用再查isMine。邏輯上前三個(gè)bool互不沖突插旗和翻開是兩件獨(dú)立的事這個(gè)設(shè)計(jì)在后面處理右鍵標(biāo)記時(shí)能省不少事。一維vector的下標(biāo)換算公式是index row * cols col。這個(gè)公式會(huì)在布雷、遞歸展開、繪制三個(gè)地方反復(fù)出現(xiàn)統(tǒng)一寫成內(nèi)聯(lián)函數(shù)或者宏別到處手寫否則改行列數(shù)時(shí)會(huì)漏改某個(gè)角落。另外隨機(jī)數(shù)要用rand()就記得設(shè)置種子。很多人不寫srand結(jié)果每局地圖一模一樣還以為是布雷寫錯(cuò)了。正確做法是在InitInstance里調(diào)用一次srand((unsigned)time(NULL))整個(gè)程序生命周期只調(diào)用這一次。3.2 布雷算法與首次安全點(diǎn)擊兩套常見方案的取舍布雷的邏輯很直白隨機(jī)挑格子是雷就跳過不是雷就放一顆直到放滿指定的雷數(shù)。代碼如下void CMineGame::InitBoard(int rows, int cols, int mineCount) { m_rows rows; m_cols cols; m_mineCount mineCount; m_board.assign(rows * cols, Cell()); // 全部重置 int placed 0; while (placed mineCount) { int r rand() % rows; int c rand() % cols; Cell cell m_board[r * m_cols c]; if (!cell.isMine) { cell.isMine true; cell.neighbor -1; // 雷格標(biāo)記為-1 placed; } } RecalcNeighborCount(); // 見下方說明 } void CMineGame::RecalcNeighborCount() { for (int r 0; r m_rows; r) { for (int c 0; c m_cols; c) { Cell cell m_board[r * m_cols c]; if (cell.isMine) continue; int count 0; for (int dr -1; dr 1; dr) { for (int dc -1; dc 1; dc) { if (dr 0 dc 0) continue; int nr r dr, nc c dc; if (nr 0 nr m_rows nc 0 nc m_cols) { if (m_board[nr * m_cols nc].isMine) count; } } } cell.neighbor count; } } }上面代碼里while (placed mineCount)用了一個(gè)很常規(guī)的“抽到非雷才計(jì)數(shù)”策略。極端情況下如果雷數(shù)量接近格子總數(shù)后段循環(huán)會(huì)空轉(zhuǎn)但掃雷的雷占比不會(huì)超過50%所以這個(gè)損耗可以忽略。注意rand() % rows存在取模偏差這對(duì)游戲場(chǎng)景完全夠用不用上std::mt19937這么重的方案。布雷完成后還有一個(gè)經(jīng)典需求玩家第一次點(diǎn)擊不能踩雷。常見做法有兩種。第一種是初始化時(shí)不布雷等玩家第一次點(diǎn)擊后把點(diǎn)擊位置周圍3x3排除掉再布雷。第二種是先布雷玩家點(diǎn)擊后如果踩雷把雷挪到別處。我傾向于第二種因?yàn)槠灞P狀態(tài)從初始化那一刻就完整了不會(huì)出現(xiàn)“布雷前數(shù)據(jù)不可用”的尷尬期。挪雷的代碼要排查周圍3x3的格子確保玩家點(diǎn)擊處以及相鄰八格全部沒有雷。3.3 翻開格子的洪水填充遞歸寫法與邊界控制掃雷最核心的交互是翻開格子。如果翻開的是空白格周邊雷數(shù)為0需要自動(dòng)向外擴(kuò)散把連成片的空白區(qū)域全部揭開。這個(gè)動(dòng)作叫洪水填充遞歸是最直觀的寫法void CMineGame::OpenCell(int row, int col) { if (row 0 || row m_rows || col 0 || col m_cols) return; // 越界直接返回 Cell cell m_board[row * m_cols col]; if (cell.isRevealed || cell.isFlagged) return; // 已翻開或被插旗不能點(diǎn) cell.isRevealed true; m_revealedCount; if (cell.isMine) { m_gameOver true; // 踩雷游戲結(jié)束 return; } if (cell.neighbor 0) { // 空白格遞歸翻開周圍8格 for (int dr -1; dr 1; dr) for (int dc -1; dc 1; dc) { if (dr 0 dc 0) continue; OpenCell(row dr, col dc); } } }這段代碼有四個(gè)關(guān)鍵點(diǎn)。第一先標(biāo)記isRevealed再遞歸否則相鄰兩個(gè)空白格會(huì)互相調(diào)用翻個(gè)沒完最終棧溢出。第二遞歸前檢查isFlagged被插旗的格子即使周圍全空也不能翻開這是Windows掃雷的標(biāo)準(zhǔn)行為。第三越界檢查在遞歸入口做保證8個(gè)方向的調(diào)用不用提前判斷。第四整個(gè)遞歸在9x9棋盤上的最大深度不會(huì)超過幾十層不需要擔(dān)心調(diào)用棧但如果哪天做超大棋盤可以改成顯式棧的迭代版本。m_revealedCount每翻開一格就自增它是勝利判定的唯一依據(jù)。翻雷時(shí)雖然也加了一次計(jì)數(shù)但m_gameOver已經(jīng)置位后續(xù)不會(huì)再走勝利判斷。3.4 勝利判定與剩余雷數(shù)統(tǒng)計(jì)狀態(tài)算對(duì)才能交差勝利條件很明確所有非雷格子全部翻開。因?yàn)榭偢褡訑?shù)、雷數(shù)、已翻格數(shù)都是已知量判定只需要一條表達(dá)式bool CMineGame::IsWin() const { // 翻開的格子數(shù) 總格子數(shù) - 雷數(shù) return m_revealedCount m_rows * m_cols - m_mineCount; }這個(gè)表達(dá)式成立的前提是m_revealedCount只在OpenCell里遞增沒有別的地方能偷偷改動(dòng)。如果哪天你加了“右鍵雙擊翻開周圍”的功能一定要確保那個(gè)入口也走OpenCell否則計(jì)數(shù)會(huì)失真。剩余雷數(shù)的計(jì)算則是用總雷數(shù)減去插旗數(shù)。注意這里有個(gè)坑玩家可以把旗插在沒有雷的格子上導(dǎo)致剩余雷數(shù)顯示成負(fù)數(shù)。標(biāo)準(zhǔn)的Windows掃雷允許錯(cuò)誤插旗但要給剩余雷數(shù)加下限保護(hù)int CMineGame::GetRemainingMineCount() const { int flagged 0; for (const Cell cell : m_board) if (cell.isFlagged) flagged; return max(0, m_mineCount - flagged); }處理完這幾塊游戲的“大腦”就完整了完全不依賴MFC也能跑。你甚至可以在黑窗口里寫個(gè)main函數(shù)模擬隨機(jī)點(diǎn)擊測(cè)試幾千次驗(yàn)證不崩潰然后再回來畫界面。這個(gè)習(xí)慣能幫你省下一大半調(diào)試時(shí)間。4. GDI繪制與鼠標(biāo)交互雙緩沖抗閃爍、坐標(biāo)換算別算錯(cuò)4.1 雙緩沖繪制OnPaint里先畫內(nèi)存DC再BitBltMFC窗口的繪制集中在OnPaint這是掃雷里觀感影響最大的一塊。如果你直接在CPaintDC上畫格子拖動(dòng)窗口時(shí)會(huì)看到界面閃爍得厲害因?yàn)槊慨嬕粋€(gè)格子顯示器就刷新一次中間過程全暴露出來了。雙緩沖是標(biāo)準(zhǔn)解法先在內(nèi)存里建一塊和窗口一樣大的畫布把格子全部畫到內(nèi)存再一次拷貝到屏幕。一次拷貝就一次刷新閃爍肉眼基本看不出來void CMainFrame::OnPaint() { CPaintDC dc(this); // 窗口DC最終輸出目標(biāo) CDC memDC; // 內(nèi)存DC CBitmap memBmp; memDC.CreateCompatibleDC(dc); memBmp.CreateCompatibleBitmap(dc, m_width, m_height); CBitmap* pOld memDC.SelectObject(memBmp); // 整塊棋盤畫到內(nèi)存DC memDC.FillSolidRect(0, 0, m_width, m_height, RGB(190, 190, 190)); for (int r 0; r m_game.GetRows(); r) { for (int c 0; c m_game.GetCols(); c) { DrawCell(memDC, r, c); // 每個(gè)格子的具體繪制 } } // 一次性從內(nèi)存拷貝到屏幕 dc.BitBlt(0, 0, m_width, m_height, memDC, 0, 0, SRCCOPY); memDC.SelectObject(pOld); // 恢復(fù)選中的位圖防資源泄漏 }這里CreateCompatibleBitmap創(chuàng)建的位圖要能覆蓋整個(gè)客戶區(qū)所以m_width和m_height要在OnSize里隨窗口大小更新。SelectObject(pOld)那句很多人會(huì)省略短時(shí)間看不出問題但窗口反復(fù)創(chuàng)建銷毀時(shí)GDI對(duì)象會(huì)累積泄漏最終導(dǎo)致繪制異?；蛘叱绦蜃兟B(yǎng)成恢復(fù)原對(duì)象的習(xí)慣很重要。DrawCell里面按格子狀態(tài)畫不同內(nèi)容未翻開畫灰色凸起塊插旗畫小紅旗翻開畫底和數(shù)字。數(shù)字的顏色按neighbor值映射1到8分別對(duì)應(yīng)藍(lán)、綠、紅、深藍(lán)、棕、青、黑、灰這組顏色是Windows掃雷從老版本沿用下來的直接用能讓老玩家一眼覺得“對(duì)味”。4.2 鼠標(biāo)消息映射坐標(biāo)換算和左右鍵狀態(tài)機(jī)鼠標(biāo)處理里最容易翻車的是坐標(biāo)換算。消息回調(diào)拿到的point是客戶區(qū)像素坐標(biāo)而棋盤是行列邏輯坐標(biāo)中間必須經(jīng)過偏移和整除兩步換算void CMainFrame::OnLButtonDown(UINT nFlags, CPoint point) { // point是客戶區(qū)坐標(biāo)先減去棋盤左上角偏移再除以格子邊長(zhǎng) int col (point.x - m_boardLeft) / m_cellSize; int row (point.y - m_boardTop) / m_cellSize; if (!m_game.IsInside(row, col)) return; // 點(diǎn)在棋盤外忽略 if (m_game.IsGameOver()) return; m_game.OpenCell(row, col); UpdateStatusBar(); // 刷新狀態(tài)欄數(shù)字 Invalidate(); // 觸發(fā)重繪 }m_boardLeft和m_boardTop是棋盤左上角在客戶區(qū)里的坐標(biāo)在OnSize或者創(chuàng)建窗口時(shí)算好。如果你忘了減偏移點(diǎn)擊位置會(huì)整體偏移一個(gè)邊距左邊和上邊尤其明顯——點(diǎn)第一個(gè)格子實(shí)際翻的是右邊第二個(gè)這種問題光靠調(diào)試很難一眼看出來直接在紙上畫個(gè)坐標(biāo)系對(duì)比最快。右鍵插旗的處理類似走OnRButtonDown。插旗的邏輯是已翻開的格子不能插旗未翻開的格子如果沒旗就插旗、有旗就去掉旗。再補(bǔ)一個(gè)細(xì)節(jié)右鍵對(duì)已翻開的數(shù)字格在Windows掃雷中會(huì)觸發(fā)“雙擊翻開周圍”這個(gè)放到最后一章說。踩雷之后不能直接結(jié)束要把所有雷的位置都暴露出來讓玩家死得明白。常見做法是在m_gameOver置位后遞歸翻開所有格子或者在繪制階段特殊處理游戲結(jié)束時(shí)強(qiáng)制把所有isMine的格子畫成雷。顯然后者更簡(jiǎn)單也更符合“繪制按狀態(tài)輸出”的原則。4.3 狀態(tài)欄顯示剩余雷數(shù)與用時(shí)SetPaneText的用法網(wǎng)上搜“MFC狀態(tài)欄怎么顯示”答案基本都是圍繞CStatusBar轉(zhuǎn)。掃雷里狀態(tài)欄放兩個(gè)指標(biāo)剩余雷數(shù)和已用時(shí)間。先在MainFrame類里聲明一個(gè)CStatusBar m_wndStatusBar成員然后在OnCreate里初始化static UINT indicators[] { ID_SEPARATOR, // 第一格默認(rèn)拉伸的信息區(qū) ID_INDICATOR_MINE, // 第二格剩余雷數(shù) ID_INDICATOR_TIME, // 第三格計(jì)時(shí) }; m_wndStatusBar.Create(this); m_wndStatusBar.SetIndicators(indicators, 3); // 三個(gè)指示器 m_wndStatusBar.SetPaneInfo(0, ID_SEPARATOR, SBPS_STRETCH, 0); m_wndStatusBar.SetPaneInfo(1, ID_INDICATOR_MINE, SBPS_NORMAL, 80); m_wndStatusBar.SetPaneInfo(2, ID_INDICATOR_TIME, SBPS_NORMAL, 80);SetPaneInfo的第四個(gè)參數(shù)是面板寬度單位是像素。三個(gè)格子一個(gè)拉伸占滿剩余空間兩個(gè)固定寬度這樣無論窗口怎么拉狀態(tài)欄都不會(huì)擠成一團(tuán)。ID_INDICATOR_MINE和ID_INDICATOR_TIME要在資源文件里定義成整數(shù)ID不想動(dòng)資源編輯器的話直接在頭文件里#define ID_INDICATOR_MINE 102也行。刷新時(shí)用SetPaneTextvoid CMainFrame::UpdateStatusBar() { CString str; str.Format(_T(剩余雷數(shù)%d), m_game.GetRemainingMineCount()); m_wndStatusBar.SetPaneText(1, str); str.Format(_T(用時(shí)%d秒), m_elapsedSeconds); m_wndStatusBar.SetPaneText(2, str); }這里SetPaneText第一個(gè)參數(shù)是面板下標(biāo)不是ID。用SetIndicators建立面板后下標(biāo)從0開始數(shù)所以第一個(gè)信息區(qū)是0剩余雷數(shù)是1用時(shí)是2。偶爾有人拿ID傳進(jìn)去顯示不出來還以為是狀態(tài)欄壞了其實(shí)是把下標(biāo)和ID搞混了。5. MFC掃雷常見翻車現(xiàn)場(chǎng)5個(gè)踩坑記錄與排查方法5.1 現(xiàn)象窗口一拖動(dòng)棋盤就錯(cuò)位或者畫不全現(xiàn)象窗口正常打開時(shí)棋盤顯示完整拖動(dòng)改變大小后棋盤邊緣出現(xiàn)白塊或者格子大小沒變但位置歪了。原因OnPaint里用了創(chuàng)建窗口時(shí)算好的固定棋盤尺寸窗口變大后客戶區(qū)變寬但棋盤還是按老尺寸畫的。另一個(gè)常見原因是CS_HREDRAW和CS_VREDRAW窗口樣式?jīng)]有設(shè)置拖動(dòng)窗口時(shí)系統(tǒng)不會(huì)自動(dòng)擦除重繪舊畫面殘留在新位置旁邊。解決在OnSize里根據(jù)當(dāng)前客戶區(qū)重新計(jì)算棋盤偏移和格子大小然后Invalidate()強(qiáng)制重繪。窗口類注冊(cè)時(shí)加上CS_HREDRAW | CS_VREDRAW讓任何尺寸變化都觸發(fā)完整重繪。調(diào)試時(shí)可以在OnSize里用TRACE打印客戶區(qū)寬高對(duì)比點(diǎn)擊坐標(biāo)換算結(jié)果錯(cuò)位問題基本當(dāng)場(chǎng)就能暴露。5.2 現(xiàn)象第一次點(diǎn)擊直接踩雷玩家體驗(yàn)極差現(xiàn)象開局第一次左鍵翻開就是地雷游戲瞬間結(jié)束。有人覺得這是概率問題但實(shí)際玩Windows掃雷多年的人都知道正規(guī)版本第一次點(diǎn)擊永遠(yuǎn)不會(huì)炸。原因布雷發(fā)生在游戲初始化時(shí)玩家第一次點(diǎn)擊沒有做安全保護(hù)點(diǎn)到了隨機(jī)布下的雷上。嚴(yán)格說這不是bug而是設(shè)計(jì)缺失但用戶感知就是翻車。解決見3.2節(jié)布雷后記錄玩家第一次點(diǎn)擊的坐標(biāo)調(diào)用安全化處理把點(diǎn)擊點(diǎn)3x3范圍內(nèi)的所有雷挪到別處。注意挪雷時(shí)要保證目標(biāo)格原本不是雷且不在3x3安全區(qū)內(nèi)否則又會(huì)出現(xiàn)新的問題。5.3 現(xiàn)象界面狂閃眼睛看著難受現(xiàn)象每次點(diǎn)擊或計(jì)時(shí)刷新棋盤跳動(dòng)閃爍尤其是快速連續(xù)點(diǎn)擊時(shí)畫面像在抖。原因直接在CPaintDC上逐個(gè)畫格子每畫一格系統(tǒng)就刷新一次屏幕。Windows對(duì)客戶區(qū)的每次寫入都會(huì)觸發(fā)顯示更新十幾二十個(gè)格子連續(xù)畫中間過程全部暴露觀感就是閃。解決雙緩沖見4.1節(jié)。另外還要做一件事重寫OnEraseBkgnd直接返回TRUE阻止系統(tǒng)用背景色擦除客戶區(qū)。擦除和重繪兩個(gè)動(dòng)作分開中間露出底色也是閃爍的元兇之一BOOL CMainFrame::OnEraseBkgnd(CDC*) { return TRUE; // 禁止擦背景交給OnPaint整體覆蓋 }配合雙緩沖和禁止擦背景閃爍問題根治。如果你發(fā)現(xiàn)還是有輕微閃檢查一下是不是UpdateStatusBar里每次都調(diào)了Invalidate狀態(tài)欄那種局部刷新用RedrawWindow指定區(qū)域更合適。5.4 現(xiàn)象右鍵插旗后剩余雷數(shù)不對(duì)甚至出現(xiàn)負(fù)數(shù)現(xiàn)象玩家在非雷格子上插了一堆旗狀態(tài)欄顯示的剩余雷數(shù)變成負(fù)數(shù)或者游戲明明把雷都標(biāo)出來了卻不判勝利。原因剩余雷數(shù)用“總雷數(shù)減插旗數(shù)”計(jì)算沒有做負(fù)數(shù)保護(hù)勝利判定誤把“插旗數(shù)等于雷數(shù)”當(dāng)成勝利條件而非“所有非雷格子全翻開”。插旗是玩家的猜測(cè)行為不能作為游戲終局依據(jù)。解決剩余雷數(shù)加max(0, ...)保護(hù)見3.4節(jié)的GetRemainingMineCount。勝利判定只用m_revealedCount 總格子數(shù) - 雷數(shù)這一條。插旗錯(cuò)誤提示可以在界面層面處理當(dāng)玩家對(duì)已插旗格子再次右鍵時(shí)去掉旗子不會(huì)影響任何數(shù)值計(jì)算。5.5 現(xiàn)象計(jì)時(shí)器越走越慢或者刷新不及時(shí)現(xiàn)象計(jì)時(shí)開始后狀態(tài)欄的時(shí)間偶爾跳秒甚至卡住幾秒不動(dòng)然后又突然跳好幾秒。原因用了WM_TIMER定時(shí)器在OnTimer里把秒數(shù)累加。WM_TIMER的精度大約15.6毫秒而且消息隊(duì)列忙碌時(shí)會(huì)延遲投遞累加次數(shù)不等于真實(shí)時(shí)間。解決用系統(tǒng)時(shí)間做差值計(jì)算。啟動(dòng)時(shí)記錄GetTickCount64()的值每次刷新顯示(當(dāng)前值 - 起始值) / 1000秒。定時(shí)器只負(fù)責(zé)觸發(fā)刷新不負(fù)責(zé)計(jì)時(shí)void CMainFrame::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent 1 m_game.HasStarted()) { ULONGLONG elapsed GetTickCount64() - m_startTick; int seconds (int)(elapsed / 1000); CString str; str.Format(_T(用時(shí)%d秒), seconds); m_wndStatusBar.SetPaneText(2, str); } CFrameWnd::OnTimer(nIDEvent); }這樣即使定時(shí)器延遲幾秒投遞顯示值依然基于真實(shí)時(shí)間不會(huì)有累計(jì)誤差。6. 把掃雷從“能玩”做到“像樣”自測(cè)模式與按鈕質(zhì)感6.1 用自測(cè)模式跑一萬局驗(yàn)證邏輯不死鎖界面接完第一件事不是反復(fù)手點(diǎn)而是寫一個(gè)自測(cè)入口。把CMineGame單獨(dú)編譯寫一個(gè)不帶MFC的main函數(shù)模擬隨機(jī)點(diǎn)擊、隨機(jī)插旗連續(xù)跑上萬局。統(tǒng)計(jì)有沒有崩潰、有沒有死循環(huán)、有沒有“翻開數(shù)超過了非雷總數(shù)”這類狀態(tài)錯(cuò)亂。這一步能把你邏輯類的隱藏bug全部逼出來// self_test.cpp獨(dú)立于MFC工程可單獨(dú)編譯 #include MineGame.h #include cstdlib #include ctime int main() { srand((unsigned)time(NULL)); for (int round 0; round 10000; round) { CMineGame game; game.InitBoard(9, 9, 10); for (int step 0; step 100; step) { int r rand() % 9, c rand() % 9; game.OpenCell(r, c); if (game.IsGameOver()) break; } // 到這里沒崩沒卡死這一局就通過 } return 0; }這不算什么高深技巧但很多人跳過了這步直接上界面結(jié)果一邊點(diǎn)一邊崩還得通過彈窗去定位問題。邏輯先驗(yàn)證到位再進(jìn)界面省下來的時(shí)間遠(yuǎn)比你想象得多。我當(dāng)年交課設(shè)時(shí)吃過這個(gè)虧后來凡是帶核心算法的小程序都先做自測(cè)這個(gè)習(xí)慣一直保留到現(xiàn)在。6.2 讓未翻開的格子有凸起感DrawEdge畫出經(jīng)典按鈕質(zhì)感最后一個(gè)小技巧用DrawEdge畫未翻開的格子能立刻讓畫面接近Windows經(jīng)典掃雷的觀感void CMainFrame::DrawCell(CDC dc, int row, int col) { CRect rc( m_boardLeft col * m_cellSize, m_boardTop row * m_cellSize, m_boardLeft (col 1) * m_cellSize, m_boardTop (row 1) * m_cellSize); if (!m_game.IsRevealed(row, col)) { // 未翻開畫凸起邊框模擬按鈕質(zhì)感 dc.DrawEdge(rc, EDGE_RAISED, BF_RECT); } else { // 翻開畫凹陷邊框 dc.DrawEdge(rc, EDGE_SUNKEN, BF_RECT); // 有數(shù)字畫數(shù)字是雷畫雷 } }EDGE_RAISED和EDGE_SUNKEN是DrawEdge的經(jīng)典組合一個(gè)凸一個(gè)凹視覺上不用顏色就能區(qū)分翻開和未翻開。到這里你的MFC掃雷從邏輯、繪制到狀態(tài)欄已經(jīng)是一個(gè)完整的作品再往后就是加雷區(qū)右鍵雙擊翻開、掃雷排行榜存檔這些錦上添花的功能了。我做這類小工程最大的感觸是MFC的坑大多不是框架本身的坑而是對(duì)消息機(jī)制和繪制時(shí)序理解不透導(dǎo)致的。把窗口當(dāng)成“消息驅(qū)動(dòng)的一個(gè)狀態(tài)機(jī)”把算法和界面拆開幾乎八成問題都能在設(shè)計(jì)階段規(guī)避。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取