0 Fork 0

Files

T

admin ce8e6ceed9 chore(工作区): 纳入版本控制基线（回收 411 MB 过程产物）

回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复：
- 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录）
- tmp/（32.4 M，按接续棒命名的过程临时区）
- .workbuddy/tmp/（39.5 M）
- 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物）
- tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留

入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与
接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、
.workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。

排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、
打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。

2026-09-24 07:51:03 +08:00

9.2 KiB

Raw Blame History

覆盖网络 · 游戏专稿：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 人	轻–中

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

AOI / 兴趣区域广播（九宫格）：只广播视野内实体 ⇒ 扇出从 O(N=500) 降到 O(k≈20–80)，差 10 倍以上。这就是为什么 MMORPG 不会出现"广播风暴"。
对外降频 + 按变化发送：服务端内部 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 网络与同步

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

3.2 世界结构

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

3.3 数据与持久化

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

3.4 社交与复用

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

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. 落地顺序（游戏线）

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

7. 未验证项

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

9.2 KiB Raw Blame History Unescape Escape