C#联机扫雷实战：TCP协议、MVC分层与断线重连

简介这份资源是开发者卢山基于C#与MVC框架实现的联机扫雷游戏项目源码适合正在学习C#编程、MVC架构与网络应用开发的学生和初学者用于理解桌面端与在线多人对战游戏的完整实现思路。压缩包共103个文件约2.16MB以cs源代码、config配置、xaml界面、png/jpg/bmp图片资源及dll、exe程序集为主另含csproj工程文件、sln解决方案、wsdl与svc服务描述等覆盖客户端界面、服务通信与资源编译多个层面。已有151人学习下载。项目将扫雷规则、雷区生成与胜负判定交由模型处理视图负责雷区展示与标记交互控制器承接点击输入并与服务器同步可帮助读者掌握MVC分层组织、实时通信与游戏逻辑的落地方式是研究C#网络游戏开发的实用案例。1. 联机扫雷从单机逻辑到 MVC 分层一个 C# 练手项目的真实价值单机扫雷谁都会写一个二维数组加递归展开就完事。但一旦加上「联机」两个字问题立刻从算法题变成工程题两个客户端怎么同步棋盘状态、点击事件怎么广播、服务端怎么防止重复开局、断线重连后棋盘怎么恢复。这个标题里的 C# 和 MVC 不是装饰它们决定了你用什么姿势拆解这些麻烦。C# 负责网络层和数据结构MVC 负责把「棋盘数据」「界面渲染」「点击控制」三件事彻底分开否则联机逻辑和 UI 代码搅在一起改一个格子状态要翻三个文件。这篇笔记面向已经会写基础 C#、想拿一个完整项目练手 MVC 分层和 Socket 通信的开发者也适合被「联机」二字卡住、不知道从哪下手的新手。我会按真实落地顺序讲先定通信协议再搭 MVC 骨架然后写服务端房间管理最后处理那些让你半夜爬起来改代码的坑。2. 通信协议先定死TCP 粘包、消息类型与棋盘序列化联机扫雷翻车最多的不是游戏逻辑是通信。两个客户端各自跑得好好的一连上就出现「对方点了格子我这边没反应」「开局棋盘不一样」「点快了直接卡死」。根因几乎都指向同一件事协议没定清楚就开始写业务代码。这一章先把通信层的地基打牢后面 MVC 才有东西可分层。2.1 为什么选 TCP 而不是 UDP以及粘包到底怎么处理扫雷是回合制、低频、要求可靠的操作一次点击必须到达且只到达一次。UDP 省的那点延迟对扫雷毫无意义丢一个「翻开格子」的消息就可能导致两边棋盘永久不一致。所以常见做法是 TCPC# 里用TcpListenerTcpClient就够了不需要上任何第三方网络库。但 TCP 是字节流没有消息边界。你发两次「点击(3,4)」和「点击(5,6)」接收端可能一次收到两段拼在一起的字节也可能一段被拆成两次收到。这就是粘包和拆包。血泪经验是不要试图用Thread.Sleep或「发完等一下」来绕过必须定长度前缀协议。我一般用「4 字节消息体长度 消息体」的格式。消息体本身用固定结构1 字节消息类型 N 字节负载。下面是最小可用的收发封装// 消息类型枚举前后端必须一致 public enum MsgType : byte { JoinRoom 1, // 加入房间 GameStart 2, // 游戏开始附带棋盘种子 Reveal 3, // 翻开格子 x,y Flag 4, // 插旗 x,y GameOver 5, // 游戏结束 SyncBoard 6 // 全量棋盘同步重连用 } // 发送先写4字节长度再写类型和负载 public static void Send(NetworkStream stream, MsgType type, byte[] payload) { payload ?? Array.Emptybyte(); int totalLen 1 payload.Length; // 类型占1字节 byte[] header BitConverter.GetBytes(totalLen); // 小端序两端统一 stream.Write(header, 0, 4); stream.WriteByte((byte)type); if (payload.Length 0) stream.Write(payload, 0, payload.Length); stream.Flush(); } // 接收先读满4字节长度再按长度读满消息体 public static (MsgType type, byte[] payload) Receive(NetworkStream stream) { byte[] lenBuf ReadExactly(stream, 4); int totalLen BitConverter.ToInt32(lenBuf, 0); byte[] body ReadExactly(stream, totalLen); MsgType type (MsgType)body[0]; byte[] payload body.Skip(1).ToArray(); return (type, payload); } // 关键必须循环读直到读满指定字节数不能假设一次Read就够 private static byte[] ReadExactly(NetworkStream stream, int count) { byte[] buffer new byte[count]; int offset 0; while (offset count) { int read stream.Read(buffer, offset, count - offset); if (read 0) throw new IOException(连接已关闭); offset read; } return buffer; }逻辑说明Send先算总长度类型字节加负载把长度写成 4 字节小端整数再依次写类型和负载。Receive反过来先精确读 4 字节拿到长度再精确读满整个消息体。ReadExactly是核心它循环调用Read直到凑够字节数这是解决拆包的唯一正确姿势。参数说明长度用int4 字节足够单条消息不会超过 2GB字节序两端必须统一C# 的BitConverter默认小端如果以后接其他语言客户端要显式约定payload允许为空比如GameStart的负载可以只放一个随机种子。2.2 棋盘怎么序列化种子同步比传整个数组更省事新手最容易犯的错是服务端生成完整棋盘然后把整个二维数组序列化发给每个客户端。这有两个问题一是消息大二是后续每次状态变化都要同步全量容易不一致。更稳的做法是「种子 操作日志」。服务端只生成一个随机种子用同一个种子在两端各自生成完全相同的雷区布局。之后所有操作翻开、插旗都作为增量消息广播。这样GameStart的负载只有 4 字节种子Reveal的负载只有 2 字节坐标。// 用种子生成雷区两端算法必须完全一致 public static bool[,] GenerateMines(int rows, int cols, int mineCount, int seed) { var rng new Random(seed); // 同一个种子序列完全相同 bool[,] mines new bool[rows, cols]; int placed 0; while (placed mineCount) { int r rng.Next(rows); int c rng.Next(cols); if (!mines[r, c]) // 避免重复放置 { mines[r, c] true; placed; } } return mines; } // 坐标打包成2字节负载 public static byte[] PackCoord(int x, int y) { return new byte[] { (byte)x, (byte)y }; // 棋盘不超过255x255时够用 }逻辑说明GenerateMines用Random(seed)保证两端拿到同一串随机数放置逻辑完全一致结果必然相同。PackCoord把坐标压成 2 字节因为扫雷棋盘通常不超过 30x30单字节足够。参数说明seed由服务端生成后通过GameStart下发mineCount和棋盘尺寸必须在开局前由服务端统一广播不能各客户端自己定否则种子相同但参数不同照样对不上。提示如果你以后想加「回放」功能操作日志天然就是回放数据这是种子方案附赠的好处。3. MVC 骨架怎么搭把棋盘数据、渲染、控制彻底拆开协议定完接下来是结构。很多人写 C# 桌面或 Web 扫雷习惯把按钮点击、格子状态、网络收发全塞进一个 Form 或一个 Controller 里几百行之后自己都看不懂。MVC 在这里不是学院派教条而是让你在加联机逻辑时不用推倒重来。这一章讲清楚三层各自该放什么以及联机场景下 Controller 和 Model 的边界在哪。3.1 Model 层棋盘状态与游戏规则不碰任何 UI 和网络Model 只做一件事维护棋盘数据提供翻开、插旗、判断胜负的方法。它不知道有网络也不知道有按钮。这样你才能单独对它写单元测试也才能在服务端和客户端复用同一份规则代码。public class BoardModel { public int Rows { get; } public int Cols { get; } public CellState[,] Cells { get; private set; } public bool IsGameOver { get; private set; } public bool IsWin { get; private set; } private readonly bool[,] _mines; private int _revealedCount; private readonly int _totalSafeCells; public BoardModel(int rows, int cols, int mineCount, int seed) { Rows rows; Cols cols; _mines GenerateMines(rows, cols, mineCount, seed); Cells new CellState[rows, cols]; _totalSafeCells rows * cols - mineCount; } // 翻开格子返回本次实际翻开的坐标列表用于广播 public List(int x, int y) Reveal(int x, int y) { var opened new List(int, int)(); if (IsGameOver || !InBounds(x, y)) return opened; if (Cells[x, y] ! CellState.Hidden) return opened; if (_mines[x, y]) { Cells[x, y] CellState.Mine; IsGameOver true; return opened; // 踩雷游戏结束 } FloodFill(x, y, opened); // 空白区域递归展开 if (_revealedCount _totalSafeCells) { IsWin true; IsGameOver true; } return opened; } private void FloodFill(int x, int y, List(int, int) opened) { if (!InBounds(x, y) || Cells[x, y] ! CellState.Hidden) return; if (_mines[x, y]) return; int adjacent CountAdjacentMines(x, y); Cells[x, y] adjacent 0 ? CellState.Empty : (CellState)adjacent; opened.Add((x, y)); _revealedCount; if (adjacent 0) // 只有空白格才继续扩散 { for (int dx -1; dx 1; dx) for (int dy -1; dy 1; dy) if (dx ! 0 || dy ! 0) FloodFill(x dx, y dy, opened); } } private bool InBounds(int x, int y) x 0 x Rows y 0 y Cols; private int CountAdjacentMines(int x, int y) { /* 统计周围8格雷数 */ return 0; } } public enum CellState : byte { Hidden 0, Empty 1, Num1 2, Num2 3, Num3 4, Num4 5, Num5 6, Num6 7, Num7 8, Num8 9, Flag 10, Mine 11 }逻辑说明Reveal返回本次实际翻开的坐标列表这个设计是为联机服务的——客户端本地翻开后把返回的列表发给服务端服务端广播给对手对手按坐标逐个更新自己的 Model。FloodFill只在空白格继续扩散数字格停止这是扫雷的标准展开规则。参数说明CellState用byte枚举方便直接序列化进网络消息_revealedCount用于判断胜利等于安全格总数即获胜Reveal对已翻开的格子直接返回空列表天然幂等能挡住重复点击。3.2 Controller 层接收输入、调用 Model、驱动网络Controller 是粘合剂。它接收 UI 的点击事件调用 Model 的Reveal拿到结果后一方面通知 View 刷新另一方面通过Send把操作发给服务端。联机场景下 Controller 还要处理「收到对手操作」的入口把对手的坐标应用到本地 Model。public class GameController { private readonly BoardModel _model; private readonly NetworkStream _stream; private readonly IGameView _view; public GameController(BoardModel model, NetworkStream stream, IGameView view) { _model model; _stream stream; _view view; } // 本地玩家点击格子 public void OnCellClicked(int x, int y) { if (_model.IsGameOver) return; var opened _model.Reveal(x, y); if (opened.Count 0) return; // 无效操作不广播 _view.Refresh(_model); // 先刷新本地 NetworkHelper.Send(_stream, MsgType.Reveal, PackCoord(x, y)); // 再广播 } // 收到对手的操作 public void OnRemoteReveal(int x, int y) { _model.Reveal(x, y); _view.Refresh(_model); } }逻辑说明OnCellClicked先本地执行成功才广播避免把无效操作发给对手造成状态分叉。OnRemoteReveal只更新 Model 和 View不再回发网络否则会形成消息回环。参数说明IGameView是接口桌面端用 WinForms 实现Web 端用 Razor 或前端 JS 实现Controller 不关心具体渲染方式_stream是当前连接的NetworkStream由连接建立后注入。注意Controller 里不要写任何Thread.Sleep或阻塞等待对手响应的代码联机是异步的阻塞会让整个 UI 卡死。4. 服务端房间管理TcpListener 多客户端与开局同步客户端能单机跑通后联机的一半工作量在服务端。服务端要管房间、配对两个玩家、生成种子、广播开局、转发操作。这一章讲一个最小可用的房间管理实现以及TcpListener处理多客户端时最容易踩的线程问题。4.1 用 TcpListener 接受多客户端每个连接一个处理线程TcpListener本身只负责接受连接接受之后必须把每个TcpClient交给独立线程或任务处理否则一个客户端的阻塞读会卡住其他所有客户端。常见做法是AcceptTcpClient循环加Task.Run。public class GameServer { private readonly TcpListener _listener; private readonly ListRoom _rooms new(); private readonly object _lock new(); // 保护 _rooms 的并发访问 public GameServer(int port) { _listener new TcpListener(IPAddress.Any, port); } public async Task StartAsync() { _listener.Start(); while (true) { TcpClient client await _listener.AcceptTcpClientAsync(); _ Task.Run(() HandleClient(client)); // 每个客户端独立任务 } } private void HandleClient(TcpClient client) { using var stream client.GetStream(); try { while (true) { var (type, payload) NetworkHelper.Receive(stream); Dispatch(client, type, payload); } } catch (IOException) { // 客户端断开从房间移除 RemoveFromRoom(client); } } private void Dispatch(TcpClient client, MsgType type, byte[] payload) { switch (type) { case MsgType.JoinRoom: lock (_lock) { AssignRoom(client); } break; case MsgType.Reveal: BroadcastToRoom(client, MsgType.Reveal, payload); break; // 其他类型同理 } } }逻辑说明StartAsync只负责接受连接每个连接丢进Task.Run独立处理这样多个客户端互不阻塞。HandleClient里是标准的「收消息-分发」循环连接断开时捕获IOException清理房间。Dispatch按消息类型路由JoinRoom涉及共享的_rooms列表必须加锁。参数说明IPAddress.Any表示监听所有网卡局域网联机够用_lock只保护房间列表的增删不要锁住整个消息处理否则并发性能会退化BroadcastToRoom需要遍历房间内除发送者外的所有客户端逐个Send。4.2 开局同步两个玩家都就绪才发种子开局最容易出的问题是「一个玩家已经看到棋盘另一个还在等」。正确流程是两个玩家都发JoinRoom后服务端生成种子同时给两人发GameStart负载里带上种子、棋盘尺寸、雷数。两人收到后各自用相同参数生成棋盘此时才允许点击。private void TryStartGame(Room room) { if (room.Players.Count ! 2) return; // 人没齐不开 if (room.Started) return; // 防止重复开局 room.Started true; int seed new Random().Next(); // 服务端统一生成种子 byte[] payload BuildStartPayload(seed, room.Rows, room.Cols, room.MineCount); foreach (var player in room.Players) NetworkHelper.Send(player.Stream, MsgType.GameStart, payload); } private byte[] BuildStartPayload(int seed, int rows, int cols, int mines) { // 4字节种子 1字节行 1字节列 1字节雷数 var buf new byte[7]; BitConverter.GetBytes(seed).CopyTo(buf, 0); buf[4] (byte)rows; buf[5] (byte)cols; buf[6] (byte)mines; return buf; }逻辑说明TryStartGame用Started标志位挡住重复开局这是防止「接口快速提交」类问题的通用手段——服务端必须对状态变更做幂等保护不能信任客户端只发一次。种子由服务端生成保证两端一致。参数说明BuildStartPayload把种子和棋盘参数打包成 7 字节客户端按同样顺序解析rows、cols、mines用单字节棋盘不超过 255 时够用超过要改成 2 字节。提示如果要做「防止接口快速提交」除了服务端Started标志客户端点击后也应立即禁用按钮双保险。5. 联机扫雷避坑排查那些让你怀疑人生的五个问题前面把正常流程走通了但真实联机环境里翻车往往发生在边界情况。这一章是我自己踩过的五个坑每个都按「现象 → 原因 → 解决」写清楚你遇到时可以直接对号入座。5.1 现象两边棋盘不一样对手翻开的格子和自己看到的不同原因种子同步了但棋盘参数没同步。常见情况是客户端各自硬编码了rows、cols、mineCount服务端下发的种子虽然一样但用不同参数生成的雷区完全不同。另一个隐蔽原因是Random的放置算法两端实现有细微差异比如循环顺序不同。解决所有棋盘参数必须由服务端在GameStart里统一下发客户端禁止硬编码。放置雷的算法要抽成两端共用的同一份代码最好直接共享源文件或做成类库不要各写一遍。5.2 现象点快了对手收到重复操作或者自己这边状态错乱原因客户端没有对已翻开的格子做幂等判断快速双击同一个格子会发两次Reveal。服务端如果只是无脑转发对手会收到两次相同坐标。解决Model 的Reveal对非Hidden状态直接返回空列表Controller 判断返回列表为空就不广播。服务端也可以做一层去重但客户端幂等是根本。5.3 现象一个客户端断开后另一个客户端卡死或崩溃原因BroadcastToRoom遍历玩家列表时某个NetworkStream已经断开Write抛异常如果没有 try-catch整个广播循环中断甚至线程崩溃。解决广播时对每个玩家单独 try-catch写失败的玩家标记为断开并从房间移除不影响其他玩家。断开清理要放在finally或专门的RemoveFromRoom里。5.4 现象游戏结束后还能继续点击或者胜利判定不触发原因IsGameOver标志在踩雷时设置了但胜利路径没设置或者 View 层没有根据IsGameOver禁用输入。解决Reveal里踩雷和胜利两条路径都要设IsGameOver true。View 刷新时检查IsGameOver为真则禁用所有格子点击。Controller 的OnCellClicked开头也要判断双保险。5.5 现象局域网内两台机器连不上本机测试却正常原因服务端绑定了127.0.0.1而不是0.0.0.0只监听本机回环。或者防火墙拦截了端口。解决TcpListener用IPAddress.Any绑定所有网卡。检查防火墙是否放行监听端口局域网测试时客户端填服务端的实际内网 IP不要填localhost。6. 进阶用操作日志做断线重连与回放基础联机跑通后最值得加的一个能力是断线重连。玩家掉线重进如果要从头再来一局体验很差。好在前面用了「种子 操作日志」的设计重连恢复几乎是免费的。这一章讲怎么把操作日志存下来以及重连时怎么用日志把棋盘状态追回来。核心思路服务端为每个房间维护一个操作列表记录所有Reveal和Flag的坐标和顺序。玩家重连时服务端先发GameStart带原种子和参数再发SyncBoard负载里是完整操作日志。客户端收到后用种子重建空棋盘然后按顺序重放每一条操作棋盘状态就恢复到断线前。// 服务端房间内记录操作日志 public class Room { public List(MsgType type, byte[] payload) ActionLog { get; } new(); public int Seed { get; set; } public int Rows { get; set; } public int Cols { get; set; } public int MineCount { get; set; } } // 转发操作时顺便记日志 private void BroadcastToRoom(TcpClient sender, MsgType type, byte[] payload) { var room FindRoom(sender); if (room null) return; room.ActionLog.Add((type, payload)); // 先记日志 foreach (var player in room.Players) { if (player.Client sender) continue; try { NetworkHelper.Send(player.Stream, type, payload); } catch (IOException) { /* 标记断开 */ } } } // 重连时下发完整状态 private void SendSyncBoard(Room room, Player reconnected) { // 先发开局信息 NetworkHelper.Send(reconnected.Stream, MsgType.GameStart, BuildStartPayload(room.Seed, room.Rows, room.Cols, room.MineCount)); // 再把操作日志逐条重放 foreach (var (type, payload) in room.ActionLog) NetworkHelper.Send(reconnected.Stream, type, payload); }逻辑说明ActionLog按顺序记录所有改变棋盘状态的操作重连时先发种子让客户端重建初始棋盘再逐条重放日志客户端 Model 的状态就和断线前完全一致。这个日志同时也是回放数据想做「复盘」功能直接拿来用。参数说明日志只记改变状态的操作JoinRoom这类不记日志在内存里房间销毁就没了要做持久化回放需要写文件或数据库重放顺序必须和记录顺序一致不能并行。验证方法故意在游戏中途关掉一个客户端重连后对比两边棋盘如果每个格子的状态都一致说明日志重放正确。也可以把日志导出成文本人工核对操作顺序。我自己的习惯是任何联机项目都先把操作日志做出来哪怕暂时用不上重连。因为它是最便宜的后悔药——出了状态不一致的 bug把两端的日志一对比问题出在哪一步一目了然。联机扫雷这个项目不大但把这套「协议定死、MVC 分层、日志兜底」的套路走一遍下次做任何联机小游戏都能直接复用。希望帮到你。本文还有配套的精品资源点击获取