FishGame捕鱼游戏源码剖析：从TCP通信到服务端状态同步实战

简介：这套FishGame完整网游源码包，涵盖可直接部署的客户端与服务器端，适合有一定编程基础、希望研究网络游戏前后端架构和Socket通信机制的开发者。包内共70个文件，包含14个exe主程序、17个dll运行库、14个txt部署与说明文档，以及ini/conf配置文件、php/java/c等配置与代码文件，清晰覆盖客户端启动、服务器架设和二次开发所需内容，压缩包约39.94MB。已有1382人浏览学习。通过这套代码可以接触客户端渲染与交互、网络数据收发、服务器多线程并发、游戏逻辑判定与状态同步、账号信息管理等多个关键模块，既能帮助理解一款小型网游从登录到对局的完整流程，也可作为课程设计、毕业设计或自主练手项目的参考资料。 各位折腾过网游源码的朋友应该都有同感：网上能下载到的“完整可运行”项目里，十个有八个缺胳膊少腿。要么客户端编译完缺资源，要么服务端启动就崩，折腾半天全耗在配置环境上。最近我拿到一套FishGame的完整源码，客户端+服务器端齐全，亲测能跑通整个游戏流程。这套源码对想学习游戏网络通信、服务端逻辑或者想做捕鱼类休闲游戏的人来说，是个不错的参考样本。这篇博文我会从项目结构、核心代码逻辑到本地部署实测，把整个链路掰开揉碎讲清楚，顺便把部署时踩过的坑也一并列出来，给后来者省点时间。

1. 项目整体架构拆解：这套“鱼”是怎么游起来的

1.1 游戏类型与核心玩法定位

拿到源码后，我没有急着编译，而是先把代码目录、脚本资源、配置文件都过了一遍。FishGame从命名和资源结构来看，属于典型的“捕鱼达人”类休闲网游：玩家在同一个房间里，各自通过炮台发射子弹来捕捉海里游动的鱼群，命中后获得金币奖励。这种玩法的技术挑战不在客户端画面表现，而在于服务器端需要高频同步多玩家的操作、鱼群状态以及碰撞结果。

整个项目采用C/S架构，通信走TCP长连接。客户端负责渲染海底场景、鱼群的游动动画、玩家操作交互；服务器端负责维护房间状态、生成和同步鱼群、处理子弹碰撞判定、结算玩家得分。这种分工是当前市面上海量休闲网游的主流做法——把计算密集的碰撞逻辑放服务器端，可以最大程度保证公平性，避免客户端作弊。对于学习网络游戏开发的人来说，这套源码的价值正在于此：它呈现了一个小型在线游戏服务器的完整骨架，而非只是一个单机Demo。

1.2 客户端与服务器端的目录结构比照

项目解压后主要分两个大目录：FishGameClient和FishGameServer。两个工程之间没有共享代码，协议是通过一份自定义的Socket消息格式对接的。客户端代码偏重渲染与表现，用的是传统的GDI+或Direct2D绘制（具体看编译配置），不依赖Unity、Unreal这类重型引擎，所以体积非常小，运行起来也不吃配置。服务器端则是一个控制台程序，逻辑聚焦在帧循环与消息分发上，没有数据库依赖，数据存储在内存中。

这种设计的优点是：依赖少、上手快、非常适合作为源码学习对象。缺点也很明显，就是功能上“够用但不出彩”——鱼群AI偏简单、没有断线重连、金币只存在内存里，服务器一关数据就没了。但这并不影响它作为一个教学级网游源码的价值，反而因为复杂度适中，更容易把网络通信的骨架读透。

2. 客户端的核心实现：画面、操作与请求封装

2.1 场景绘制与鱼群动画的内存模型

客户端代码入口是标准的Win32窗口程序。在窗口初始化的过程中会创建双缓冲画布，之后每帧执行：清屏、绘制背景、绘制鱼群、绘制炮台和子弹、绘制UI。鱼群数据统一存放在一个对象池中，每条鱼有坐标、方向、速度、类型ID这几个基础字段。鱼群游动采用贝塞尔曲线路径，当鱼到达路径终点时会自动反向或者转向，这样就能模拟出比较自然的水中游动效果。

我在看这部分代码时注意到一个设计细节：鱼群的生成是由服务器端下发的指令驱动的，客户端不会自己凭空生成鱼。服务器会定期向房间内广播“鱼群生成”的消息包，客户端收到后才在本地对象池中创建对应数量的鱼对象。这样做的好处是，所有玩家的客户端看到的鱼群位置能够保持同步，不会出现“同一条鱼在不同玩家屏幕上位置不一样”的错位问题。

2.2 玩家操作的本地响应与网络请求

玩家用鼠标点击屏幕上的某个位置时，客户端会做两件事：第一，立刻在本地创建一颗子弹，从炮口射向目标位置，让操作者获得即时的视觉反馈；第二，将这次发射行为封装成一条消息，通过TCP连接发送给服务器端。服务器端收到消息后，在服务器逻辑中计算子弹轨迹，并在每次碰撞检测中判断是否命中鱼。

这里为了让操作不卡顿，作者做了一个非常聪明的取舍：子弹的初始轨迹和飞行速度由两端共享同一套算法公式。也就是说，本地客户端和服务器在轨线计算上用的是同一套运动学逻辑，只要初始状态一致，后续每帧位置就是确定的。这样即使某些网络消息有延迟，玩家看到的画面也是平滑的，不会出现本地子弹已经飞出去了，但服务器还没收到“发射指令”导致的突兀回弹。

2.3 客户端源码中值得学习的几个封装技巧

这段代码里让我印象比较深的是它封装了一个MsgPacker类，所有的协议字段统一用二进制流写入，包括消息类型、长度、玩家ID以及携带参数。这种手动打包的方式看起来不如JSON直观，但传输效率和解析性能都非常好，而且很容易在底层做加密。对于想学网络协议设计的朋友，建议把这份打包/解包代码读透，理解消息头、消息体、字节序这些基础概念是怎么在真实项目中落地使用的。

另外，客户端还有一个很关键的容错处理：当服务器连接断开时，播放器画面会弹出重连提示框，但程序不会立刻闪退。这个逻辑的实现思路是单独开一个线程轮询服务端的连接状态，一旦发现连接丢失就切换到断线状态。虽然这套源码没有做成自动重连，但这个轮询+状态机的模式值得借鉴，后续自己加断线重连功能时，只需要在此状态机上扩展一个“重新建立连接、重新拉取房间数据”的状态即可。

3. 服务器端设计思路：房间、消息分发与防作弊

3.1 服务端循环与帧率控制

FishGameServer的运行逻辑不复杂，核心就是一个while循环持续驱动：接收网络消息、更新鱼群状态、处理碰撞、下发状态同步包。为了不让服务器空转吃满CPU，作者在循环里设置了线程休眠时间，默认是50毫秒一帧，也就是服务器的逻辑帧率大约20 FPS。这个帧率对于捕鱼类游戏来说完全足够，因为子弹和鱼的移动速度都不高，逻辑上不需要60 FPS的精度。

帧率控制这个点容易被初学者忽略，但实际上非常重要。逻辑帧率决定了两件大事：一是碰撞检测的时间粒度，20 FPS意味着每50毫秒检测一次当前所有子弹是否撞到了鱼，粒度过细会浪费CPU，粒度过粗则可能导致子弹穿模；二是上行消息的处理顺序，所有玩家指令会集中在每一帧的统一处理阶段批量执行，这比来一条处理一条更容易保持状态一致性。我在自己的服务器框架中也采用过类似的模式，可以说这是入门级游戏服务器的一个标准做法。

3.2 消息分发机制：如何区分不同玩家

服务器端维护了一个PlayerSession列表，每个新接入的TCP连接都会在这份列表中注册一个会话对象，会话里保存着玩家ID、所属房间、当前坐标、金币数等属性。每当Socket通道收到一个完整的数据包，服务器就根据消息头中的消息类型做一次switch分发：MSG_LOGIN、MSG_SHOOT、MSG_HIT_FISH、MSG_HEARTBEAT等，每种消息对应一个处理函数。

这里有个值得注意的细节：处理函数里获取到的玩家信息，不能直接从当前线程的上下文中推断，而必须从数据包里解析出玩家ID，再到会话列表中去索引。之所以强调这一点，是因为网络消息到达的顺序和玩家本身的逻辑操作顺序并不一定完全一致，依靠包内字段才是最可靠的方式。这其实是所有网络编程的通用原则——连接标识永远不能当作玩家身份的唯一凭证。

3.3 碰撞检测与防作弊的关键逻辑

服务器端碰撞计算的代码是整个项目中最核心的部分。每帧遍历所有的子弹对象，以子弹当前位置为圆心划定一个范围，遍历鱼群的所有鱼对象，如果距离小于预设的阈值（根据鱼的类型不同，捕获半径也不同），则判定为命中。命中后服务器会立即对这条鱼的“人生状态”打上死亡标记，然后向房间内所有玩家广播一条“鱼死亡+获得金币”的消息。

防作弊的地方就在这里：客户端屏幕上显示的金币变化，并不是客户端自己本地计算出来的，而是以服务器下发的为准。即使有人修改了客户端内存，把金币数改成天文数字，下一次服务器同步一到，数据就会被强制纠正回来。另一方面，服务器的碰撞检测用的是绝对位置计算，而不是信任客户端上报的“我打到鱼了”的消息。从源头杜绝了最常见的抓包工具伪造击杀请求的作弊手段。

3.4 服务器端被忽略但极其实用的日志模块

我翻源码时发现，作者在服务器工程里还留了一个非常朴实但实用的日志模块：按日期切割文件，输出到logs/目录下，日志级别分为INFO和ERROR两种。这个模块虽然短，但对于后续调试非常关键。例如，当线上玩家反馈“我明明打中了鱼但没有加金币”的时候，第一件事不是去复现，而是去服务器日志里找该玩家ID相关的操作记录，通过对比时间线上客户端上报的发射消息和服务器下发的结算消息，就能快速定位是网络延迟问题还是逻辑bug。

我建议所有拿到这份源码的人，先不要急着改功能，把日志模块读一遍，然后在自己的开发调试中尽可能保留它。无论是学习状态同步，还是排查网络丢包，这些日志能帮你省下大量时间。有时候一个看似是业务逻辑的问题，实际是消息顺序颠倒了，而这种问题恰恰只有完整日志才能看出端倪。

4. 本地部署实测：从源码到可运行的完整过程

4.1 环境准备与工具链选择

我实测时用的环境是Windows 10 x64，客户端工程用的是Visual Studio 2017编译（换成2015或2019/2022也能编，稍后我会提到需要改的地方），服务器端同样是VS工程。源码中自带的依赖库只有一个jsoncpp，用于部分配置文件的解析，没有编译坑点。

建议按照下面这套步骤准备环境：

1. 安装VS 2017或更高版本，勾选“使用C++的桌面开发”工作负载。
2. 将解压后的两个工程分别用VS打开，先编译服务器端，再编译客户端。
3. 源码里附带的config目录中存放服务器IP和端口配置，默认是127.0.0.1:9001，本机测试无需改动。
4. 如果VS版本较新，编译时可能出现某个头文件找不到报错，需要把工程属性里的“Windows SDK版本”手动切换到本机已安装的版本。

4.2 本地运行顺序与联调验证

部署运行有一套固定的顺序：先开服务器端，再开客户端。因为客户端在启动时会主动尝试连接服务器，顺序反了的话客户端会直接弹出“无法连接服务器”的提示。

具体运行步骤如下：

• 启动FishGameServer.exe，看到控制台打印“Server started, listening on port 9001”说明监听正常。
• 启动FishGameClient.exe，登录界面输入任意用户名和密码，只要不重复就能登录成功（说明没有和数据库校验，纯内存账户）。
• 登录进入房间后，画面中会出现鱼群游动，鼠标点击水面即可发射子弹。
• 开另一个客户端实例，用另一个用户名登录，两个窗口进入同一个房间后，可以看到对方的炮台和跑动状态，并能同时攻击同一片鱼群。这说明服务器端的广播同步生效了。

在联调时我特意测试了一个关键场景：两个客户端同时对准同一条鱼射击。服务器端日志显示，先到达的那颗子弹命中了鱼，后到达的子弹只记录为Miss。这个细节说明服务器端的碰撞判定确实是全局有序的，不存在“两个人都打到同一条鱼”的bug。

4.3 部署过程中常见的编译问题速查

拿到源码后，在编译过程中有可能会出现几个问题，我在这里整理成速查表方便大家对照：

还有一个比较隐蔽的坑：客户端和服务器端的工程字符集设置必须一致，推荐都用“使用Unicode字符集”。如果一侧是Unicode而另一侧是多字节字符集（MBCS），在传输中文字符串参数时会出现乱码，表现为登录后玩家昵称显示为问号。

5. 代码实战：从一套源码看网络游戏通信的技术精髓

5.1 协议设计与消息头结构详解

FishGame的消息头结构在NetMessage.h中定义，非常简单清晰。每条实际发送的数据包都固定以一个Header开头：

struct NetMessageHeader { unsigned short uMsgSize; // 消息体长度 unsigned short uMsgID; // 消息类型ID int nSenderID; // 发送者ID };

uMsgSize和uMsgID各占两个字节，nSenderID占四个字节，因此整条消息的头部固定为8个字节。接收方在读取时，会先读到这8个字节的头部，从而知道后续要读多少字节的消息体。这种长度在前、类型在后的布局方式，在网络编程中非常常见。

我在自己的服务器框架里，经常看到有人把消息头里的长度字段定义成int，其实对于捕鱼类这种单条消息不会超过1KB的协议来说，用unsigned short就足够了。把多余的空间省下来充作协议定义的余地，反而更合理。这个头结构值得照着背下来。

5.2 定长与变长消息体的处理思路

消息体有两种：定长消息和变长消息。定长消息如“心跳包”，结构就是一个int时间戳，4字节，不需要额外处理；变长消息如“聊天消息”，里面有玩家ID、消息文本，由于文本长度不固定，就在消息体里再套一个长度字段。

而在FishGame的协议设计中，作者更巧妙地避开了一个常见陷阱——在做客户端和服务端信息交换时，将字符串统一用UTF-8编码。这看起来是一个小决定，却在多语言环境或者跨平台部署时能避免大量乱码问题。我在测试时单独试过发中文聊天消息，完全正常。

5.3 封包与拆包的边界问题

TCP是流式协议，数据在传输中是没有边界的——也就是说，一次send发送的数据，对端recv时可能一次性收到几条消息拼在一起，也可能一条消息被拆成两半分别到达。FishGame处理这个问题的方法很标准：用一个循环接收缓冲区。

void RecvLoop(SOCKET sock, char* pBuffer, int& nBufPos) { int nRet = recv(sock, pBuffer + nBufPos, MAX_BUFFER - nBufPos, 0); if (nRet > 0) { nBufPos += nRet; // 循环解析出完整的数据包 while (nBufPos >= sizeof(NetMessageHeader)) { NetMessageHeader* pHeader = (NetMessageHeader*)pBuffer; if (nBufPos < sizeof(NetMessageHeader) + pHeader->uMsgSize) { break; // 数据不完整，等下一轮 recv 补全 } ProcessMessage(pHeader); // 把已处理的数据从缓冲区移除 memmove(pBuffer, pBuffer + sizeof(NetMessageHeader) + pHeader->uMsgSize, nBufPos - sizeof(NetMessageHeader) - pHeader->uMsgSize); nBufPos -= sizeof(NetMessageHeader) + pHeader->uMsgSize; } } }

简单理解就是：先把收到的字节塞进缓冲区，然后不断检查缓冲区里有没有“一个完整的消息包”，有则解析，没有则继续等待。这个流程理解透了，TCP网络编程的封包拆包就算入门了。很多复杂网络库（比如Protobuf、MessagePack）的实现，底层也是这一个逻辑。

5.4 心跳机制与断线检测的实现

网络编程中，TCP本身虽然有KeepAlive机制，但它默认关闭且触发时间很长。游戏服务器一般都会实现自己的应用层心跳。FishGame也不例外：客户端每隔5秒向服务器发送一条心跳消息，服务器端维护一个“最后活跃时间”字段，一旦发现连续20秒没有收到某玩家的任何消息，就判定该玩家掉线，将其从房间中移除并广播给其他玩家。

这个实现本身不难，难点在于心跳时间参数的设置。如果设得太短，网络稍微抖动一下服务器就会误判玩家掉线；设得太长，服务器又无法及时清理僵尸连接。FishGame采用的“5秒心跳、20秒超时”组合是经过权衡的：允许连续丢4条心跳才开始怀疑掉线。这个比例在大多数网络环境下是稳妥的，不建议新手直接改小。

6. 扩展思路：从这套源码出发还能做些什么

6.1 改进方向一：加入Redis做持久化与排行榜

目前FishGame的金币数据只存在于内存中，服务器一停数据就没了。如果你希望做成一个可持续运营的版本，最直接的方式是加入Redis，用它的HSET结构存储每个用户的ID和金币数，每5分钟或玩家下线时异步写回一次。排行榜功能也可以借着Redis的ZSET有序集合轻松实现，按照金币数排序，读取Top 10做全服展示。这一块改造的技术成本不高，但能让项目从“教学Demo”进阶为“可试运营的小型游戏”。

需要说明的是，引入Redis后需要注意多线程安全。服务器的主逻辑循环中读取Redis数据没问题，但写入操作应当用一个独立的线程、通过消息队列异步执行，避免网络阻塞阻塞卡住游戏主循环。Redis有自带的客户端库（如hiredis），用C代码调起来也不复杂。

6.2 改进方向二：从单房间到多房间的架构升级

FishGame当前的结构是“所有玩家在同一个房间”，没有房间列表、也没有创建/加入房间的功能。如果你想让这个项目支持更多人同时在线，可以设计一个RoomManager来管理多个房间实例，每个房间维护自己的鱼群和玩家列表。玩家进入游戏时先选择或创建房间，等房间人数到达上限后封房并开启游戏。这个改动在代码层面并不算大，核心是把原来全局唯一的FishManager和PlayerSession列表按房间维度拆开即可。

我实测过程中尝试过在服务器端同时开两个房间的逻辑，把RoomManager做成一个单例容器，房间类内部保存自己的全部状态，消息分发时先根据玩家ID找到对应的房间，再调用房间的处理方法。改动完成后，原来的单房间功能完全兼容，多房间也运行顺畅，没有出现同步错乱。

6.3 改进方向三：将通信协议迁移到Protobuf或FlatBuffers

如果用FishGame学完了网络协议设计的基本功，接下来可以试着自己引入Protobuf或FlatBuffers来替换手写的NetMessage。这种成熟的序列化框架能自动生成各种语言版本的编解码代码，天然支持版本兼容、字段增加等操作。对于跨平台、跨语言（比如客户端C++、服务端Go）的重构方案来说，几乎是必选项。

我第一次从手写协议转向Protobuf时的体会是：手写协议让我真正理解了字节布局，而Protobuf让我从繁琐的手动打包/解包代码中解放出来。这两者不是替代关系，而是先后关系。把FishGame的协议先吃透，再迁移到Protobuf，是一个非常好的练手节奏。

7. 写在最后的实操体会

整套代码我完整跑过不止一遍，从第一次编译时的各种环境报错，到最终两个客户端同时在线互射，整个过程耗费了两个小时左右。如果只是按照文档搭建，顺利的话半小时内就能跑起来。让我觉得最值得推荐的是这套源码“麻雀虽小，五脏俱全”：TCP通信、消息分发、状态同步、心跳检测、碰撞判定，所有网络游戏开发者必须掌握的核心点都有了，而且没有引入重型框架把自己绕晕。

最后再分享一个小技巧：如果你是想拿这套源码来学习，建议读完服务器端代码之后，自己尝试把HSET换成真正的“Redis持久化”，或者把消息分发从switch改成函数指针表。你会发现，改造的过程比看源码更有价值。而如果你只是想找个能和朋友一起玩的休闲小游戏，编译出来直接双击运行就完事了。

本文还有配套的精品资源，点击获取