简介全套石器时代项目源代码适合想研究经典 C 语言游戏/应用架构的开发者也适合需要参考完整工程组织方式的初学者。包内共 378 个文件以 174 个 .h 头文件和 170 个 .c 源文件为主体配合 makefile、VC6 工程文件.dsp/.dsw及 Visual Studio 解决方案.sln/.vcproj可以直观看到一套老式 C 项目的模块划分与构建方式整体仅 1.32MB便于快速下载比对。从节选内容看源码覆盖 battle、char、item、magic、npc 等核心模块适合围绕游戏逻辑、角色状态、战斗流程与消息协议做断点调试和二次开发。已有 2016 人学习下载对想深入理解 C 语言工程实践、还原早期网络游戏服务端实现的人来说是一份难得的完整参考资料。1. 这份“完整”的石器时代源代码到底能拿来做什么在怀旧游戏源码交流这个圈子里被问得最多的一句话不是“能不能跑”而是“我下载的这份完整石器时代源代码到底少了什么”。压缩包解压出来几百兆目录树看着很全一编译红字一片一启动进程秒退折腾两天连登录界面都见不到。其实“完整”从来不是以体积或文件数衡量的它等于服务端、客户端、数据库脚本、依赖环境四样东西能相互咬合。这篇笔记就是给所有打算认真复现老游戏服务端的人看的拿到一份自称完整的石器时代源码之后按什么顺序去盘它、编译它、启动它以及撞墙之后怎么排查。它的价值不在商业运营而在让你看清十年前 MMORPG 服务端是怎么把账号、场景、角色、封包串起来的看完你会觉得这波折腾很值。2. 拿到源码包先别急着编译先盘出这份包裹的边界2.1 完整性判断服务端、客户端、数据库脚本三件套缺一不可“完整”这两个字在不同人嘴里含义完全不同。有人说完整等于服务端能启动有人说完整等于能进地图打怪还有人说得自带 GM 命令。按我带别人看源码的经验真正值得花时间的包至少要同时具备三块服务端源码或二进制、对应版本的客户端、数据库初始化脚本。地图资源、封包定义、GM 工具表反而是次要的因为很多能从客户端里解出来数据库脚本如果缺失你连账号表都建不出来。拿到包以后先按下面这张表找对应目录不要被一堆 .cpp 带偏。组成部分常见目录名缺失时的典型表现服务端源码Server / LoginServer / GameServer编译不出登录服或游戏服进程客户端程序与资源Client / bin / res没有验证封包与地图表现的对象数据库脚本db / database / sql建不了账号、角色、物品表地图与场景资源map / data / scene进游戏卡在加载或黑屏封包定义文档protocol / packet / doc客户端与服务器消息对不上如果数据库脚本目录是空的别急着编译先想办法把库建起来否则后面登录服一启动就报数据库连接失败。很多所谓完整包其实只缺了脚本自己补一套基础表并不是难事。核心原则完整性的定义是“能跑成最小闭环”不是“文件覆盖有多全”。把“完整”重新理解为“能在本地跑通”比纠结压缩包体积要实际得多。2.2 老 Visual C 项目的依赖陷阱运行库、DirectX SDK、第三方库缺失石器时代这一代游戏源码最常见的工程环境是 Visual C 6.0 或早期 Visual Studio。如果你现在用新版 VS 打开工程第一关是版本转换向导第二关是平台工具集第三关是旧的 WINSOCK 库和 DirectX 库找不到。很多编译错误根本不是语法错误而是编译器不知道去哪里找 windows.h、winsock.h、ddraw.h。我见过有人把几千个 C2065 报错当成代码问题实际上把 SDK 路径加上就全好了。解决套路是优先在 Windows 虚拟机里装一个老版本 VC别用新 VS 强行转换。如果因为兼容性不得不用新 VS就手工把工程转成 CMake 或新格式但大把的 include 路径和预处理宏需要重新指。DirectX SDK 的版本也要对上老游戏客户端常用 DirectDraw缺了 DX 头文件所有图形相关文件全挂。运行库方面要装 VC6 对应的可再发行组件有些包还会依赖特定版本的 STLport、zlib 或 libpng。遇到这类问题通常不是代码错是环境错。常见依赖清单我一般照着查VC6 运行库、DirectX 8/9 SDK、Platform SDK、MySQL 客户端库、zlib、STLport。缺哪个就把哪个加入项目的 include 和 lib 路径再编译。如果看到第三方库的版本和源码里的注释不一致尽量以源码为准老代码对版本很敏感随便换个新版库可能局部正常、整体崩溃。2.3 用目录扫描代替人肉翻包先列清单再动手一个几百 MB 的源码包靠资源管理器一层层点开效率太低。我习惯先列目录树和统计各目录体积看体量分布再决定先研究哪块。比如服务端源码只有几十 MB却有一个 GB 的地图资源那关键路径很可能在资源加载和地图格式解析上而不是逻辑代码反过来如果源码有几百 MB 而数据库脚本只有几 KB就要重点看角色、物品是不是硬编码在 CPP 里改起来会麻烦得多。# 列出两层目录先看顶层结构 find . -maxdepth 2 -type d | sort # 统计每个子目录的体积找出哪里占了大头 du -sh ./*/ | sort -h # 优先找出所有数据库脚本和启动说明 find . -iname *.sql -o -iname readme* | sort这三条命令能在大约 10 秒内把一份源码包的骨架摸清。第一条看目录分层第二条看资源体量分布第三条找数据库脚本和说明文件。du 的 -h 输出人类可读体积sort -h 让最大的目录排在最后方便一眼看出大头。find 的 -iname 不区分大小写老代码里 .SQL、.sql、README 都可能存在。在 Windows 环境没有 find 和 du可以直接用 Git Bash 或 WSL 跑如果你把源码丢到 Linux 服务器上研究原样能跑。拿到新包先做这一步后面所有排查路径都会清晰很多。我自己的经验是先盘点再动手能省掉至少一个通宵。3. 把服务端跑起来编译、配置、启动的最小闭环3.1 先定环境Windows 虚拟机 VC6/VS 编译的常规选择老古董源码有一个共同特点对环境极度敏感。同样是 VC6 工程在 Windows XP 上编译可能顺滑在 Windows 10 上就报一堆地址和链接错误。所以我一般建议先搭一台干净的 Windows 虚拟机装好老版 VC再配数据库别在主力开发机上硬刚。虚拟机用桥接网络方便后面让另一台机器上的客户端连进来测试多机联调是避免“本机能跑、别人连不上”的最直接手段。判断用什么编译器的依据是目录树有 .sln/.vcproj/CMakeLists.txt 就按对应工程走只有 Makefile 和 GCC 风格源码说明作者已经搬到 Linux 上了可以直接用 Linux 环境。遇到只有老式 .dsp/.dsw 文件的包先去找 VC6 或 VS2008别拿 VS2022 硬转。语言和运行库也要统一服务端和客户端如果一边用 ANSI 字符串、一边用 Unicode日志会全是乱码。选型还有一个隐藏点数据库版本。老源码多数配 MySQL 5.x连接库是 libmysql.dll 的老版本。如果装 MySQL 8客户端连接库不兼容即使配置写对了也可能报“无法加载认证插件”。我常备一个 MySQL 5.7 的绿色版专门用来跑老游戏服务端。这一步定好了后面 SQL 脚本导入才不会被版本卡住。3.2 数据库初始化建库、建表、导入基础数据的 SQL 套路服务端跑起来前必须先把数据库准备好。哪怕包里带了脚本我也建议先手动建一个库确保字符集和表结构符合预期。老源码有很多把中文内容硬编码在脚本里字符集选错后面进游戏全是乱码。常见做法是新建一个独立库表名前缀和源码里写死的前缀保持一致。-- 建库字符集按源码要求选拿不准先用 utf8mb4 CREATE DATABASE IF NOT EXISTS sa_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE sa_db; -- 账号表存登录凭据和 GM 权限 CREATE TABLE account ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, username VARCHAR(32) NOT NULL, pass_hash CHAR(32) NOT NULL DEFAULT , gm_level TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 0普通玩家1普通GM9超级GM, create_time TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 角色表最核心字段就是所在地图和坐标 CREATE TABLE role ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, account_id INT UNSIGNED NOT NULL, name VARCHAR(32) NOT NULL, map_id INT UNSIGNED NOT NULL DEFAULT 1000, x SMALLINT UNSIGNED NOT NULL DEFAULT 100, y SMALLINT UNSIGNED NOT NULL DEFAULT 100, level SMALLINT UNSIGNED NOT NULL DEFAULT 1, PRIMARY KEY (id), UNIQUE KEY uk_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这两张表只是老式 MMORPG 最基本的轮廓实际源码包里的字段会多得多有任务状态、宠物信息、装备栏等。拿到完整脚本时优先用原脚本这里只解决“没有任何 sql 文件”时怎么起步。核心参数gm_level 决定 GM 命令是否理会你map_id、x、y 是角色登录后的落点建角色时必须给初始值否则会出生在 (0,0) 导致客户端卡死。账号表的主键和唯一键也要提前想好登录服会按 username 查库。注意导入脚本前先看表前缀有些源码要求sa_account、login_account之类别把表名写死成自己的。如果源码里用了存储过程MySQL 版本要支持老存储过程在 5.7 上通常没问题。导入完成后用一条 SELECT 验证账号表能查到数据再启动服务端。3.3 服务端启动顺序和三个必调参数监听端口、数据库连接、GM 开关服务端不是只有一个进程老游戏常见会拆成登录服和游戏服。启动顺序基本固定先数据库再登录服等登录服监听端口出来再开游戏服。顺序错了游戏服连不上登录服日志里会一直刷连接失败。排查启动问题时第一步永远是看进程在不在第二步是看端口有没有起来第三步才是翻日志。[login] listen_ip 0.0.0.0 listen_port 9001 max_connections 200 [game] listen_ip 0.0.0.0 listen_port 9002 login_host 127.0.0.1 login_port 9001 db_host 127.0.0.1 db_port 3306 db_user sa_user db_pass sa_pass db_name sa_db这份配置是我按老端习惯写的示例重点是三个参数。第一个是 listen_ip必须设成 0.0.0.0设成 127.0.0.1 就只能本机连第二个是 db_host/db_user/db_pass数据库连接串写错登录服启动直接退第三个是 GM 开关一般在 game 段里单独开没开的话游戏里敲 GM 命令没有反应。老源码有很多配置项是编译期常量改 ini 不一定生效查不到时就去源码里搜端口号和数据库名。启动后验证端口# Windows 下确认端口监听 netstat -ano | findstr :9001 # Linux 下确认 ss -ltnp | grep 9001看到监听说明登录服已经起来接下来用客户端连。如果端口没出现多半是配置里的数据库连接失败进程起来又自杀。日志文件比控制台输出可靠老代码喜欢把错误写进 log 目录按时间戳找最新日志。启动闭环跑通后才算真正进入客户端调试环节。4. 客户端连不上从登录封包到地图资源把链路拆开看4.1 客户端和服务端的握手流程登录验证、角色列表、进入地图客户端不是一上来就发封包的。老游戏的做法通常是客户端先请求服务器列表拿到登录服地址端口然后 TCP 连上登录服发账号密码登录服查库后返回结果客户端再拿着登录票据去连游戏服拉角色列表选择角色后进入地图。这个链路上任何一环断开表现都只是“连接失败”很难看出是哪一步挂了。所以遇到连不上我会按顺序打点服务器列表能不能拉到登录服端口通不通账号密码能不能通过游戏服端口通不通地图资源能不能加载。日志和抓包工具是两大利器。用 Wireshark 的过滤器tcp.port 9001直接看三包交互先观察有没有数据回复再分析内容。如果没有抓包条件就看服务端日志里在哪个阶段断掉日志是源码给你的免费调试信息。老游戏封包不是简单的“长度 协议号”很多会在包头上再做一层加密、压缩或混淆。第一次抓包看到前几个字节不是明文别慌可能只是这一代端的加密方式先确认链路通不通再研究怎么解码。加密层的调试要放到后面别一上来就卡在解密上。4.2 用 Python 写一个最小封包观察器看请求与响应的链路我习惯用 Python 快速验证服务端端口的行为比反复启动客户端工程省时间。下面这段代码就是一个最小的封包观察器连接登录端口发送一个按长度前缀封装的请求包读取服务端返回的原始字节并打印十六进制。它不做解密只确认链路和数据层有没有响应。import socket import struct def recv_exact(sock, n): 读满 n 个字节缺一个字节都不返回 buf b while len(buf) n: chunk sock.recv(n - len(buf)) if not chunk: raise ConnectionError(连接被对端关闭) buf chunk return buf def read_packet(sock): 读取一个标准长度前缀封包前2字节等于总长度 head recv_exact(sock, 2) (total,) struct.unpack(H, head) # 小端无符号短整数 if total 2: raise ValueError(f非法包长: {total}) body recv_exact(sock, total - 2) return body sock socket.create_connection((127.0.0.1, 9001), timeout3) # 构造一个最小请求包协议号 定长账号 定长密码 # 真实协议差异很大这里只是演示跑通前先看有没有回包 proto b\x01\x00 username bA * 8 password bB * 8 body proto username password packet struct.pack(H, len(body) 2) body sock.sendall(packet) try: resp read_packet(sock) except TimeoutError: print(超时服务端没回包检查端口和监听IP) else: print(响应字节数:, len(resp), 前16字节:, resp[:16].hex()) sock.close()代码里的 read_packet 是通用长度前缀封包读取适合所有“前两字节为长度”的协议。struct.unpack(H, head) 按小端序解出无符号短整数total 是整个包的长度所以 body 要再读 total-2 字节。如果服务端用大端序就要把改成。这个观察器的价值在于它把网络调试从“客户端 服务端 资源包”的大系统里剥离出来只留下最原始的 TCP 数据能立刻判断是服务端没回包还是客户端处理不了。超时并不代表协议不对也可能只是服务端收包后主动断开要多打印 recv 的原始异常。把这套脚本扩展成循环抓包再配合数据库日志通常能很快定位登录阶段的问题。脚本里端口、协议号、账号字段长度都要按实际源码改别拿示例数据直接套生产包。4.3 地图和战斗资源缺失的典型表现客户端卡在“载入中”登录验证过了角色列表也能看到一进游戏就卡在载入中这是最典型的资源缺失症状。原因通常有三个客户端资源包里没有对应地图 ID 的地图文件地图文件在但格式不被客户端识别服务端下发的初始地图 ID 和客户端资源目录对不上。表现都一样但排查方向不同。先查角色表里的初始 map_id 是不是存在的地图编号。很多老端出生点是 1000如果你把角色表里的默认地图设成 1001而客户端没有 1001 的资源就会一直转圈。把 map_id 改回一个确定可用的编号比如 1000再重新登录测试这是最快的一招。如果是地图格式问题就得找地图编辑器或服务端源码里的地图导出工具检查资源和客户端的版本是否配套。战斗资源缺失一般是战斗动画文件缺客户端会在进入战斗时闪退或黑屏体现得比地图更晚。地图这一块是很多源码包“完整”承诺里最脆弱的环节。有些包为了减小体积会把 res 目录里的高材质清掉只留低清版看起来还能跑但一换地图就报错。遇到这种问题要尽量先找回配套客户端别急着改代码。地图 ID、地图文件格式、客户端资源版本三个条件都对齐才能安然进图。5. 避坑编译、启动、连线的五个常见问题5.1 编译报错 [C2065]未声明标识符实际是平台工具集和依赖没对齐现象一编译就是几百条 error C2065报的还都是系统 API比如 CreateWindow、WSAStartup、DDraw 相关的函数未声明。看起来像源码缺文件实际上大多是编译器找不到 Windows SDK 的 include 路径和库路径。VC6 的默认 SDK 路径和后来的 Visual Studio 不一样老工程在 VS2022 里打开平台工具集会变成 v143头文件路径全部偏移。原因代码没变是依赖没对齐。解决方法是把平台工具集改回 v100 或 v120 再编译或者手动在工程属性的“VC 目录”里补上 Windows SDK 的 include 和 lib 路径。如果还不行确认是否装了 DirectX SDK并把 DX 的 include/lib 放到搜索路径的最前面。记住一条C2065 大爆发时先怀疑环境再怀疑代码。5.2 启动后进程秒退先查配置不是先查代码现象登录服或游戏服进程双击后窗口一闪就没了没有任何弹窗报错。新手最容易一头扎进源码里找 main 函数其实老服务端的 main 通常很短真正决定生死的是配置加载。配置里数据库连不上、必要文件不存在、监听端口被占用都会导致进程自己退出而窗口一闪就看不到日志。原因日志被写到 log 目录控制台窗口关闭了不代表没记录。解决先看 log 目录下最新日志文件按时间戳排序找最后几行。典型报错是 “connect database failed”、“open profile failed”、“bind port failed”。然后回配置改而不是改代码。我通常会把进程从命令行启动而不是双击这样退出前打印的堆栈还能留在终端里。5.3 本机能登录、局域网连不上监听地址写死了 127.0.0.1现象同一台机器上客户端能登录放到另一台电脑上就提示“无法连接服务器”。原因非常典型服务端配置里的 listen_ip 是 127.0.0.1服务只绑了回环地址外面的机器当然连不进来。有些源码还会在代码里写死 socket bind 的地址配置文件根本没生效。解决把配置里 listen_ip 改成 0.0.0.0再检查服务端防火墙有没有放行对应端口。如果改配置没用就在源码里搜 “127.0.0.1” 和 “INADDR_LOOPBACK”很可能有个常量写死在 init 函数里。改完重新编译用 netstat 确认监听地址变成 0.0.0.0 而不是 127.0.0.1。这个问题是联调中最高频的优先级排很高。5.4 账号能建、进不去地图数据库字符集把中文地图名搞成乱码现象账号能创建角色也能选但一进地图就断开或卡住服务端日志里地图名是一串问号。原因多半是数据库字符集不一致。老脚本用 latin1 写入的中文你在建库时用了 utf8mb4读取时按 utf8 转码变成乱码地图查不到角色自然进不去。或者反过来源码连接串里没指定 charsetMySQL 连接默认用了错误字符集。解决先看脚本开头有没有 SET NAMES 或者 DEFAULT CHARSET 声明保持建库、脚本、连接串三者字符集一致。最简单的方法是重建库严格按脚本里的 charset 来如果脚本没有明确声明先用 latin1 试再用 utf8mb4 试。登录服连接串里加上 charsetutf8mb4 或 charsetlatin1和库一致。改完清掉角色表重来别在脏数据上反复试。5.5 GM 命令无效不是功能没写是权限号没赋现象游戏里敲 GM 命令没反应或者提示“无权限”源码里明明看到 GM 函数实现。原因通常是账号表里 gm_level 是 0服务端校验权限不通过。有的端还分普通 GM 和超级 GM命令要求 9你给 1 它照样不理。解决直接在数据库里把账号 gm_level 改成源码要求的数值改完重启登录服让权限缓存刷新。如果改了还是无效去源码里搜 GM 命令的权限常量确认服务端读哪张表哪个字段重点看它读的是 account.gm_level 还是角色表里一个独立字段。权限字段赋值后要让客户端也重新登录很多权限是在登录时写入内存的不是每发一次命令查一次库。6. 收尾进阶玩法——改经验倍率、加物品、换地图名以及一条保命原则6.1 改经验倍率在数据库参数表里做乘法不在代码里做加法跑通之后大多数人第一件事是改经验倍率让自己爽一下。常见做法是找到经验费率表或全局配置表比如 exp_rate 或者 rate把杀怪经验值做乘法。我一般建议在数据库层做因为老源码结构不熟动代码容易把公式改崩。-- 假设有全局参数表先查一下当前倍率 SELECT * FROM exp_rate WHERE map_id 0; -- 把经验倍率从 1 改成 10 UPDATE exp_rate SET exp_rate 10 WHERE map_id 0;注意有些端是“基础经验 × 倍率 × 组队加成”改完倍率后数值变化很大别人可能无法复现。所以先在单人地图验证确认角色的经验数值符合预期再决定是否全局改。改完要重启游戏服很多倍率参数只在启动时加载一次。6.2 新增物品从模板表到掉落表的三个地方要同步新增一个物品不是只往 item 表插一行老端通常要同时处理三处物品模板表、掉落表、客户端资源里的图标和说明。三处缺一处要么物品看不见要么捡起来是问号。-- 1. 物品模板表定义 ID、名称、类型、堆叠上限和售价 INSERT INTO item_template (id, name, type, max_stack, sell_price) VALUES (90001, 测试纪念品, 1, 20, 100); -- 2. 掉落表把新物品挂到某个 NPC 上drop_rate 是权重 INSERT INTO npc_drop (npc_id, item_id, drop_rate) VALUES (10101, 90001, 5); -- 3. 记得更新物品描述表否则客户端显示空白 INSERT INTO item_desc (item_id, desc_text) VALUES (90001, 本地学习用的测试物品);这里的表名和字段是按通用结构举例实际端可能用 item_data、drop_list、item_extra 之类的名字先在源码里确认。加物品最怕的是 ID 冲突建议从 90000 开始加避免覆盖原版 ID。如果在客户端看不到图标则是资源表的问题别在数据库里反复折腾。6.3 版权红线学习、复原、写技术文章可以但别拿它做运营最后一条是保命原则。这类老游戏源代码和历史资源绝大多数有著作权归属你可以用它做本地学习、做服务端架构复盘、写技术文档但不要拿去开服运营也不要公开传播完整客户端和服务端资源。公开的源码包本身来源模糊我自己的习惯是只保留少量必要代码做笔记完整包放在不联网的虚拟机里研究文章里只贴原理和关键片段不打包分享。折腾老源码的过程让我养成了拿到任何项目先盘目录、再配环境、后跑闭环的习惯。这个习惯帮我少走很多弯路。这篇笔记如果能让你少掉几根头发那我也算没白写希望帮到你。本文还有配套的精品资源点击获取