简介这是热血传奇2005年客户端源码包面向游戏开发爱好者与早期网络游戏技术研究者可用于了解那个时期客户端程序的组织方式和开发特点。资源共4个文件以HTML说明文档和代码记录文件为主另有Git忽略配置项压缩包整体仅8KB查看和阅读非常轻量。目前已有138人学习浏览。这段客户端代码体现了2005年网络游戏客户端在用户操作响应、画面渲染、网络通信等方面的基础实现思路。开发者可通过阅读其中保留的历史代码片段熟悉早期游戏编程中常见的数据封装、异常处理和模块划分方式一些经典算法与设计模式即便放到当下也仍具有一定的借鉴价值。配合文档文件中的说明可较为完整地还原当时客户端开发的脉络作为学习游戏编程演进的一份补充素材。1. 热血传奇2005客户端代码它不是游戏是一台时间机器我刚把这份源码从压缩包里解出来的时候第一反应是怀疑自己下载错了没有 .sln 工程没有 Unity 场景连个像样的 README 都没有只有一堆 .dsp/.dsw 老工程文件、数不清的 .cpp/.h 和 WIL 资源文件。双击编译出来的 exe 也并不会直接弹出游戏窗口因为它默认走的是全屏 DirectDraw 模式在今天的显卡上大概率黑屏。但恰恰是这种“老掉牙”的形态让它成为一份极难得的教学样本它把 00 年代 MMORPG 客户端的登录流程、资源封装、网络封包、主循环调度四个最核心的模块以最朴素、没有任何引擎掩盖的方式摊在你面前。如果你有 C 基础、想搞懂老游戏客户端是怎么工作的或者需要在一套旧代码上做移植和二次开发这套源码代码包比任何现代教程都值钱。如果你是想一键开服那可以关掉这个页面了——这不是服务端也不是成品游戏。2. 源码拓扑模块划分与启动流程哪些文件值得先读拿到一套 2005 年前的客户端代码第一件事不是急着编译而是先把目录结构摸清楚。这套源码的工程组织方式和今天习惯的“解决方案 项目”完全不一样它是按功能模块切目录、再通过 .dsp 工程文件把散落的源文件聚合起来的。我在下面按“模块 → 典型文件 → 职责”的方式整理了一张表对照着去翻代码包能少走很多弯路。2.1 客户端模块与文件识别别被几十个文件夹吓住老客户端代码的目录看着吓人其实大部分是第三方库和资源文件真正需要读的源码目录就四五个。我一般会先打开工程文件或 Makefile顺着链接依赖反向找回源文件列表。模块常见文件示例职责程序入口Main.cpp / GameApp.cppWinMain、窗口创建、消息循环图形渲染DirectDraw.cpp / DxLib.cppDDraw 初始化、表面管理、贴图/精灵绘制资源管理WixFile.cpp / ImageLib.cpp读取 WIL/WIX 图片资源、索引解析、缓存网络模块Socket.cpp / NetPack.cppSocket 封装、封包加密解密、协议分发游戏逻辑GameProc.cpp / MapCtrl.cpp状态机、地图控制、角色控制、战斗流程界面系统DlgMgr.cpp / LoginDlg.cpp自绘窗口、按钮、输入框不依赖 MFC需要注意一点2005 年这个时间点的客户端大多已经不用 MFC 了界面是直接用 DirectDraw 在后台缓冲上“画”出来的。这意味着你在代码里几乎看不到标准控件库的调用取而代之的是大量 BitBlt / StretchBlt 和自定义消息处理。这不是代码质量差而是当年做游戏界面的标准做法读的时候别拿现代 UI 框架的习惯去套。代码包里通常还会混着 zlib、libpng、Lua 脚本等第三方源码目录这些属于依赖项不是核心可以先在工程文件里把它们标记为“不参与编译”减少干扰。我习惯的做法是先 grep 一下各目录里的 #include 计数被引用次数最多的那几个文件就是主链路文件优先读。2.2 启动流程从 WinMain 到进入游戏要闯几道关客户端从启动到看到登录界面中间经过的步骤在代码里是有清晰顺序的。2005 年的客户端不像现代引擎有统一的“引擎启动器”一切都是 WinMain 里手工推进。我读这套代码时整理出的典型启动链路如下WinMain 先解析命令行参数包括服务器 IP、端口、窗口模式开关、语言编码标志这些参数会被存进全局配置结构体。读取本地配置文件常见命名如 Mir.ini把上一步的命令行参数覆盖进去优先级是“命令行 配置文件 默认值”。创建主窗口这一步是纯 Win32 的 RegisterClass CreateWindow窗口类名和样式一般是写死的比如 800x600 固定大小。初始化 DirectDraw枚举显示模式、创建主表面和后台缓冲设置调色板。这个环节是黑匣子重灾区很多迁移到新系统后黑屏就是在这里翻车的。加载登录界面资源把 Login.wil / Login.wix 等资源文件读入内存解析出界面背景图、按钮图、输入框光标等素材。创建网络连接对象并连接登录服务器。如果失败界面会停在“正在连接服务器请稍候”的状态。进入消息循环开始正常游戏帧循环。整个流程中比较容易被忽略的是第 2 步的配置读取顺序。有些版本把服务器 IP 硬编码在代码里配置文件只是一个摆设有些版本则完全相反所有服务器地址都在 ini 里动态读取。判断标准很简单在源码里搜“server”和“gate”相关的全局变量看它们的初值是常量还是配置文件映射的键值。2.3 游戏主循环PeekMessage 与帧率控制的分水岭老客户端的消息循环几乎是同一种套路为了在“不操作时依然能执行网络收包和动画刷新”消息处理用 PeekMessage 而不是 GetMessage。差异在两处一是循环退出条件二是帧率控制逻辑。2005 年的版本大多还没有垂直同步概念纯粹靠时间戳计算帧间隔。典型的循环像下面这样// 游戏主循环PeekMessage 时间片驱动 MSG msg; while (bRunning) { // 有窗口消息则处理没有则立即返回不阻塞 if (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message WM_QUIT) { bRunning FALSE; continue; } TranslateMessage(msg); DispatchMessage(msg); } else { // 计算本帧时间差限制逻辑和渲染频率 DWORD dwNow timeGetTime(); DWORD dwDelta dwNow - m_dwLastTick; if (dwDelta 10) { // 大约 100 FPS 上限 GameTick(dwDelta); m_dwLastTick dwNow; } // 空闲时让出 CPU避免占满单核 Sleep(1); } }这段代码里的关键点是 dwDelta 10 这个下限。很多后来的私服改造版把阈值调成 30 或 50让帧率上限降下来结果发现游戏逻辑比如技能冷却、走路速度也跟着变慢了——原因是这套客户端的很多逻辑计时直接依赖这个 delta 值而不是独立时钟。读这份源码时如果你想改帧率上限记得同时去检查时间相关的全局变量是否有地方用“帧数”做隐式计算。主循环里还有一层容易被忽略的分流GameTick 内部通常会先处理网络接收队列再处理键盘/鼠标缓冲区最后才做地图渲染和角色行动。也就是说当你看到角色在画面上移动时位置其实已经被网络包提前影响过一次了。这在后面读登录协议、移动协议时要格外留意不要把“画面表现顺序”误当成“数据到达顺序”。3. 编译与运行从 VC6 到 VS2015 的迁移手术这章是实战环节。2005 年的代码是用 Visual C 6.0 时代的 .dsp 工程组织起来的想在今天的 VS2015 上编译核心问题不是语法而是三个老工程格式怎么迁移、DirectX SDK 头文件往哪放、字符集和运行时库怎么选。我按一个能跑通的最小步骤来写你照着做就不会卡在“编译 500 个错误”这一步。3.1 打开工程先认识 .dsp 这个老古董再决定迁移路径代码包里的工程文件大概率是 .dsp/.dsw 后缀VS2015 并不能直接打开它们。不要试图用新版 IDE 去强行加载旧工程那会把简单的路径问题渲染成几百个莫名奇妙的语法报错。正确的做法是手工迁移新建一个 Win32 桌面应用工程再把源码文件加进去。在动手之前先把旧工程里可能残留的中间文件清掉。这些文件是原开发者在当年机器上编译留下的路径早就失效了不清会造成误报。用下面这段批处理清理一下echo off rem 清理旧编译产物防止失效的 pch 干扰新工程 for /d /r . %d in (Debug Release) do rd /s /q %d for /r . %f in (*.pch *.obj *.idb *.pdb) do del /q %f echo done.清理后在 VS2015 里新建一个“Win32 项目”向导会让你选空项目或不使用预编译头。这里有两个细节一是向导默认的工程带了 stdafx.h老代码也带自己的 stdafx.h冲突时以老代码的为准二是新工程默认使用 Unicode 字符集必须改成“多字节字符集”否则大量 char* 函数和 CString 操作会报 C2664 类型转换错。3.2 DirectX SDK 版本与头文件顺序新版先声夺人的代价2005 年客户端依赖的 DirectPlay/DirectDraw 头文件在 VS2015 自带的 Windows SDK 里并不完整需要额外引入 DirectX SDK比较稳妥的是 June 2010 版本。完整安装后SDK 的环境变量是 DXSDK_DIR。接下来是真正的坑新老 SDK 的 d3d9.h 和 d3dx9.h 互相排放顺序不对会触发一堆“重复定义”或“找不到标识符”。配置要点很清楚在工程的 VC 目录里把 DXSDK 的 Include 路径放在 Windows SDK Include 路径的前面让编译器先看到老版本的头文件。Library 路径同理。工程文件里的关键 XML 片段如下你可以直接在 .vcxproj 里手动改也可以项目属性里点选PropertyGroup IncludePath$(DXSDK_DIR)Include;$(IncludePath)/IncludePath LibraryPath$(DXSDK_DIR)Lib\x86;$(LibraryPath)/LibraryPath /PropertyGroup ItemDefinitionGroup ClCompile CharacterSetUseMultiByteCharacterSet/CharacterSet RuntimeLibraryMultiThreadedDebugDLL/RuntimeLibrary PreprocessorDefinitions_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS/PreprocessorDefinitions /ClCompile /ItemDefinitionGroup第一个 里的顺序就是踩坑点必须让 $(DXSDK_DIR)Include 在最前面才能用 DXSDK 的 d3d9.h 覆盖 Windows SDK 中不完整的版本。后面多字节字符集和运行时库的选择也要注意RuntimeLibrary 用多线程调试 DLL对应 /MDd否则你在 Debug 下会看到一堆 LNK2038 之类运行时不匹配的错误。3.3 链接错误三件套遇到这些提示时说明迁移方向对了迁移之后编译能过到链接阶段就算成功一半。常见的链接错误就那么几类都是有固定解法的不必慌。第一种错误LNK2019 unresolved external symbol _WinMain16 referenced in function __tmainCRTStartup。这通常是因为控制台子系统和 Windows 子系统搞混了。解决方法项目属性 → 链接器 → 系统 → 子系统设为“Windows (/SUBSYSTEM:WINDOWS)”同时在入口点保持默认。第二种错误LNK2019 ws2_32.lib 相关符号无法解析。2005 年代代码习惯在 stdafx.h 或网络模块顶部手动 include winsock2.h但忘记附加链接库。现代编译器不会自动帮你链接老库需要显式声明。大多数代码里已经写了 #pragma comment(lib, ws2_32.lib)没写的话在 stdafx.h 末尾统一加一段// 手动指定链接库避免在工程属性里遗漏 #pragma comment(lib, ws2_32.lib) #pragma comment(lib, d3d9.lib) #pragma comment(lib, d3dx9.lib) #pragma comment(lib, dxguid.lib) #pragma comment(lib, winmm.lib)第三种错误LNK1104 cannot open file d3d9.lib。这就是 3.2 节库路径没配对回检查库目录里 DXSDK 的 Lib\x86 是否存在注意选择 32 位x86版本2005 客户端没有 x64 支持。4. 登录链路与封包协议看懂客户端到底在发什么编译通过只是起点。这份源码真正值钱的地方在登录链路和封包协议。很多拿这套代码做二次开发的目的就是从客户端里抠出登录流程、理解加密方式然后配合服务端联调。这一章我会把客户端视角的连接过程、封头结构和加密算法拆开讲。4.1 客户端视角LoginGate → SelGate → GameGate 的三个连接阶段传奇类客户端的登录流程不是一步到位的而是分阶段连接不同的服务器组件。2005 年版本里客户端通常会依次连接登录服务器、选人服务器和游戏服务器。下表是典型阶段划分阶段连接目标客户端动作本阶段核心封包登录LoginGate发送账号密码登录请求/登录响应选服SelGate拉取服务器列表选服请求/区列表选人SelGate创建/选择角色角色列表/创建角色进游戏GameGate进入游戏世界入场请求/入场回应代码里搜索类似 ConnectLogin / ConnectSel / ConnectGame 这类函数名可以看到三个连接用的服务器地址通常来自同一个配置项。如果你发现三个阶段连的都是同一个 IP只是端口不同那是正常的。我见过不少读者在这里翻车以为 GameGate 一定在另一个地址把客户端配置改成两个 IP 后反而连不上了。4.2 封包头结构与核心加密老版本写死的 0xAC登录阶段的封包格式是典型的自定义二进制结构。客户端把账号密码装进结构体再原地加密最后发给服务端。一个常规的封包头像这样// 封包头2字节协议号 2字节包体长度 4字节序列号 #pragma pack(push, 1) typedef struct tagNetMsgHead { WORD wIdent; // 协议号比如 0x0101 表示登录请求 WORD wSize; // 包体长度单位字节 DWORD dwSeq; // 自增序列号用于防重放和排序 } NET_MSG_HEAD, *LPNET_MSG_HEAD; #pragma pack(pop)加密部分我拿到的这份代码用的是“固定初始值异或 查表置换”的朴素方案。这类算法在现代加密标准面前非常弱但在当年就是主流。客户端代码里一般会有一小段类似这样的函数// 经典的老式异或加密密钥固定写在代码里 void XorPacket(BYTE* pBuf, int nLen) { // 0xAC 是写死的掩码后续版本改为按包序号轮换 BYTE byKey 0xAC; for (int i 0; i nLen; i) { pBuf[i] ^ (byKey i); } }这段代码的关键是密钥来源很多魔改版把 0xAC 换成了变量、或按封包序号做 16 种密钥轮换导致客户端能发出数据但服务端解密失败。如果你要和服务端联调务必先确认两边密钥初值一致。比较省事的验证方法是抓包在客户端连接登录服务器时用 Wireshark 抓一下前两个字节再看服务端日志收到的包是否对得上协议号。4.3 非阻塞收发与粘包处理对照老代码看自己踩过多少坑2005 年客户端在网络接收上有个常见的半残设计recv 一次只等一个包不管缓冲区里是否还残留着下一个包的数据。这在局域网低延迟环境下问题不大但在跨网或高峰期就会频繁丢包、卡界面。我读到的大多数版本核心逻辑是这样的// 典型的老式非阻塞接收 fd_set fdRead; FD_ZERO(fdRead); FD_SET(m_Socket, fdRead); timeval tv { 0, 500 }; int nRet select(0, fdRead, NULL, NULL, tv); if (nRet 0 FD_ISSET(m_Socket, fdRead)) { int nLen recv(m_Socket, m_Buf m_nBufLen, BUFSIZE - m_nBufLen, 0); if (nLen 0) { m_nBufLen nLen; // 危险点直接把缓冲区当作一个完整包来处理 ProcessPacket(m_Buf, m_nBufLen); m_nBufLen 0; } }这里的隐患一眼就能看出来如果一次 recv 同时收到两个小包ProcessPacket 会拿着“两个包拼在一起的垃圾长度”去解析必然出错。正确的做法是在接收后先用包头里的 wSize 字段判断是否攒够一个完整包只解析出该包的字节数留下多余数据给下轮处理。很多后续优化其实都是在这个位置做手术的。4.4 封包打日志给协议解析上保险丝读协议代码时最实用的习惯是先加日志。你把 ProcessPacket 的入口做一个统一的包打印再带着日志跑一遍登录流程就能看到客户端到底发了哪些包、每个包的长度和协议号是什么。这比单纯读代码快十倍。一个最轻量的打点// 在 ProcessPacket 最前面插入临时抓包工具 void PacketLog(const char* szTag, BYTE* pData, int nLen) { FILE* fp fopen(packet.log, ab); if (fp) { fprintf(fp, [%s] len%d , szTag, nLen); for (int i 0; i nLen i 32; i) { fprintf(fp, %02X , pData[i]); } fprintf(fp, \n); fclose(fp); } }跑一次登录打开 packet.log你会发现协议号在屏幕上对应的十六进制就是那串开头的两个字节。后面的改造思路基本就是从这个日志文件出发去验证自己写的包结构体偏移对不对。我后面所有协议相关的修改都强制要求先有这个日志作为对照基准。5. 避坑记录编译、运行、登录三条线的排查复盘这份代码坑很多而且坑得很有时代感。我把最常见的四类问题整理成“现象 → 原因 → 解决”三段式每条都是我在不同机器上实际遇到过的照着排查能省半天时间。5.1 编译期报错SDK 头文件互相干架光标乱跳现象编译一开始就出现几百行类似 error C2146: syntax error : missing ; before identifier PVOID64 的错误还伴随大量重定义警告看起来像是源码代码坏掉了。原因90% 是 include 顺序的问题。老代码里把 windows.h 和 winsock2.h 混在了一起且没有定义 WIN32_LEAN_AND_MEAN导致 Windows 的头文件和 Socket 头文件内部的类型定义互相覆盖。现代 SDK 对这种混用的容忍度比 2005 年低得多于是旧代码在老环境能过换到新环境就崩。解决打开 stdafx.h或工程里最早被 include 的文件在最顶部添加宏定义并固定 include 顺序// 先定义精简宏再按固定顺序引入两大头文件 #define WIN32_LEAN_AND_MEAN #include windows.h #include winsock2.h #include ws2tcpip.h5.2 运行期黑屏/花屏全屏模式是历史遗留的雷现象程序跑起来黑屏或整个屏幕变成花屏键盘操作似乎有反应能听到声音或者窗口标题在切换但画面始终不出来。笔记本上尤其频繁。原因客户端初始化 DirectDraw 时默认选择 800x600 16bit 全屏模式现代显卡的驱动在 Windows 10/11 上对老的 DDraw 全屏支持很差切不回去就黑屏了。花屏多半是调色板或者前台/后台表面切换时序问题。解决第一步搜索 DirectDraw 初始化代码里的 SetCooperativeLevel 和 SetDisplayMode 调用把全屏标志改成窗口化通常是把 DDSCL_EXCLUSIVE 换成 DDSCL_NORMAL并跳过 SetDisplayMode。第二步若还花屏找到渲染主循环里的 Lock()/Unlock() 调用确认每帧 Lock 前没有对后台缓冲做多余操作。常见做法是先强制窗口化跑通再反过来逐行看渲染调用。别忘了进程右键里设置“禁用全屏优化”也能救一部分场景但那不治本。5.3 登录卡在“正在连接服务器”蜜汁沉默的排查点现象账号密码输入后界面一直停在“正在连接服务器…”没有报错也没有画面跳转。服务端看起来开着但就是进不去。原因三类常见根因。一是客户端连接的地址或端口写死你的服务端肯定没监听那个端口。二是客户端和服务端的加密版本不一致服务端收到包后解密失败直接丢弃不再响应。三是客户端连接的是 SelGate而你服务端只开了 LoginGate。解决先用 Wireshark 抓包看客户端有没有发出 SYN 包、有没有收到服务端 ACK。如果连 SYN 都没有去代码里搜服务器 IP 常量改成实际地址如果 SYN 和 ACK 都有但客户端还在转圈那就是加密不匹配回头检查第 4.2 节里的密钥初值并确认服务端用同一套密钥。最后确认你要连的是哪个端口LoginGate 和 SelGate 不要张冠李戴。5.4 中文乱码与资源路径读取失败不是代码错是环境错现象游戏里的中文全变成乱码或者登录界面按钮图片加载不出来资源文件明明在目录里程序却提示找不到。原因老代码默认使用 ANSI/GBK 编码而现代 Windows 10/11 的默认字符集可能是 UTF-8。两套编码不匹配时硬编码的字符串资源读取路径就会指向不存在的文件名。另一个坑是路径中的中文目录名如果代码里写死了 ASCII 字符中文路径会让 WinAPI 打开文件失败。解决不推荐去改系统区域设置那个影响面太大。稳妥做法是在工程预编译头里把字符集强制为多字节见 3.2 节然后在所有文件操作入口统一封装一个路径转换函数。我自己一般会写一个代理函数把内部 char* 路径转成宽字符再交给 CreateFileA/W 系列。此外把整个客户端目录放到纯英文路径下并保持资源文件名与代码内字符串严格一致。6. 进阶玩法把这份老代码当教材的三条路径这套源码编译跑通后你能做的事远不止“运行一个老游戏”。我自己的使用习惯是把它当成协议逆向和 Windows 编程的手工教具下面三条路径是我实际走完的每一步都能验证你前面读得对不对。第一条路径把第 4.4 节的封包日志做成常态功能。给 PacketLog 增加一个开关运行时从配置读取是否打印这样你在后续改造时随时能看协议数据。别小看这一步它等于给黑匣子装了一块观察窗所有后续联调都依赖它。第二条路径用 IDA 加载编译出来的 exe再对照源码里的函数名做符号还原。老代码没有做过多混淆函数名和源码高度一致很适合用来练“源码辅助逆向”的手感。我曾经靠这套流程把某个改版客户端的登录密钥从 0xAC 改成动态轮询的完整调用链摸了出来完全是靠这两个工具。第三条路径写一个 WIL/WIX 资源读取器把素材图片批量导成 PNG。WIL 头部的格式有固定偏移读懂后你会发现这也是一份很好的二进制格式解析训练样本。做到这一步我给自己定了个规矩以后凡是拿到老代码都强制先做“编译 → 启动 → 封包打日志 → 逆向核对”的完整流程再谈改需求。这样能避免很多自以为懂了、一动手就翻车的尴尬。希望帮到你。本文还有配套的精品资源点击获取