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 | 跨区转发的延迟增量 | 📋 待实测 |