简介这份资源是开发者卢山基于C#与MVC框架实现的联机扫雷游戏项目源码适合正在学习C#编程、MVC架构与网络应用开发的学生和初学者用于理解如何将面向对象语言与Web分层模式落地到实际游戏项目中。压缩包共103个文件约2.16MB以cs源代码、config配置、xaml界面、png/jpg/bmp图片资源及dll、exe程序集为主另含csproj、sln工程文件与svc、wsdl等网络服务描述文件覆盖模型、视图、控制器三层结构。已有151人学习下载。项目将扫雷规则、雷区生成与胜负判定交由模型处理视图负责雷区展示与标记交互控制器接收点击操作并与服务端通信可帮助读者掌握实时同步、数据库记录存储与界面动态渲染等实现思路是研究C#网络游戏开发的完整参考案例。1. 联机扫雷游戏源码拆解C# MVC 架构下的网络对战实现一份名为「联机扫雷游戏_卢山_1510243249_C#mvc」的源码包文件名里塞满了ClientWindow.baml、App.baml、MainWindow.baml、ButtonStyle.baml这类 WPF 标记编译产物同时挂着 C# 和 MVC 两个标签。很多人第一反应是「扫雷不是单机小游戏吗怎么还联机」但恰恰是「联机」两个字让这份代码有了拆的价值——它把扫雷从单机逻辑题变成了一个需要处理网络通信、状态同步、多客户端协调的小型分布式系统。这份资源适合正在学 C# 网络编程、想找一个完整可运行项目练手的开发者也适合教.NET 课程的老师拿去做课程设计参考。它不教你扫雷规则它给你看的是一个真实项目怎么把 WPF 客户端、MVC 服务端和网络协议串起来。2. 从 baml 文件反推 WPF 客户端结构视图层到底怎么组织的2.1 baml 文件是什么为什么源码包里全是它ClientWindow.baml、App.baml、MainWindow.baml、ButtonStyle.baml、MyMessageBox.baml——这些.baml文件是 WPF 中 XAML 编译后的二进制标记语言文件。你写的是.xamlVisual Studio 在编译时把它压成.baml嵌进程序集。源码包里出现这些文件说明项目已经经过至少一次编译压缩包里的内容可能是obj或bin目录的残留也可能是作者直接把编译产物一起打包了。这对想学习的开发者其实是个好消息你可以通过反编译工具比如 ILSpy 或 dotPeek把.baml还原成可读的 XAML直接看到界面布局和控件树。常见做法是先用 ILSpy 打开Client.exe或Client.dll找到对应的.baml资源右键导出为.xaml。还原出来的MainWindow.xaml里通常能看到Grid布局、Button矩阵、TextBlock状态栏这些扫雷界面的标准元素。ButtonStyle.baml单独存在说明作者把按钮样式抽成了独立资源字典。这是 WPF 里很常规的做法——把Style定义在ResourceDictionary里然后在App.xaml中通过MergedDictionaries合并。好处是换肤或者调整格子外观时不用改主窗口代码。MyMessageBox.baml则暗示作者没有直接用系统自带的MessageBox而是自定义了一个弹窗控件可能是为了统一风格或者支持非阻塞提示。2.2 从 App.baml 看应用启动流程与 MVC 的对应关系App.baml对应的是App.xaml里面定义了Application的启动入口和全局资源。在 WPF 里App.xaml的StartupUri属性决定第一个显示的窗口。如果项目是 MVC 架构那App.xaml.cs里很可能在OnStartup方法中做了控制器初始化或者服务端连接的前置操作。我一般会这样去还原启动逻辑先反编译App.baml得到 XAML看StartupUri指向哪个窗口再反编译App.xaml.cs对应的 IL看OnStartup里有没有new Controller()或者TcpClient.Connect()之类的调用。如果看到DispatcherUnhandledException的事件绑定说明作者做了全局异常捕获这对联机游戏很重要——网络断了不能让整个客户端崩掉。MVC 在 WPF 客户端里的落地方式跟 Web 端不太一样。Web 里Controller处理 HTTP 请求返回ActionResult但在 WPF 里Controller更像是一个协调器它持有Model的引用监听View的事件然后把状态变更推回View。比如扫雷里点击一个格子View触发Button_ClickController收到坐标后调用Model.RevealCell(x, y)Model算完返回结果Controller再通知View更新那个格子的显示。这套流程在MainWindow.baml对应的代码里应该能找到痕迹。2.3 客户端与服务端的通信边界在哪里联机扫雷的核心问题是哪些逻辑放客户端哪些放服务端。从文件列表看客户端有独立的Client.csproj说明至少有两个项目——一个客户端、一个服务端。服务端大概率是 ASP.NET MVC 项目用Controller暴露 HTTP 接口或者 WebSocket 端点。常见做法是服务端负责权威游戏状态雷区生成、点击判定、胜负裁决都在服务端完成客户端只负责渲染和发送操作指令。这样做的好处是防作弊——如果雷区在客户端生成玩家改内存就能看到所有雷的位置。但代价是每次点击都要等服务器响应网络延迟直接影响操作手感。另一种做法是客户端生成雷区把雷区种子发给服务端服务端用同样的种子复现雷区。这样点击判定可以在本地做响应快但需要保证种子同步和随机算法一致。从这份源码的文件结构看ClientWindow和MainWindow都在客户端服务端代码没有出现在文件列表里所以具体用了哪种方案需要解压后看服务端项目的GameController或GameHub才能确定。提示如果你反编译后发现客户端里有完整的雷区生成逻辑那大概率是客户端权威模式如果客户端只有渲染代码所有判定都走网络请求那就是服务端权威模式。3. 把 MVC 模式套进扫雷Model、View、Controller 各自管什么3.1 Model 层雷区生成、状态机与数据契约扫雷的 Model 层至少要管三件事雷区数据结构、游戏状态流转、以及跟服务端交换的数据格式。雷区数据结构常见的是二维数组或一维数组加索引计算。用 C# 的话int[,]或者Cell[,]都行Cell是个自定义类包含IsMine、IsRevealed、AdjacentMines三个属性。雷区生成用随机数把指定数量的雷撒进去然后遍历每个非雷格子算周围八格的地雷数。这部分逻辑不复杂但要注意边界处理——四个角和四条边的相邻格子数量跟中间不一样循环时下标别越界。游戏状态机一般有Waiting、Playing、Won、Lost四个状态。状态流转由 Controller 触发但状态本身存在 Model 里。联机模式下状态变更需要同步给所有玩家所以 Model 里通常还会有一个Version或Timestamp字段用来解决并发操作时的冲突。数据契约是联机游戏里容易翻车的地方。客户端和服务端之间传什么至少要有玩家 ID、操作类型左键翻开/右键标记、坐标、当前回合号。如果用 JSON 序列化C# 里常见的是System.Text.Json或者Newtonsoft.Json。定义 DTO 的时候记得加[Serializable]或者用record类型避免序列化时丢字段。// Model 层核心数据结构示例 public class Cell { public bool IsMine { get; set; } public bool IsRevealed { get; set; } public bool IsFlagged { get; set; } public int AdjacentMines { get; set; } } public class GameModel { public Cell[,] Board { get; private set; } public int Rows { get; private set; } public int Cols { get; private set; } public int MineCount { get; private set; } public GameState State { get; set; } public int Version { get; set; } // 用于并发控制 public GameModel(int rows, int cols, int mines) { Rows rows; Cols cols; MineCount mines; Board new Cell[rows, cols]; InitializeBoard(); } private void InitializeBoard() { // 初始化所有格子 for (int i 0; i Rows; i) for (int j 0; j Cols; j) Board[i, j] new Cell(); // 随机撒雷用 Random 或 RNGCryptoServiceProvider var rand new Random(); int placed 0; while (placed MineCount) { int r rand.Next(Rows); int c rand.Next(Cols); if (!Board[r, c].IsMine) { Board[r, c].IsMine true; placed; } } // 计算相邻雷数 for (int i 0; i Rows; i) for (int j 0; j Cols; j) Board[i, j].AdjacentMines CountAdjacentMines(i, j); } private int CountAdjacentMines(int row, int col) { 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 row dr, nc col dc; if (nr 0 nr Rows nc 0 nc Cols Board[nr, nc].IsMine) count; } return count; } }上面这段代码里InitializeBoard先建格子再撒雷最后算相邻数顺序不能反。CountAdjacentMines用双重循环遍历八方向dr和dc从 -1 到 1跳过 (0,0)然后检查边界。参数rows、cols、mines一般从配置文件或服务端下发联机模式下服务端应该校验mines不超过rows * cols - 1否则会死循环。3.2 View 层WPF 界面与数据绑定View 层在 WPF 里就是 XAML 加少量代码隐藏。扫雷界面通常是一个UniformGrid或者Grid动态生成按钮矩阵。每个按钮对应一个Cell按钮的Content绑定到AdjacentMinesBackground绑定到IsRevealed的状态。数据绑定是 WPF 的强项但也是新手容易踩坑的地方。Cell类需要实现INotifyPropertyChanged接口否则属性变了界面不会更新。联机模式下服务端推来的状态变更要在 UI 线程上执行不然会抛InvalidOperationException。常见做法是用Dispatcher.Invoke或者SynchronizationContext把更新操作切回 UI 线程。// View 层动态生成按钮矩阵并绑定 private void BuildBoard(GameModel model) { BoardGrid.Children.Clear(); BoardGrid.Rows model.Rows; BoardGrid.Columns model.Cols; for (int i 0; i model.Rows; i) { for (int j 0; j model.Cols; j) { var btn new Button { Width 30, Height 30, Tag new Point(i, j), // 存坐标 Style (Style)FindResource(CellButtonStyle) }; btn.Click Cell_Click; btn.MouseRightButtonUp Cell_RightClick; BoardGrid.Children.Add(btn); } } } private void Cell_Click(object sender, RoutedEventArgs e) { var btn sender as Button; var pt (Point)btn.Tag; // 通知 Controller 处理点击 _controller.HandleReveal((int)pt.X, (int)pt.Y); }BuildBoard里用Tag存坐标是常见技巧比用Name拼接字符串再解析要干净。CellButtonStyle从资源字典里取对应之前看到的ButtonStyle.baml。Cell_Click不直接改 Model而是调_controller.HandleReveal这就是 MVC 里 View 不碰 Model 的约束。3.3 Controller 层输入分发与网络消息路由Controller 在联机扫雷里要做两件事把本地用户操作转成网络消息发出去以及把服务端推来的消息转成 Model 更新和 View 刷新。本地操作包括左键翻开、右键标记、双击快速展开如果实现了的话。每个操作都要带上玩家 ID、坐标、操作类型和时间戳。时间戳用于服务端排序防止网络乱序导致状态错乱。网络消息路由一般用一个switch或者字典分发。消息类型至少有PlayerJoin、PlayerLeave、CellReveal、CellFlag、GameOver、StateSync。StateSync是全量状态同步用于新玩家加入或者断线重连。增量同步只发变更的格子省带宽但逻辑复杂。// Controller 层处理本地点击并发送网络消息 public class GameController { private GameModel _model; private IGameClient _client; // 网络客户端接口 public void HandleReveal(int row, int col) { if (_model.State ! GameState.Playing) return; if (_model.Board[row, col].IsRevealed) return; // 构造消息 var msg new GameMessage { Type MessageType.CellReveal, PlayerId _client.PlayerId, Row row, Col col, Version _model.Version }; // 发送到服务端等待确认后再更新本地 Model _client.Send(msg); } // 收到服务端广播后调用 public void OnCellRevealed(int row, int col, int adjacentMines) { _model.Board[row, col].IsRevealed true; _model.Board[row, col].AdjacentMines adjacentMines; _model.Version; // 通知 View 更新 ViewUpdated?.Invoke(row, col); } }HandleReveal里先做本地校验避免无效请求发到服务端。Version字段用于乐观并发控制——如果服务端收到的Version跟当前不一致说明有并发操作需要拒绝或合并。OnCellRevealed是服务端确认后的回调更新 Model 并触发 View 刷新事件。注意联机模式下不要在本地点击后立即更新 UI否则服务端拒绝时会出现「翻开了又弹回去」的诡异现象。等确认再更新用户体验反而更一致。4. 联机通信的避坑与排查从 TCP 粘包到 UI 线程崩溃4.1 现象客户端点击后格子没反应日志显示消息已发送原因通常是服务端没有广播回来或者广播回来了但客户端没解析对。先查服务端的GameHub或GameController有没有把消息转发给所有玩家。如果服务端日志显示已广播那问题在客户端接收端——可能是消息格式不匹配比如服务端发的是 JSON 但客户端按二进制解析。解决在客户端接收回调里加日志把原始字节数组或字符串打出来。对比服务端发送时的序列化格式确认字段名和类型一致。常见坑是DateTime序列化格式不同或者enum被序列化成数字但客户端按字符串解析。4.2 现象多个玩家同时点击同一格子状态不一致原因是没有做并发控制。两个玩家同时翻开同一个格子服务端如果直接处理两个请求可能一个成功一个失败但失败的那个客户端已经本地更新了 UI。解决服务端用Version或Timestamp做乐观锁。每个操作请求带上客户端当前的Version服务端比对不一致就拒绝并返回最新状态。客户端收到拒绝后回滚本地 UI用服务端返回的状态覆盖。4.3 现象游戏运行一段时间后客户端卡死或抛InvalidOperationException原因是网络回调在非 UI 线程上直接改了 WPF 控件的属性。WPF 要求所有 UI 操作必须在 UI 线程上执行网络库的回调线程通常是后台线程。解决在 Controller 里把 Model 更新和 View 刷新分开。Model 更新可以在后台线程做但触发 View 刷新时必须切回 UI 线程。用Application.Current.Dispatcher.Invoke或者SynchronizationContext.Post。// 错误做法直接在网络回调里改 UI private void OnNetworkMessage(GameMessage msg) { // 这行会抛异常因为不在 UI 线程 BoardGrid.Children[msg.Row * _model.Cols msg.Col].Background Brushes.White; } // 正确做法切回 UI 线程 private void OnNetworkMessage(GameMessage msg) { Application.Current.Dispatcher.Invoke(() { var btn (Button)BoardGrid.Children[msg.Row * _model.Cols msg.Col]; btn.Background Brushes.White; btn.Content msg.AdjacentMines 0 ? msg.AdjacentMines.ToString() : ; }); }4.4 现象TCP 连接下消息粘包一次收到多条消息或半条消息原因TCP 是字节流协议不保证消息边界。发送方连续发两条消息接收方可能一次收到两条拼在一起也可能一条消息分两次收到。解决定义消息头包含消息长度。接收方先读固定长度的头解析出消息体长度再读对应长度的字节。常见做法是用BitConverter处理 4 字节的int长度头。// 发送先发长度再发内容 byte[] body Encoding.UTF8.GetBytes(json); byte[] header BitConverter.GetBytes(body.Length); stream.Write(header, 0, 4); stream.Write(body, 0, body.Length); // 接收先读 4 字节长度再读内容 byte[] header new byte[4]; int read 0; while (read 4) read stream.Read(header, read, 4 - read); int length BitConverter.ToInt32(header, 0); byte[] body new byte[length]; read 0; while (read length) read stream.Read(body, read, length - read); string json Encoding.UTF8.GetString(body);4.5 现象服务端重启后客户端无法重连必须手动重启原因客户端没有实现断线重连逻辑或者重连时没有重新同步游戏状态。解决在客户端加一个心跳检测每隔几秒发一个Ping服务端回Pong。连续几次没收到Pong就触发重连。重连成功后先请求StateSync用服务端返回的全量状态覆盖本地 Model再刷新 UI。提示心跳间隔别设太短2 到 5 秒比较合适。太短会增加无谓的网络流量太长则断线发现不及时。5. 进阶技巧用状态快照和回放验证联机同步的正确性联机游戏最难测的就是同步正确性。你没法同时盯着两个客户端看它们状态是否一致靠肉眼比对格子颜色效率太低。我一般会加一个状态快照机制每次 Model 变更后把整个雷区序列化成一个紧凑的字符串比如每格用 0-9 表示未翻开、A-F 表示已翻开且相邻雷数、M 表示雷、F 表示旗子存到一个列表里。游戏结束后把两个客户端的快照列表拉出来逐帧比对哪一帧开始不一致问题就出在那个操作上。这个技巧在调试「偶现不同步」时特别管用。因为不同步往往是特定操作序列触发的比如「A 玩家翻开格子后 B 玩家立即标记同一格子」靠手动复现很难但有了快照就能精确定位。// 状态快照把 Model 序列化成紧凑字符串 public string TakeSnapshot() { var sb new StringBuilder(); for (int i 0; i Rows; i) { for (int j 0; j Cols; j) { var cell Board[i, j]; if (cell.IsFlagged) sb.Append(F); else if (!cell.IsRevealed) sb.Append(?); else if (cell.IsMine) sb.Append(M); else sb.Append(cell.AdjacentMines.ToString()); } sb.Append(|); // 行分隔符 } return sb.ToString(); } // 比对两个快照 public static int FindFirstDiff(string snapA, string snapB) { int len Math.Min(snapA.Length, snapB.Length); for (int i 0; i len; i) if (snapA[i] ! snapB[i]) return i; return snapA.Length snapB.Length ? -1 : len; }TakeSnapshot用?表示未翻开、F表示旗子、M表示雷、数字表示已翻开格子的相邻雷数。行之间用|分隔方便定位是第几行第几列出问题。FindFirstDiff返回第一个不一致的字符位置换算成行列就能知道是哪个格子。另一个实用技巧是操作日志回放。把每个玩家的操作按时间戳记下来格式是[timestamp] [playerId] [action] [row] [col]。测试时把日志喂给一个模拟客户端让它按顺序重放操作观察最终状态是否跟真实客户端一致。这能发现时序相关的 bug比如两个操作在毫秒级间隔内到达服务端时处理顺序不确定导致的状态分叉。我现在的习惯是任何联机项目先把快照和操作日志加上再开始写游戏逻辑。看起来多花了半小时但后面省下的调试时间至少是十倍。有一次做一个五子棋联机就是靠快照比对发现服务端在「平局判定」时少同步了一个标志位导致两个客户端一个显示平局一个显示继续下。这种 bug 靠肉眼根本看不出来。希望帮到你。本文还有配套的精品资源点击获取
