admin
4e3a1a4a13
- 新增 04-调整方案/103-112：可行性评估 · 全球架构复盘 · 骨干层方案 · 百台推演 v2 · 千台全场景推演 · 游戏专项 · 游戏网络与群聊上限调研 · 答疑(群聊/备份/迁移/保密) · 补遗与参考方案 · 九大瓶颈落地方案 - 每份按 交接单/README.md §二 8 段改写（目标/只读前置/范围/决策点/ 步骤/验收/回滚/回报格式）+ 头部状态标注（📋 规划态 · 未实施） - 技术内容不变：附录 A 逐字保留原文全文（仅去其一级标题），已逐份校验字节一致 - 登记：INDEX.md §二 +10 行、03-路线图与待办.md §二 +1 行 - 收尾：docs-audit.py 退出码 0（无 P0）· docs-manifest.py 已刷新 - 本轮零代码、零服务器改动；⛔ 未 push - 占号：103-112（先原子 mkdir .lock-<NN> 再写）
231 lines
15 KiB
Markdown
231 lines
15 KiB
Markdown
# 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 | 跨区转发的延迟增量 | 📋 待实测 |
|