简介：传奇模拟游戏源代码包面向具备C++基础、希望理解游戏客户端与服务器完整实现流程的开发者，采用VC++6.0编写，包含可参考的客户端与服务器端工程。压缩包共499个文件，以h头文件、cpp源文件为主，并含obj、sbr等编译中间文件及vcproj、dsw、dsp等工程配置，整体约11.32MB，便于按客户端界面渲染、服务器逻辑处理与工程组织等模块对照阅读。已有218人学习。读者可从中梳理角色控制、场景渲染、玩家状态同步、规则执行与数据存储等环节的实现思路，接触网络通信、多线程、数据结构与性能优化等主题，并借助客户端请求与服务器响应的实际案例加深对并发编程和数据封装传输的理解，适合作为游戏开发入门与旧项目维护的实践参考。对希望进入游戏服务端开发或维护早期VC++工程的读者较有参考价值。

1. 传奇类模拟游戏的双端源码，真不是编译一下就能玩

传奇类模拟游戏的双端源码，最容易被人低估成「玩具工程」：下载下来看目录，客户端一堆贴图和 UI 文件，服务端几个 C++ 工程，看着像是随手编译就能跑。真上手才知道，登录链路、地图线程、封包校验任何一处没对上，你就只能盯着登录界面转圈，还分不清是客户端资源没挂上还是 C++ 服务器端口没起。这份资源给的是客户端与服务器源程序两套完整工程，服务端走多进程加网络库的老派写法，客户端是渲染循环加强制资源索引的结构。它适合两类人：想搞明白老式 MMO 服务端怎么把成百上千玩家塞进几十个地图线程的，以及想拿一套能跑的双端骨架改成自己玩法的。下面按「它给了什么 → 怎么跑起来 → 核心代码怎么写的 → 卡住怎么查 → 怎么加功能」的顺序往下拆。

2. 双端架构拆解：一个移动请求从网关走到地图线程的完整链路

先把整体链路摆出来，不然看代码会很虚。客户端从登录服拿到票据，拿着票据去连网关，网关只做连接保持和转发，真正处理逻辑的是游戏服，游戏服里再按地图切成多个线程。玩家点一下地面，这个移动指令要经过：客户端封包 → 网关透传 → 游戏服收包队列 → 对应地图线程出队 → 校验坐标 → 九宫格广播 → 结果回包。整条链上一个环节出问题，表现都是「人物不动」，这也是排查时最费劲的地方。

2.1 服务端进程拓扑与源码目录

四类进程各管一摊：登录服管账号和区服列表，网关管长连接和限流，游戏服管地图、玩家、战斗，工具目录放配置表导出和封包生成脚本。这么拆的理由很实际——游戏服崩了不能把登录也带垮，登录服重启也不该让在线玩家掉线。共享的东西只有一份：协议头、枚举、错误码，放在 Share 目录里被双端同时引用。

Server/ ├── Common/ # 公共库：Socket 封装、环形缓冲区、日志、定时器 │ ├── Net/ │ ├── Log/ │ └── Timer/ ├── LoginSrv/ # 登录服：账号校验、区服列表、票据签发 ├── GateSrv/ # 网关：连接维护、票据二次校验、报文转发 ├── GameSrv/ # 游戏服：地图线程、玩家实体、战斗、掉落 │ ├── Map/ │ ├── Battle/ │ └── Item/ ├── Tool/ # 配置表导出、协议代码生成 └── Share/ # 双端共用：packet.h、errcode.h、enum.h Client/ ├── Engine/ # 渲染、输入、音频、资源加载 ├── Game/ # 场景、角色、UI、网络回调 └── Res/ # 地图掩码、角色图集、配置二进制

目录结构里最该先看的是Share/packet.h，它决定了双端能不能对上话；其次是GameSrv/Map/，服务端绝大多数逻辑都压在那边。我一般拿到这种工程，先按目录大小排序看一眼，哪个模块文件最多，基本就是这项目的重心所在。

2.2 封包协议：包头、序列号与粘包处理

老派 MMO 的协议设计很朴素：定长包头加变长包体，包头里带总长度，收包方按长度切。这里容易翻车的是字节序和长度校验——客户端是小端，服务端如果跨平台不做转换，读出来的长度就是天文数字，接收缓冲区瞬间被撑爆。

// Share/packet.h：所有报文共用的包头，1 字节对齐，禁止编译器填充 #pragma pack(push, 1) struct PacketHeader { uint16_t size; // 整包长度，含包头本身，上限 64KB uint16_t cmd; // 命令字，登录、移动、战斗各占一段号段 uint32_t seq; // 序列号，客户端递增，服务端用于防重放和回包匹配 uint32_t checksum; // 包体校验，早期用累加和，现在多为 crc32 }; #pragma pack(pop) static_assert(sizeof(PacketHeader) == 12, "header size changed");

size是整个包的总长度，服务端收到数据先判断够不够 12 字节，不够就等下一批；够了再按size取整包，这就把 TCP 粘包问题在协议层解决掉了。seq有两个作用，一是服务端按序列号丢弃重复包，二是客户端回包匹配，避免异步响应乱序。static_assert那行是血泪经验：某次有人往包头里加了个字段没同步客户端，双端结构体大小差了 4 字节，所有包解析全错位，表现是「登录后角色列表一片空白」，查了整整一下午。

收包侧一般配一个环形缓冲区，读指针和写指针分开：

// Common/Net/Buffer.cpp：环形缓冲区，避免每次 recv 都做内存搬移 bool RingBuffer::TryPopPacket(Packet& out) { if (readable() < sizeof(PacketHeader)) return false; // 头都不够，等 PacketHeader hdr; Peek(&hdr, sizeof(hdr)); if (hdr.size < sizeof(PacketHeader) || hdr.size > kMaxPacket) { return false; // 长度非法，交由上层断开 } if (readable() < hdr.size) return false; // 半包，等下一批 out.resize(hdr.size); Read(out.data(), hdr.size); // 只在整包到齐时搬一次 return true; }

kMaxPacket建议设成 32KB 以内，超过这个值的包要么是协议设计有问题，要么是有人在往服务端灌垃圾数据。这个函数返回 false 有两种语义——「数据不够」和「数据非法」，上层必须区分开：前者继续等，后者直接断连接，否则一个畸形包能让线程空转。

2.3 客户端结构：渲染循环、场景管理与资源挂载

客户端是典型的「固定帧率主循环 + 逻辑插值」写法，渲染帧和逻辑帧不绑死。逻辑帧跑 20 次每秒，负责发移动指令、处理服务端回包；渲染帧跟着显示器刷新率走，中间用插值补出平滑位移。老派 2D MMO 基本都这么干，好处是网络包少，坏处是插值参数调不好会看到角色「滑步」。

// Client/Game/MainLoop.cpp：逻辑帧与渲染帧解耦 void GameLoop() { const int64_t kLogicStepMs = 50; // 逻辑帧 20fps int64_t last_logic = NowMs(); while (!quit_) { int64_t now = NowMs(); // 1. 逻辑帧：固定步长推进，网络包在这里消费 while (now - last_logic >= kLogicStepMs) { net_.Poll(); // 收包，回调进场景 scene_.Tick(kLogicStepMs); // 移动预测、动画状态机 last_logic += kLogicStepMs; } // 2. 渲染帧：按真实时间插值，不碰网络 float alpha = float(now - last_logic) / kLogicStepMs; renderer_.Draw(scene_, alpha); input_.Swap(); } }

alpha是插值系数，取值 0 到 1，渲染时用「上一逻辑帧位置 + (当前位置 - 上一位置) * alpha」算出显示坐标。这个值如果直接用now - last_logic不除步长，角色移动速度会跟着显卡帧率变，帧率越高跑得越快——这种玄学 bug 我在不止一个工程里见过。

资源挂载这块，客户端启动时会先读Res/data/下的索引文件，把每个资源 ID 映射到具体文件偏移，之后按需加载。所以资源目录和可执行文件必须是同级关系，挪了位置就找不到索引，表现是进游戏黑屏但进程不崩。

3. 编译与首次启动：从 CMake 到进图的三段式流程

这套工程不像现代项目那样一条命令全自动，首次跑通要分三段：先把服务端依赖配齐编出来，再初始化数据库和配置表，最后编客户端并保证资源目录结构正确。三段里任何一段跳步，后面都会以一种很奇怪的方式失败。我按自己实际操作的顺序写，命令可以直接抄。

3.1 服务端依赖、CMake 配置与编译参数

服务端依赖不多：C++17 编译器、CMake 3.16 以上、线程库、MySQL 客户端库。Linux 上装build-essential cmake libmysqlclient-dev，Windows 上用 vcpkg 拉 mysql-connector-c 或者直接用官方安装包里的 lib。CMakeLists 的关键是把公共库编成静态库再链接，别把所有 cpp 塞进一个可执行目标，不然改一行日志要全量重编。

cmake_minimum_required(VERSION 3.16) project(gamesrv CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # RelWithDebInfo 是为了线上出问题时还能看栈，别用 -O3 裸奔 add_compile_options(-O2 -g -Wall -Wextra) find_package(Threads REQUIRED) find_package(mysqlclient REQUIRED) add_library(common STATIC Common/Net/Socket.cpp Common/Net/Buffer.cpp Common/Log/Logger.cpp) target_include_directories(common PUBLIC Common Share) add_executable(loginsrv LoginSrv/Main.cpp LoginSrv/Account.cpp) add_executable(gatesrv GateSrv/Main.cpp GateSrv/Forward.cpp) add_executable(gamesrv GameSrv/Main.cpp GameSrv/MapThread.cpp GameSrv/Battle.cpp) target_link_libraries(loginsrv PRIVATE common Threads::Threads mysqlclient) target_link_libraries(gatesrv PRIVATE common Threads::Threads) target_link_libraries(gamesrv PRIVATE common Threads::Threads mysqlclient)

三个可执行目标分别对应三个进程，common被重复链接没关系，静态库会把用到的符号各拷一份，进程之间互不影响。-Wall -Wextra建议一直开着，这种老代码里藏着不少「有符号和无符号比较」的隐患，等到线上数值溢出再查就晚了。

编译和启动：

# 1. 生成构建目录，RelWithDebInfo 兼顾优化和调试信息 cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo # 2. 并行编译，nproc 是核数，Windows 换成 %NUMBER_OF_PROCESSORS% cmake --build build -j"$(nproc)" # 3. 先起登录服，再起网关，最后起游戏服，顺序不能反 ./build/loginsrv -c conf/login.ini ./build/gatesrv -c conf/gate.ini ./build/gamesrv -c conf/game.ini

启动顺序是有讲究的：游戏服启动时要向网关注册自己负责的区服，网关启动时要连登录服拿区服列表。顺序反了，游戏服注册失败会静默退出，日志里只有一行「register timeout」，很多人第一次就是这么卡住的。

3.2 数据库初始化与配置表落地

账号和角色数据落 MySQL，建库建表脚本一般在Tool/sql/下。字符集一定要显式指定utf8mb4，不然玩家角色名带 emoji 或者生僻字，插入直接报错，客户端上表现为「创建角色失败」但没有任何提示。

CREATE DATABASE IF NOT EXISTS game_db DEFAULT CHARSET utf8mb4; USE game_db; CREATE TABLE account ( uid BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, account VARCHAR(32) NOT NULL, pwd_hash CHAR(64) NOT NULL, -- sha256(salt + pwd)，绝不存明文 salt CHAR(16) NOT NULL, -- 每个账号独立盐值 created_at INT UNSIGNED NOT NULL, UNIQUE KEY uk_account (account) ) ENGINE=InnoDB; CREATE TABLE player ( pid BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid BIGINT UNSIGNED NOT NULL, name VARCHAR(24) NOT NULL, job TINYINT UNSIGNED NOT NULL DEFAULT 0, level SMALLINT UNSIGNED NOT NULL DEFAULT 1, map_id INT NOT NULL DEFAULT 1, x SMALLINT NOT NULL DEFAULT 100, y SMALLINT NOT NULL DEFAULT 100, KEY idx_uid (uid) ) ENGINE=InnoDB;

uk_account是唯一索引，注册时靠它挡重复账号，别在代码里先查再插，并发下必穿透。player表的idx_uid也必须有，登录后拉角色列表是按 uid 查的，没索引在几百个角色时就开始慢。

配置表走的是「Excel/CSV 导出成二进制」的路子，导出工具在Tool/下，产物丢进Client/Res/data/和服务端的conf/data/，两边必须是同一次导出的结果，否则会出现「客户端显示技能伤害 100，服务端算出来 80」这种对不上的情况。

3.3 客户端编译与资源挂载顺序

客户端同一套 CMake 流程，编完把可执行文件放到资源目录同级。资源目录的层级不能随便改，代码里是按相对路径拼的：

# 客户端目录结构，exe 与 Res 必须同级 Client/ ├── game.exe ├── conf.ini # 服务器 IP、端口、分辨率 └── Res/ ├── data/ # 配置表二进制，和服务端同一次导出 ├── map/ # 地图掩码，文件名为 map_id.map ├── chr/ # 角色动作图集，按 job 分目录 └── ui/ # 界面布局和贴图

conf.ini里的服务器地址别写死127.0.0.1就以为完事——很多工程是登录服返回区服列表，列表里的 IP 是服务端配置里写死的，客户端拿到的还是内网地址。局域网内测没问题，一旦换机器就全连不上。我一般会把gate_ip做成配置项，而不是编译期常量。

4. 核心模块精读：登录鉴权、地图广播、战斗结算三段代码

服务端代码量不小，但真正决定「能不能玩」的就三段：登录怎么验、移动怎么同步、伤害怎么算。这三段看懂，剩下的背包、任务、商店基本都是同一套模板套出来的。下面每段代码都保留了关键注释，参数含义我会在代码后单独说。

4.1 登录服：账号校验与一次性票据下发

登录服的职责很单一：验账号密码，发一张短时效票据，把网关地址告诉客户端。密码校验绝不能明文比对，也不能用固定盐，工程里用的是每账号独立盐值加 SHA-256。

// LoginSrv/Account.cpp：处理登录请求 bool HandleLoginReq(Session* s, const LoginReq* req) { // 1. 字段合法性校验，长度异常直接丢包，别进业务 if (req->account_len == 0 || req->account_len > 32) return false; // 2. 频率限制：同一连接 60 秒内最多 5 次，防撞库 if (!s->rate_limiter.Allow(5, 60)) { s->Close(); return false; } AccountInfo info; if (!db_.QueryAccount(req->account, &info)) { s->SendAck(ERR_ACCOUNT_NOT_EXIST); return true; // 业务失败不断连接，让客户端提示 } if (Sha256(info.salt + req->password) != info.pwd_hash) { s->SendAck(ERR_PASSWORD); return true; } // 3. 签发票据，30 秒有效，网关拿它去游戏服换正式会话 std::string ticket = token_gen_.Issue(info.uid, /*ttl_sec=*/30); LoginAck ack{}; ack.code = 0; ack.gate_ip = cfg_.gate_ip; // 从配置读，别写死 ack.gate_port = cfg_.gate_port; std::snprintf(ack.ticket, sizeof(ack.ticket), "%s", ticket.c_str()); s->Send(ack); return true; }

rate_limiter.Allow(5, 60)是滑动窗口，前两个参数分别是次数和秒数，调小能挡撞库但会误伤弱网重试的玩家，我一般先设 10 次 60 秒观察日志再收紧。返回值语义要特别注意：协议错误返回 false 断连接，业务失败返回 true 保留连接——客户端要在这条连接上收错误码做提示，断掉就只剩「连接已断开」这一句废话。

票据有效期只有 30 秒，是为了防止有人抓包重放。网关收到票据后向游戏服校验一次并立刻作废，同一张票第二次用直接拒绝。

4.2 地图线程：九宫格 AOI 与移动广播

游戏服按地图切线程，一张地图上的所有玩家实体只归一个线程管，天然无锁。跨线程通信靠消息队列，不做共享内存。AOI 用九宫格，玩家只关心自己周围 3×3 个格子里的实体。

// GameSrv/MapThread.cpp：移动处理，全程在本线程内，无锁访问 void MapThread::OnPlayerMove(uint32_t pid, int16_t x, int16_t y) { Player* p = players_.Find(pid); if (!p) return; // 1. 只允许走到相邻格，挡住了加速外挂最常见的「一步跨半屏」 if (std::abs(x - p->x) > 1 || std::abs(y - p->y) > 1) return; if (!map_.CanStand(x, y)) { p->SendSyncPos(); return; } // 撞墙回拉 const int old_cell = map_.CellIndex(p->x, p->y); const int new_cell = map_.CellIndex(x, y); p->dir = DirOf(p->x, p->y, x, y); p->x = x; p->y = y; if (old_cell == new_cell) { // 2. 格内移动：只广播给同格，省带宽 BroadcastToCell(new_cell, MoveNotify{p->id, x, y, p->dir}, pid); } else { // 3. 跨格：先重算九宫格观察者，再向新视野广播 map_.UpdateObserver(p, old_cell, new_cell); BroadcastToNineGrid(new_cell, MoveNotify{p->id, x, y, p->dir}, pid); } }

DirOf算出朝向，客户端拿去做动画播放，服务端自己不关心表现。BroadcastToCell的最后一个参数是「排除自己」，自己的移动客户端已经做了本地预测，回包再发一次会看到角色抖一下。

UpdateObserver是 AOI 的核心：玩家从 A 格走到 B 格，A 格视野内的人要收到「该实体消失」，B 格视野内的人要收到「该实体出现」。这个函数写漏了，表现就是「走到别人旁边看不见人，走远了反而冒出来」——典型的视野残留。

4.3 战斗与掉落：伤害结算和权重表

伤害公式走的是「配置驱动」，系数全在技能表里，代码只负责固定流程。这样改数值不用重编服务端，改表重启就行。

// GameSrv/Battle.cpp：一次物理攻击的结算 DamageResult CalcDamage(const Actor& atk, const Actor& def, int skill_id) { const SkillCfg& sk = cfg_.skill[skill_id]; // 1. 命中率夹在 [5, 95]，避免出现绝对命中和绝对闪避 const int hit = Clamp(atk.hit - def.dodge, 5, 95); if (rng_.Rand(100) >= hit) return {0, false}; // 2. 基础伤害 = 攻击*系数 - 防御*减伤，至少造成 1 点 int64_t base = (int64_t)atk.attack * sk.power / 100 - (int64_t)def.defense * sk.def_rate / 100; base = std::max<int64_t>(base, 1); int64_t dmg = base * rng_.Rand(sk.rand_min, sk.rand_max) / 100; // 3. 暴击最后乘，保证数值上限可预期 const bool crit = rng_.Rand(100) < atk.crit; if (crit) dmg = dmg * 150 / 100; return {(int32_t)dmg, crit}; }

sk.power是百分比系数，100 表示一倍攻击力；sk.def_rate是防御减伤比例，设 50 就是防御值的一半参与减伤。中间用int64_t是必须的——攻击和系数都上万时，32 位中间结果会溢出成负数，表现是「打高级怪给自己加血」，这种 bug 光看公式看不出来。

掉落的权重表按累计权重取：

// 权重表按顺序累加，随机数落在哪个区间就掉哪件 int RollDrop(const std::vector<DropEntry>& table) { int total = 0; for (const auto& e : table) total += e.weight; if (total <= 0) return 0; int r = rng_.Rand(1, total); // 闭区间 [1, total] for (const auto& e : table) { if (r <= e.weight) return e.item_id; r -= e.weight; } return 0; }

rng_必须是地图线程私有的随机数引擎，别用全局rand()。多线程共用一个rand()序列，一是会有数据竞争，二是每次重启掉的装备顺序都一样，玩家很快就能摸出规律。我习惯用std::mt19937加线程 id 混种子。

5. 排查清单：五类让你卡在登录界面或进图黑屏的问题

这类工程的问题有个共同特征：现象和原因隔得很远。下面五条是我自己踩过、也在别人机器上复现过的，按「现象 → 原因 → 解决」写，遇到类似表现可以直接对照。

5.1 连接与登录阶段的典型现象

现象一：客户端提示「连接服务器失败」，服务端日志干净得像没人来过。原因基本是客户端连的地址和网关实际监听的不一致，或者网关进程根本没起来。老工程里gate_ip常常写死在配置表里，客户端拿到的是内网 IP，换了机器就连不上。解决：先在本机telnet 127.0.0.1 7000确认端口通，再看conf/gate.ini里的listen_port和登录服返回的gate_port是不是同一个值，最后检查防火墙。

现象二：账号密码输对了，提示「账号不存在」。不是数据库没连上，就是库连上了但连错了库。很多工程把数据库名写在 ini 里，默认值和建表脚本里的库名不一致，查询永远返回空。解决：把服务端启动日志里的数据库连接串打出来看一眼，SHOW DATABASES确认库在，SELECT COUNT(*) FROM account确认数据在。

现象三：登录成功，角色列表一直转圈。票据校验过了但角色数据拉不出来，最常见是player表缺idx_uid索引加上数据量大，或者字段类型和代码里的结构体对不上——比如代码里level是int32，表里建成tinyint，读取时按 4 字节解析就越界了。解决：开慢查询日志，把角色加载那条 SQL 单独拿出来在客户端执行一遍，看耗时和返回类型。

5.2 进图之后的行为异常与内存问题

现象四：进图黑屏，人物能操作但什么都看不见。资源没挂上。要么Res/map/下缺map_id.map文件，要么配置表导出的是新版本、客户端用的还是旧索引。解决：看客户端日志里加载地图时打印的文件路径，手动确认文件存在；再对比Client/Res/data/和服务端conf/data/的文件修改时间，不一致就重新导一次。

现象五：服务端跑几个小时内存一直涨，重启就好。典型是实体析构没清干净。玩家下线时从players_里删了，但 AOI 观察者列表、技能冷却表、Buff 列表里还挂着裸指针，对象池回收不了。解决：给玩家实体加个引用计数，下线走统一销毁流程；再挂个定时任务，每 10 分钟打印一次各容器的size()，哪个只涨不降就查哪个。

提示：排查这类问题别急着改代码，先把日志级别开到 debug，把收包命令字和玩家 id 打出来。八成问题看一眼日志就能定位，剩下两成再动调试器。

6. 二次开发：给这套双端骨架加一套 Buff 系统

想验证自己有没有吃透这套双端结构，加一套 Buff 系统是最好的练手。改四处：配置表、实体结构、属性计算、协议同步。

配置表加一张buff表，字段至少要有id、duration_ms、stack_max、attr_key、attr_value、tick_ms。stack_max控制叠加上限，attr_key指向属性枚举，别用字符串匹配，性能和可读性都差。

实体上挂一个实例列表，用到期时间戳驱动，不要给每个 Buff 建一个定时器：

// GameSrv/Buff.h：Buff 实例，靠地图线程的 tick 统一驱动 struct BuffInst { int cfg_id; // 对应 buff 表主键 int64_t end_ms; // 绝对到期时间，判断时和当前时间比 int stack; // 当前层数，超过 stack_max 不再叠加 uint32_t caster_pid; // 施放者，用于结算归属 int64_t next_tick_ms; // 持续伤害类 Buff 的下次结算时间 };

属性计算要分阶段：基础属性 → 装备加成 → Buff 加成 → 临时增益，每阶段算完缓存，标记脏了才重算。最忌讳的是每帧遍历全部 Buff 加一遍属性，几十个 Buff 乘几千个玩家，CPU 直接吃满。

协议上新增两条命令字：S2C_BUFF_ADD和S2C_BUFF_REMOVE，只同步cfg_id、剩余时间、层数三个字段，客户端负责表现。别把整个 Buff 结构体发过去，配置字段客户端自己查表就行。验证方法很土但有效：加 GM 命令手动上 Buff，连续挂 30 分钟观察属性面板数值能不能回到原始值，回不去就是移除流程漏了某一阶段的重算。

我踩过最深的一次坑，是 Buff 生效写在攻击结算之后，导致「先算伤害再上增伤 Buff」，玩家反馈增伤第一下不生效。从那以后我每次加状态类功能，都强制先跑一遍「上状态 → 打一下 → 看日志里的属性快照」这个流程，再谈数值平衡。这套双端骨架的改造空间其实挺大，Buff、坐骑、行会都能在现有实体结构上长出来，别一上来就重构网络层。希望帮到你。

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