1. 为什么几千人同屏不卡通信架构的底层逻辑1.1 玩家的体感差异从哪来你打开客户端点进一场英雄联盟对局或者登录《魔兽世界》飞到主城看到的画面是一群角色在那蹦跶。你以为这是显卡渲染出来的其实只对了一半。屏幕上每一个角色的位置、朝向、技能释放、血量变化全是服务器通过网络告诉你的。显卡负责把画面画出来网络负责把世界状态告诉你——而后者恰恰是所有网络游戏体验的分水岭。同一款游戏有人延迟 30ms 觉得丝滑有人延迟 200ms 觉得技能怎么按都慢半拍有人挤在主城看到几百个玩家走动全程流畅有人换个网吧一进团本就黑屏、飘逸、瞬移。这些感受上的天差地别根源不在电脑配置而在通信架构的取舍。做游戏后端这行有一个共识架构设计决定了这个游戏的天花板运营期的每一个卡慢掉线十有八九都能追溯到架构阶段埋下的雷。大型网络游戏本质上是这样一件事一台或多台服务器需要在极短的时间内把整个世界的变化同步给成千上万个客户端同时接住这些客户端丢上来的操作指令。这个过程做得越高效、越聪明玩家就越感觉不到网络的存在。反过来做得粗糙玩家就会觉得世界是假的、人物是飘的、技能是猜的。我一直习惯把网络游戏的通信架构比作一个大型线下聚会。玩家是来参加聚会的人服务器是主办方网络是场地里的传话筒。主办方不可能让每个人都跟所有人聊天那样会吵翻天。真正的做法是主办方划定区域每个人只需要知道自己周围几米内发生了什么事远处谁摔了一跤、谁喝多了跟你没关系你也不需要知道。所谓千万玩家同处一世界其实就是一套高度组织化的只告诉你该知道的事的通信调度系统。1.2 客户端-服务器模型为什么几乎所有大型游戏都选它聊具体架构之前得先把最底层的那个选择题说清楚游戏数据到底走什么样的网络结构。有两条路。一条叫 P2P点对点就是玩家之间直接互相传数据服务器只充当牵线人甚至完全不参与。优点是一台服务器能省下海量带宽延迟链条也短。缺点是所有人必须高度互信只要有一个人的客户端出问题或者作弊整个世界就会跟着崩。所以 P2P 只适合两个人对战比如格斗游戏直连或者 4~8 人的小型局域网联机规模一大就失控。另一条叫客户端-服务器Client-Server所有玩家都连接服务器由服务器做权威仲裁客户端之间不直接通信。这是 LoL、WoW、以及市面上你叫得出名字的所有大型网游共同的选择。代价是服务器要抗住所有数据流的转发和逻辑计算但换来的是两点决定性优势第一服务器是唯一权威谁的位置在哪里、谁击中了谁、谁掉血了以服务器计算为准作弊很难得逞第二服务器可以对所有客户端做统一调度按需下发数据而不是让每个玩家盲目地全网广播。你完全可以理解为P2P 是一群人在广场上自由喊话客户端-服务器则是所有人通过一个总台对讲机沟通总台决定谁该听谁的话。对于千万级玩家的游戏世界只有后者能做到有序。确定了模型之后真正的工程挑战才开始。因为客户端-服务器模型把压力全部集中到了服务器和网络链路上一台机器每秒要处理几十万条消息而玩家的网络环境又千奇百怪——有人光纤有人校园网有人用手机热点。通信架构的一切工作本质上就是围绕三个矛盾展开带宽有限、延迟客观存在、客户端性能参差不齐。接下来我分别用 LoL 和 WoW 这两类典型游戏拆给你看它们是怎么应对这些矛盾的。2. LoL 与 WoW两类架构的典型对比2.1 对战竞技类的房间制架构LoL 为例英雄联盟这类 MOBA 游戏一场对局的人数极少——5v5最多十个人。但它的通信压力一点不小原因在于这十个人的所有操作都要被精确地同步给彼此而且节奏极快技能预判、走位博弈都建立在毫秒级的反馈上。你看一把 LoL 对局会发现它整个通信模型是房间制Room-based的。玩家匹配到一起后系统分配一个独立的对局服务器Game Server这十个人独占一个房间所有消息都在这个房间内流转。这带来一个非常好的特性消息接收范围天然有限任何一个人移动只需要同步给其他9个人不需要也不应该广播给全世界。房间制架构的核心组件是个状态管理循环。每个 Game Server 内部维护着一张游戏状态表里面记录着十个玩家的坐标、血量、技能冷却、小兵位置、野怪刷新状态等。客户端每秒钟会发送大量操作请求移动指令、施法指令、买装备指令到服务器服务器收到消息并不是立刻转发而是先做一次逻辑仲裁这个施法请求合法吗蓝量够吗冷却好了吗位置对吗通过仲裁后服务器更新状态表再把这个状态变化打包发给关心它的客户端。这个过程有个关键指标叫 Tick Rate逻辑帧率。LoL 的服务器逻辑帧率通常在 30Hz 左右意思是服务器每秒执行 30 次完整的逻辑更新。每一次更新就是一轮收指令-算结果-发状态。30Hz 听着不高但已经能让人眼感觉流畅了毕竟玩家的操作频率本身也就每秒几次点击。这里有个重要权衡Tick 频率越高玩家操作反馈越跟手但服务器 CPU 消耗和带宽消耗会同步上升。10 个人的房间也许不觉得但如果房间规模上升到几百人Tick 每翻一倍服务器成本可能翻两三倍。2.2 大型多人在线的无缝世界架构WoW 为例《魔兽世界》是完全不同的物种。它一张地图同时容纳几百甚至上千人而且这个世界是无缝的——玩家从暴风城一路跑到西部荒野不需要加载界面理论上整个大陆是一个连通的物理空间。这意味着通信架构不能按房间来切必须按区域来管。WoW 的服务器角色更准确地说是多个服务协同工作的集合。它有个大世界服务器负责承载地图数据内部按区域划分成多个逻辑处理单元。比如你在艾尔文森林你在逻辑上被分配给了艾尔文森林区域服务你跑到西部荒野系统会做一次跨区域迁移把你从上一个区域的会话列表里挪到下一个区域的列表里。这个过程玩家无感但背后是一次完整的信息交接你屏幕里该看到的其他玩家列表、NPC 状态、任务进度全部要从上一个区域服务移交到下一个区域服务。区域世界里的通信模式不是谁动了就通知谁而是按视野范围同步。每个玩家客户端会告诉服务器自己在哪服务器维护一张场景实体列表然后只把视野范围内的信息推送给客户端。这里用到的核心概念叫 AOIArea of Interest也就是兴趣区域管理。服务器会动态计算每个玩家的可见圆通常以玩家坐标为中心的一个半径范围凡是落在这个范围内的其他玩家、怪物、掉落物才打包同步给你。你看 TV 直播里 WoW 主城那么多人每个人客户端收到的其实只是周围几十米内的几十个角色信息而不是全城几千人。从技术角度看LoL 是人少但要精WoW 是人多但要省。LoL 需要在十个人之间高频同步精确状态而 WoW 需要在几百上千人之间低成本地维持一个大体一致的世界。两种架构没有谁优谁劣只有谁更适合业务场景。2.3 状态同步 vs 帧同步选型的核心权衡做游戏后端的人迟早要面对一个经典选择题游戏逻辑的状态同步到底走状态同步还是帧同步这个选择直接决定了整个通信架构的实现方式。状态同步服务器维护所有实体的完整状态位置、血量、CD客户端发操作指令服务器算结果把更新后的状态发回客户端。它的优点是容错强、防作弊好、客户端实现灵活缺点是服务器压力大、带宽消耗高因为每个状态变化都必须实时下发。LoL 和 WoW 本质上走的都是状态同步只是粒度不同——LoL 更精细WoW 更粗放。帧同步则是另一个思路服务器不计算复杂的游戏逻辑只负责把每个客户端的操作指令收集起来按时间序列广播给所有人。每个客户端收到的指令序列完全一致然后各自用同一套逻辑代码跑出同样的结果。它的优点是服务器极其省事带宽需求小只传指令不传状态适合格斗游戏、RTS 这类所有人都得精确知道每一步的场景。缺点也很致命只要有一个客户端和服务器的时间基准出现偏差或者逻辑代码有一点不一致整个游戏世界会立刻分叉出现各人看到各人的世界的灾难。所以帧同步对网络要求极其苛刻几乎只用在小型对战房里。这两个概念经常被混淆但它们的适用边界其实很清楚。你做 10 人 MOBA可以考虑帧同步很多竞技游戏实际是帧同步思路做输入预测你做千人同屏的 MMORPG几乎没得选只能状态同步。因为千人同时在一张地图如果全量广播操作指令带宽是天文数字而按需下发状态配合 AOI 裁剪才能控制住流量。3. 让千万玩家同处一世界的关键技术3.1 AOI视野管理是怎么做到的前文提到 AOI 是兴趣区域管理这个词值得展开讲因为它是大型网游通信血量的命门。没有 AOI 的世界会是什么样想象一下一张地图 1000 个玩家每个人移动一步都要把坐标广播给其他 999 人一秒产生 1000×999×每秒移动次数条消息服务器和带宽瞬间爆炸。实际上绝大多数移动信息对远处的玩家毫无意义你不需要知道另一个大陆上有个玩家往左挪了一厘米。AOI 的核心就是回答一个问题某个实体发生变化时应该通知谁工程上有几种常见实现。最简单的是网格法Grid-based。把地图划分成等大的格子格子边长通常取玩家可视半径的 1/2 或 1/3。服务器维护一个格子-实体列表的映射表。当一个实体移动时只需要遍历它当前所在格子及相邻格子中的实体把变化通知给它们。格子的粒度很讲究格子太大无效通知变多格子太小切换格子的频率变高计算开销上升。我见过不少项目直接把格子边长设为固定值结果人多的区域消息量爆炸人少的区域又浪费。经验做法是取玩家最远交互距离的 1/2 作为格子边长并且配合热点区域动态调整。另一种常见实现是九宫格/十字链表法。每个实体动态维护一个我周围有哪些实体的链表通过十字链表的数据结构快速增删。这种方式在实体稀疏分布的 MMORPG 里效率极高但实现复杂度高位置频繁跳动时容易出 bug。无论哪种实现AOI 只解决该告诉谁的问题不解决消息怎么发才不爆。配合 AOI 的还有一整套消息裁剪策略你看到的远处玩家可以降低同步频率比如 5 米内的实体每秒同步 10 次50 米外的实体每秒同步 2 次200 米外的实体每秒钟最多同步一次位置甚至干脆只同步他还在这个状态。这就是 LODLevel of Detail思想在通信层面的应用——跟图形渲染的 LOD 如出一辙都是远处少给细节、近处给足细节玩家感知不到区别带宽却能省下一大截。3.2 消息广播与流量控制AOI 决定发给谁广播策略决定怎么发。一个 1000 人的主城如果服务器把每个玩家的移动消息都单独打包、单独发给各自视野内的目标会产生大量重复的小数据包。每个包头有开销IP 头TCP/UDP 头再小的消息也得占几十字节。所以工程上普遍采用合并广播Batching策略。具体做法是服务器按固定的时间片比如 100ms收集这一帧内产生的所有实体变化把它们打包成一个大的数据包再把这个包发给所有相关客户端。这个包的结构通常是一个实体 ID 状态增量的列表。玩家收到后解包逐个更新本地对应实体的状态。这样做的效果是数量级地减少网络包数量让本来每秒几十万个包降级为每秒几百个包网络吞吐量不变但 router 和网卡的 CPU 开销大幅下降丢包率也随之降低。除了合并广播还有一套比较依赖经验的流量控制手法。最常见的是按距离降频前面已经提到。另一个是用重要性评级敌人施法、自己掉血这些消息不能丢优先级最高远处玩家的移动可以降频景观类对象NPC 走路、小动物蹦跶几乎可以只在客户端本地做假动画不占用服务器带宽。很多 MMO 里你看到的小动物跑动其实是客户端自己播的循环动画根本不是服务器同步的——这不算欺骗这是系统性的带宽节约。在偏实时竞技的 LoL 里流量控制更精细化。移动指令和施法指令必须全量、低延迟发送。但像音效触发、表情播报这类非核心消息走的是另一个通道可以合并、延迟、甚至丢弃不影响游戏公平性。这就是分层消息通道设计核心战斗消息走快通道逻辑帧内必须送达非关键消息走慢通道能合并就合并。通道拆分在实现上不难但很多人没用直到线上带宽告急才回来补课。3.3 延迟补偿客户端预测与服务器回滚网络的物理限制无法破除光速和路由器排队时间就在那。300ms 的延迟在跨省线路上并不罕见。如果玩家的每次操作都要发到服务器→服务器算好→发回来→客户端看到结果那 300ms 意味着你按下技能后要等 1/3 秒才有反应这游戏根本没法玩。于是有了两项经典技术客户端预测Client-side Prediction和服务器回滚Server Reconciliation。客户端预测的逻辑很朴素服务器还没返回结果时客户端先按玩家的输入假装世界变了。你按下方向键往右客户端立刻把本地角色往右移动一截同时把操作指令发送给服务器。如果服务器同意的确可以往右移动那客户端本地显示的就是正确结果如果服务器发现右侧有墙、有控制效果它会返回一个纠正包客户端收到后用正确的位置覆盖本地预测的位置。这一覆盖过程就是回滚。LoL 里你偶尔能看到角色突然抽搐一下、或者被拉回原位很多就是客户端预测被服务器纠正后的视觉表现。服务器回滚的升级版叫延迟补偿Lag Compensation在 FPS 游戏里用得最多服务器在收到攻击判定请求时不是按当前时刻的实体位置来算命中而是回滚到玩家发起攻击那一刻的位置快照用那个位置做碰撞检测。这样高延迟玩家的子弹也能命中移动中的目标不至于因为延迟永远打不到人。虽然 LoL 这类 MOBA 对精确命中要求更苛刻但原理一样服务器需要保存过去若干帧的状态快照常用的做法是保留最近 1~2 秒内每 50ms 一个快照用于裁决争议事件。这里有个工程上常见的坑快照保存太频繁内存开销大保存太稀疏回滚精度不够。实际项目里我建议按一个快照对应 2 个 Tick的粒度保存配合时间戳二分查找既能保证精度又不至于整天 GC 报警。快照里的数据不是全量实体状态而是足以完成仲裁的最小状态集比如玩家坐标、朝向、速度向量、当前技能 ID。能做到这一步回滚的开销就在可接受范围内。4. 大型游戏服务器架构的落地实践4.1 分区、分流与跨服说完了通信模型和同步技术再看真实的工程落地。一个千万级玩家的游戏肯定不可能让所有人挤在同一台服务器上。必然会拆。拆的方式有几种分区Sharding、分流Channeling和跨服匹配Cross-server这三者概念经常被混用但解决的问题完全不同。分区是最粗粒度的手段。把玩家按地理、按服务器 ID 拆到互相独立的服务器集群里每个集群有自己的世界和玩家数据库。LoL 的电信区网通区就是分区思想的体现——好处是隔离故障、降低单集群压力坏处是不同区的玩家无法互动。分流是同一个世界里的垂直切片。想象 WoW 的一张地图有 1000 人服务器按一定规则把它拆成 4 个独立的副本空间每个空间 250 人。玩家从外观上都在同一张地图但实际在 4 个不同的实例里跑。这个方案解决的是一张地图物理容纳上限的问题代价是玩家会看到明明站在同一点却看不到对方——用游戏世界观的措辞叫位面。跨服匹配则是把不同服务器的人拉进同一个房间/战场。LoL 的排位赛就是跨服匹配它和世界服务器关系不大因为匹配成功后是拉进一个新的、独立的 Game Server 房间。这个方案大量用于 PvP 玩法既利用了空闲的服务器算力又避免了永久分区带来的玩家隔离感。实际项目里三种手段往往是叠加使用的。先按区分组再在区内部署多个大世界服务器每个大世界内部再按地图分流而 PvP 玩法统一走跨服匹配房间。这套区-服-图-房的四层嵌套架构几乎所有大型网游都在用只是名字各不相同。4.2 从单体到微服务网关、逻辑服、房间服早期的游戏服务器是单体架构一台机器跑网关、跑逻辑、跑数据库访问、跑聊天系统。上线初期人少没事一到高峰期就四处告警加机器只能整台整台地加浪费严重。现在的主流方案是按职责拆分成可独立扩展的服务。最前面是网关服Gateway。它负责四件事维护客户端的长连接、做登录认证、按玩家当前所处场景转发消息到对应逻辑服、做消息的队列排队。网关本身不跑游戏逻辑它是消息的交通警察。玩家断线重连、进入游戏世界、切场景对接的都是网关而不是底层逻辑服。中间是逻辑服Game Logic Server承载 AOI 计算、战斗判定、技能逻辑、任务系统。逻辑服按场景/区域部署一张地图一个逻辑服地图内所有实体的状态由它维护。如果地图人气太高可以把这个逻辑服拆成多进程每个进程管一部分区域。最下面是房间服Room Server主要服务于对局类玩法——MOBA 的每一局、FPS 的每一场、MMO 里的战场都是启动一个独立的房间服实例。房间服会内嵌一个完整的状态同步循环逻辑帧率跑在 20~60Hz。LoL 对局和 WoW 战场底层的房间服架构是高度相似的只是游戏逻辑内容完全不同。这套分层的好处显而易见网关可以水平扩容人多了加网关节点就行逻辑服按地图拆哪个地图人多就给哪个地图多加实例房间服按需创建比赛结束后销毁算力利用率极高。我曾经接手过一个游戏逻辑和网关混跑的老项目高峰期一个线程又收包又算逻辑又写数据库性能瓶颈一个接一个。后来把网关拆出去逻辑服 CPU 占用直接降了一半玩家掉线率肉眼可见地下降。这不是什么高深理论就是一个朴素的教训职责不清性能永远上不去。4.3 带宽与 CPU 的权衡实测数据参考很多人以为网络优化就是省带宽其实省带宽和省 CPU 经常是矛盾的。做大量小消息的合并广播能省带宽但要做序列化和压缩CPU 消耗就上去了不做压缩带宽又爆了。架构师必须找到自己的平衡点。我拿一个实际项目的数据举例。一个小型 MMO平均同时在线 5000 人集中在 3 张大地图。刚上线时网关带宽峰值 1.2GbpsCPU 只有 40%但服务器网络出口已经接近上限随时可能丢包。我们做了一轮优化把 AOI 半径从 80 米压缩到 60 米把 50 米外实体的同步频率从 5Hz 降到 2Hz再开启消息合并峰值带宽立刻降到 480Mbps市场份额大减。代价是什么玩家在 50 米外看到其他玩家跑步时略有瞬移感。但我们把 15 米以内的实体同步频率保持在 15Hz保证了核心交互体验不受影响。这是标准的体验换带宽的操作前提是你得知道哪些距离是玩家的核心交互半径哪些距离只是存在感。再补一个参数参考一个 30Hz 逻辑帧率的 10 人房间每帧状态更新包大约 2~4KB一秒就是 60~120KB 的流量对一个玩家来说约等于 0.5~1Mbps。而一个 1000 人主城如果全量同步每个玩家位置理论上每秒要发 1000×999×位置消息随便算算就是几百 MB/s。所以主城里面绝不能全量同步必须靠 AOI 裁剪。用一个 100 米视野半径的典型参数假设人群密度均匀每个玩家视野内大约有 30~50 个实体这 50 个实体每秒同步 5 次位置每个位置消息 32 字节流量就是 50×5×328000B/s64Kbps加上包头和协议开销差不多 100Kbps 一个玩家。一个千人在线的主城网关出口也只需 100Mbps 左右这是完全靠 AOI 省下来的带宽。5. 常见问题与排查技巧实录5.1 玩家反馈卡顿的分类和排查流程游戏上线后最常收到的玩家反馈就是一个字卡。但卡其实是一个极其模糊的描述背后可能是完全不同的病因。我习惯把卡顿分三类排查路径各不相同。一类是网络延迟卡。特征是技能有延迟、走路有回弹、按了半天没反应。排查思路是看延迟统计曲线如果波动大且周期性出现多半是网络路径问题如果是持续走高可能是带宽跑满需要看流量监控。这类问题优先查网关出口和机房线路质量而不是翻逻辑代码。一类是服务器逻辑卡。特征是全体玩家在同一时段集体卡顿而且不管你在哪个地图都卡。这个是服务器 CPU 跑满了需要抓火焰图看热点逻辑。我曾经排查过一个案例一张地图 300 人同时放 AOE 技能服务器出现1 秒卡死的鬼畜表现。抓火焰图发现是技能伤害结算时反复查数据库做物品掉落计算每次结算都产生一个数据库查询。改成内存缓存后同样负载下 CPU 从 95% 降到 40%。还有一类是客户端渲染卡。特征是画面掉帧、帧率低但网络延迟正常。这个与通信架构无关但玩家也会把它算成卡列在这是为了排查时别浪费时间。判断方法很简单看延迟是否正常把画质调到最低还卡不卡。如果延迟正常、画质调低后不卡那就是客户端优化问题不要往服务器上找原因。5.2 优化带宽的几个实用手段如果监控显示某个场景消息量异常暴涨我用过几个屡试不爽的办法。第一招是加 AOI 的格子粒度。同样是 1000 人的主城网格边长从 20 米改成 40 米AOI 计算次数能降一半但无效消息会增多。所以别盲目调先用日志统计平均每帧广播实体数高于 100 再考虑调窄/调粗。第二招是给实体状态同步加阈值过滤。实体移动状态只有变化量超过某阈值才同步。比如角色位移小于 0.1 米不广播朝向变化小于 5 度不广播。这个阈值在 MMORPG 里可以开得比较大在 MOBA 里必须很小否则会破坏手感。第三招是把聊天、表情、非关键系统消息移出主同步通道。聊天消息本身占流量倒不重要但它会打断合并广播的紧凑性导致主通道的包变多。分通道后聊天走独立 TCP 连接不会挤压游戏逻辑消息的发送时序。5.3 实测经验与避坑心得这个行业里很多东西是不踩坑不知道的我把自己经历过的一些典型教训梳理出来供你参考。第一永远不要高估玩家的网络质量。开发期用内网测试延迟 1ms什么都顺畅。上线后发现大量玩家延迟 100ms 以上甚至 10Mbps 带宽的共享网络。如果你开发的是一款竞技性强的游戏必须从第一行代码就把客户端预测做好不做预测的游戏上不了真实网络这是铁律。第二消息协议别一开始就上 JSON。JSON 可读性好、调试方便但序列化膨胀率高达 2~3 倍解析也慢。上线后流量不够用了再换 Protobuf/FlatBuffers改造工程量极大。我的习惯是内部调试用 JSON客户端和服务器正式通信一律走二进制协议字段顺序固定、可变长字段用 varint 编码。这能让理论带宽消耗降一半以上。第三注意 UDP 和 TCP 的选择。大部分 MMO 用 TCP 省心因为要保证消息不丢。但 TCP 有队头阻塞问题一个包丢了后续所有包都得等重传。对于快节奏的 MOBA 和 FPS延迟稳定性比消息绝对可靠更重要现在越来越多团队选择UDP 自研可靠层在 UDP 之上实现 ACK、重传、排序。LoL 早年就有 UDP 方案。做技术选型时请把丢包率容忍度和延迟敏感度摆在一起评估别只图省事。第四网关和逻辑服之间别复用同一条连接。网关到逻辑服的消息内网延迟极低但如果把海量玩家消息都塞进同一条内网 TCP 连接一个慢速玩家会拖慢整条管道。正确做法是把玩家按逻辑服拆分成独立的内部连接池并使用消息队列做削峰填谷。很多线上事故的根源不是逻辑代码而是内网连接被某个大流量消息堵死了。写在最后我从入行做游戏后端到现在接手过从几个人到几千人同时在线的项目也围观过别人几万人在线时的架构演进。最大的体会是网络游戏通信架构从来没有银弹一切技术选型都是在体验、成本、复杂度三者之间找平衡。你在 LoL 里追求极限的同步精度在 WoW 里却必须接受粗粒度同步带来的细节损失有人主城同屏几百人流畅如丝必然有人在远处看到其他玩家瞬移但你不在乎因为你的核心交互半径内始终是稳定的。做这套系统的成就感很奇怪——不是上线那一瞬间所有人流畅运行的满足感而是你优化完 AOI 之后盯着带宽曲线从尖峰变成平缓的那种踏实感。通信架构的每一点优化最终都会转译成玩家的一个丝滑感受技能甩出去的瞬间命中判定不延迟队友在你身边走过没有鬼影团队打 Boss 时每个人的血量条都在同步跳动。如果你正准备做一个需要承载大量并发玩家的游戏我的建议很简单先画清楚你的同处一世界到底同处到什么程度。是十个人的精彩对决还是一千个人的热闹街市这个答案决定了你后面所有的架构决策。不要一开始就想着把《魔兽世界》的整套体系搬过来也不要为了省事直接套用对战游戏的房间模型。先想清楚核心体验再动手写通信层你会发现后面所有的路都顺了。