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