145 lines
9.2 KiB
Markdown
145 lines
9.2 KiB
Markdown
|
# 覆盖网络 · 游戏专稿：MMORPG（2D/2.5D）· MUD · 传奇类
|
|||
|
|
|
|||
|
|
> 日期：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 | 跨区转发的延迟增量 | 📋 待实测 |
|