dsh_shenxian/dsh-server-docs/04-调整方案/108-覆盖网络-游戏专项-MMORPG与MUD.md

108 · 覆盖网络 · 游戏专项-MMORPG与MUD

• 日期：2026-09-16 ｜ 状态：📋 规划态 / 未实施（专项设计稿）
• 来源：工作区根 覆盖网络_游戏专项_MMORPG与MUD_20260916.md（正文见 附录 A）
• 层级：专项设计｜ 承接档案 111 §一（其修正点）；配套 109（游戏网络参数与群聊上限）
• 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

⚠️ 本档含一次判定修正：此前按 3D 大世界强实时竞技评估，结论是"不合适"； 用户明确重点是 MMORPG（2D/2.5D）· MUD · 传奇类 —— 这三类恰好是覆盖网络最匹配的应用，甚至比群聊更契合。

TL;DR 这三类游戏的架构（服务端权威 + tick 驱动 + AOI 九宫格广播 + 分区/分线）本身就是覆盖网络友好型的， 不需要为它改造什么，只需提供「到达游戏服的可靠低延迟路径」。 ⭐ 最重要的简化：玩家之间不需要互联（服务端权威，玩家只与游戏服通信）⇒ 中继容量按「服数」算，不按「玩家数」算。

一、目标

把「覆盖网络上的 MMORPG(2D/2.5D) / MUD / 传奇类」设计成可落地方案：流量画像 · 与覆盖网络的映射 · 12 条关键设计细节 · 参考方案对照 · 反模式 · 游戏线落地顺序。 可判定「做完了没有」＝ 上述六项齐备，且最匹配判定的依据（五条特征对照）已给出。

二、只读前置

#	事实	核对方式（期望输出）
1	玩家与游戏服是长连接（TCP/WebSocket/自定义 UDP）且断线重连不踢人	本档 §3.1 第 2 条（设计要求）
2	「房间」抽象平台尚不存在（现在是「每用户一个实例 + 会话」）	档案 110 §五（群聊需新建，无房间抽象）
3	存档 = 不可再生数据 ⇒ 直接套备份三层	档案 110 §二（不可再生 46.3 MB 口径）
4	有公网 IP 的节点天然就是游戏服 / 中继候选	档案 105 §1
5	AOI 是控带宽的杀手锏：扇出从 O(N) 降到 O(k)	本档 §1（九宫格，k≈20–80）

三、范围

• 改什么：⏳ 未开跑。方案面 = 服主接入（拨出 + 中继）· 房间层（组队/行会/频道）· 存档备份 · 跨区/跨线路由 · 会话恢复 + 连接迁移 · 副本临时实例。
• 不动什么：⛔ 官方 dsh 主程序（R2）｜⛔ 不把玩家连成 P2P 网状（毫无必要且徒增连接数）｜⛔ 本轮不动服务器、不改代码。
• 明确排除：❌ 3D 大世界强实时竞技（FPS / MOBA 64+）—— 需专用服务端 + 权威模拟，中继多一跳，P2P 无法反作弊。

四、决策点

已定

1. 游戏重点是 MMORPG(2D/2.5D) / MUD / 传奇类（用户明确定调）⇒ 判定上修为「最匹配」，非 3D 强实时竞技。
2. 服务端权威不可让（P2P 无法防作弊；且这类游戏天生服务端权威 ⇒ 反作弊问题自然解决）。
3. 对外降频 + 按变化发送（⛔ 别把服务端内部帧率直接当对外频率）。
4. 社交功能直接复用「房间层」（队伍/行会/世界频道/副本组 = 房间）⇒ 一次建房，聊天 + 组队 + 行会 + 频道全都有。
5. 反模式硬拦：全图广播 · 信任客户端时间 · 对外频率=服务端帧率 · 每 tick 落盘 · 世界频道无限制推送 · 玩家 IP 一变就断线 · 单区无限扩容 · 把玩家连成 P2P 网状。

未定：会话恢复窗口（断线多久内可无缝续上，参数待定）。

五、步骤（§6 游戏线落地顺序；每步自带一次验证）

1. 服主接入：无公网 IP 的机器能开服并被外网访问（拨出 + 中继）—— 最小可用形态 → 验证：外网玩家可连上 NAT 后的游戏服。
2. 房间层（组队/行会/频道，与聊天共用）→ 验证：一次建房，四类社交容器同时可用。
3. 存档备份（套用备份三层，只备存档与配置，不备可重建的客户端资源）→ 验证：恢复演练通过。
4. 跨区/跨线路由（骨干节点承担）→ 验证：跨地图/跨线/合服有可用路径。
5. 会话恢复 + 连接迁移（移动端体验）→ 验证：Wi-Fi↔蜂窝切换不掉线。
6. 副本临时实例、合服。

六、验收

#	口径	期望
A	每玩家带宽	MUD <5 KB/s ｜ 传奇 10–50 KB/s ｜ 2D/2.5D MMO 20–80 KB/s
B	单节点承载	MUD 数百人 ｜ 传奇 100–300 人 ｜ 2D/2.5D 300–500 人
C	⭐ 关键简化生效	中继容量按服数算（一个服 1~N 条中继，几百玩家不各占一条）
D	AOI 生效	扇出从 O(N=500) 降到 O(k≈20–80)（差 10 倍以上）
E	反模式零命中	§5 八条反模式逐条对照，无命中
F	未验证项透明	§7 四条已列全

七、回滚

• 本档自身：零改动 ⇒ 无回滚需要。
• 执行期：§五 六步各自独立可回滚；⛔ 服务端权威不可回滚（一旦允许客户端持有权威状态 = 可作弊，属红线）。

八、回报格式

执行会话回填：① 每步验证命令 + 实际输出 ② 本环境实测：中继承载 100–300 人游戏服的实际带宽与抖动 ③ 443/TCP 兜底下长连接稳定性 ④ 会话恢复窗口实际取值 ⑤ 跨区转发延迟增量 ⑥ commit ⑦ 未完成项与卡点。

九、未验证项（勿当结论）

本环境实测：中继承载 100–300 人游戏服的实际带宽与抖动（未实测）｜443/TCP 兜底通道下长连接的稳定性（UDP 封禁的企业网，未实测）｜会话恢复窗口（待定参数）｜跨区转发的延迟增量（待实测）。

---

附录 A · 原始规划正文（逐字保留 · 2026-09-16）

以下为工作区根 覆盖网络_游戏专项_MMORPG与MUD_20260916.md 的原文全文，仅删除其一级标题（避免与档案标题重复）， 其余一字未改；本档的可判定部分以上方 8 段为准。

日期：2026-09-16 ｜ 性质：专项设计稿（细化 覆盖网络_补遗与参考方案_20260916.md §一） 🟢 范围：只考虑技术实现；跨境数据合规由使用者自行考虑。

---

0. 判定修正（此前按 3D 强实时竞技评估，结论要改）

前文说"大规模 MMORPG 不合适" —— 那是针对 3D 大世界强实时。用户明确重点是 MMORPG（2D/2.5D）· MUD · 传奇类，这三类恰好是覆盖网络最匹配的应用，甚至比群聊更契合。

特征	FPS / MOBA（不适合）	MMORPG / MUD / 传奇（适合）
权威归属	实时模拟需专用服，P2P 反作弊难	天生服务端权威 ⇒ 反作弊问题自然解决
延迟敏感	<50 ms	几百 ms 无感（tick 驱动）
广播方式	全员高频状态	AOI 视野广播（九宫格） ⇒ 天然不放大
每玩家带宽	数十–数百 Kbps 且要求抖动小	数 KB/s ~ 数十 KB/s
扩展方式	单局	分区 / 分线 ⇒ 天然水平切分

一句话：这三类游戏的架构（服务端权威 + tick + AOI + 分区）本身就是覆盖网络友好型的，我们不需要为它改造什么，只需要提供"到达游戏服的可靠低延迟路径"。

---

1. 流量画像（决定容量与选路）

类型	tick / 广播频率	每玩家带宽	单节点可承载	覆盖网络压力
MUD（文字）	tick 0.25–1 s（文本行）	< 5 KB/s	数百人	极轻，中继也够
传奇类（2.5D 俯视）	服务端 20–50 Hz 内部；对外按变化/降频	10–50 KB/s	100–300 人	轻
2D/2.5D MMORPG	同上 + 技能/特效事件	20–80 KB/s	300–500 人	轻–中

两处关键的省带宽机制（这类游戏的标准做法，直接沿用）：

1. AOI / 兴趣区域广播（九宫格）：只广播视野内实体 ⇒ 扇出从 O(N=500) 降到 O(k≈20–80)，差 10 倍以上。这就是为什么 MMORPG 不会出现"广播风暴"。
2. 对外降频 + 按变化发送：服务端内部 20–50 Hz 模拟，对客户端只发变化且可降到 5–10 Hz ⇒ 再省一半到八成。

---

2. 与覆盖网络的映射（关键简化）

        玩家（任意网络）              游戏服（服主的机器）
   ┌──────────────┐            ┌──────────────────────┐
   │ 玩家 A 家宽   │──直连──────▶│                      │
   │ 玩家 B 移动网 │──中继──────▶│  服务端权威 + 分区/分线 │
   │ 玩家 C 企业网 │──443/TCP──▶│  存档 / AOI / tick    │
   └──────────────┘            └──────────────────────┘

⭐ 最重要的简化：玩家之间不需要互联（服务端权威，玩家只与游戏服通信）。 ⇒ 覆盖网络在这一场景里只需解决一件事：让玩家可靠地到达游戏服，而不是把玩家连成网。 ⇒ 直接后果：中继容量按"服数"算，不按"玩家数"算 —— 一个服只需要 1~N 条中继，几百个玩家不各占一条。

2.1 三类角色的接入需求

角色	需求	覆盖网络的作用
服主（无公网 IP）	让外网玩家能连进来	必须有（拨出 + 中继/反向隧道）—— 这是核心价值
服主（有公网 IP）	直接开放端口	可选（只为跨地域优化）
玩家	连上游戏服	直连为主；跨地域或对端在 NAT 后时走中继

⇒ 与"骨干层"完美衔接：有公网 IP 的节点天然就是游戏服/中继候选。

---

3. 关键设计细节（12 条）

3.1 网络与同步

1. 服务端时间权威：一切 tick、冷却、移动校验以服务端时钟为准，不信任客户端时间 ⇒ 这是防"加速外挂"的唯一正解（传奇私服最常见的作弊就是改本地时间/加速）。
2. 长连接 + 心跳：这类游戏是长连接（TCP/WebSocket/自定义 UDP）。心跳要能区分"卡"与"断"，且断线重连不踢人（回放窗口 + 状态快照）。
3. 连接迁移：玩家 Wi-Fi ↔ 蜂窝切换会换 IP ⇒ 用会话 token 恢复而不是"IP 变了就当新连接"（否则玩家一走动就掉线）。
4. 对外降频 + 变化优先：见 §1.2；别把服务端内部帧率直接当对外频率。
5. AOI 用成熟算法：九宫格（最常用）/ 十字链表 / 四叉树。⚠️ 不要用全图广播 —— 那是这类游戏唯一的"自找风暴"。

3.2 世界结构

6. 分区 / 分线（zone / shard）：地图或线路 = 独立的模拟单元 ⇒ 天然的水平扩展点，也天然对应"一台机器跑一个区"。
7. 跨区 / 跨线转发：玩家跨地图、跨线、跨服（合服）时需要转发 ⇒ 由骨干节点做跨区路由（这部分流量是小头，但必须有一条路径）。
8. 副本 / 独立实例：副本可以临时开进程（用完即销毁）—— 资源模型与"实例"一致。

3.3 数据与持久化

9. 存档策略：热数据在内存 + 定期落盘/写日志（不要每 tick 落盘）；冷数据（离线玩家）批量归档。
10. 持久化与备份衔接：这类游戏的存档是不可再生数据 ⇒ 直接套用备份三层（本地快速恢复 + 对象存储主备份 + 网内第三副本），且只备存档与配置，不备可重建的客户端资源。
11. 节点故障的玩家恢复：游戏服挂 ⇒ 玩家应能落到另一个节点继续（配合 tick 存档 + 会话恢复）；这正是"迁移提速"那条在游戏场景的直接应用。

3.4 社交与复用

12. ⭐ 社交功能直接复用「房间层」：队伍 = 房间、行会 = 房间、世界/交易频道 = 房间、副本组 = 房间。 ⇒ 前面"群聊房间与游戏对局是同一个抽象"的结论在这里第二次兑现：一次建房，聊天 + 组队 + 行会 + 频道全都有。 ⚠️ 但要注意世界频道的扇出：它是唯一"一人发、全网收"的点 ⇒ 必须限频 + 分片 + 拉取式，否则就是唯一的风暴源。

---

4. 参考方案对照（这类游戏生态很成熟，别自研）

方向	参考方案	借什么
MUD 服务端	Evennia（Python，现代）、FluffOS / LPMud、CircleMUD、Ranvier（JS）	tick 驱动世界模型、房间/对象/指令体系
传奇类（Mir2）服务端	开源 Mir2 服务端模拟器（多份社区实现）、HeroM2 类引擎	格子地图、服务端权威移动校验、封包协议
2D/2.5D MMO 服务端框架	Skynet（Lua，分区分服经典）、Pomelo（Node.js 分布式）、KBEngine、ET（C# 双端）、Colyseus、Orleans（虚拟 Actor）	分区分线、跨服路由、actor/实体模型
通用游戏后端	Nakama（房间 + 匹配 + 持久化 + 排行，开源）	直接可用的社交/账号/存储能力
AOI 算法	九宫格 / 十字链表 / 四叉树 / R-tree	视野广播的成熟实现
联机传输	KCP / enet / QUIC；WebRTC DataChannel（不可靠模式）	类 UDP 的低延迟可靠传输
客户端	Cocos / LayaAir / Phaser / Godot（2D）	与 Web 客户端壳集成的天然选择

国内生态提示：传奇/2D MMO 的"一台机器一个区 + 分线"是行业标准做法，与我们"用户自己开服 + 骨干中继让外网可达"的模型天然契合 —— 不需要发明新范式。

---

5. 反模式（这类游戏特别容易踩的）

#	反模式	后果
1	全图广播（不做 AOI 裁剪）	唯一的自找广播风暴
2	信任客户端时间	加速外挂横行
3	对外频率 = 服务端帧率	带宽浪费数倍
4	每 tick 落盘	IO 打满
5	世界频道无限制推送	一人发言全员收 = 放大点
6	玩家 IP 一变就断线	移动玩家体验崩塌
7	单区无限扩容	该分区就分区，别硬撑单进程
8	把玩家连成 P2P 网状	毫无必要（服务端权威）且徒增连接数

---

6. 落地顺序（游戏线）

1. 服主接入：无公网 IP 的机器能开服并被外网访问（拨出 + 中继）—— 这是最小可用形态。
2. 房间层（组队/行会/频道，与聊天共用）。
3. 存档备份（套用备份三层，只备存档与配置）。
4. 跨区/跨线路由（骨干节点承担）。
5. 会话恢复 + 连接迁移（移动端体验）。
6. 副本临时实例、合服。

---

7. 未验证项

#	项	状态
1	本环境实测：中继承载 100–300 人游戏服的实际带宽与抖动	⚠️ 未实测
2	443/TCP 兜底通道下长连接的稳定性（UDP 封禁的企业网）	⚠️ 未实测
3	会话恢复窗口（断线多久内可无缝续上）	📋 待定参数
4	跨区转发的延迟增量	📋 待实测