2.2 单局房间型游戏问题模型

房间制（Session-based）游戏是最常见的多人游戏类型。核心特征是：玩家通过匹配进入一个独立的“房间“（或称对局、局、session），房间有明确的开始和结束，房间之间互不影响。

典型游戏：棋牌（斗地主、麻将、德州扑克）、卡牌对战（炉石传说、皇室战争）、MOBA（英雄联盟、DOTA2、王者荣耀）、FPS（CS:GO、守望先锋、Valorant）、大逃杀（PUBG、Apex Legends）。

虽然这些游戏在玩法上差异巨大，但从后端角度看，它们共享同一套核心问题模型。

核心特征：为什么房间制游戏是一类问题？

房间制游戏有三个共同的技术特征，这三个特征将它们与 MMO 等持久化世界游戏明确区分开：

1. 会话隔离

每个房间是一个独立的状态容器。房间 A 中的玩家操作不会影响房间 B。这意味着：

• 房间状态不需要跨房间同步
• 房间可以独立部署到不同进程甚至不同机器
• 天然适合水平扩展——加机器就能加房间

这是房间制游戏相比 MMO 最大的架构优势：无需处理全局状态一致性。

2. 有限时长

每局有明确的开始和结束。一局斗地主约5-15分钟，一局英雄联盟约25-45分钟。这意味着：

• 房间的内存生命周期可预测
• 可以提前规划资源回收
• 服务器可以按“房间/小时“来估算容量

3. 固定参与人数

每局参与人数有上限（2人象棋、5v5 MOBA、100人大逃杀）。这意味着：

• 单房间的计算和带宽开销有上限
• 不需要处理 MMO 中“一个区域涌入大量玩家“的问题

参考：腾讯游戏学院专家 Wade 在“经典游戏服务器端架构概述“中描述了房间制架构的基本进程结构：Lobby 服务器负责匹配和管理，Game Server 负责具体对局，二者职责明确分离。 — https://zhuanlan.zhihu.com/p/336195014 ¹

三个核心问题

所有房间制游戏都需要解决以下三个问题。不同游戏的差异主要在于每个问题的约束条件不同。

问题1：房间生命周期管理

一个房间从创建到销毁经历以下阶段：

创建 → 等待玩家 → 人齐/超时 → 游戏中 → 结算 → 销毁

关键设计决策：

房间进程还是房间对象？

这是最基础的架构选择：

• 房间进程：每个房间对应一个独立进程（或容器）。优点是完全隔离，一个房间崩溃不影响其他房间。缺点是进程创建和销毁的开销。适合单局计算量大的游戏（如 MOBA、FPS）。
• 房间对象：一个进程内管理多个房间，每个房间是一个内存对象。优点是开销小，适合轻量级对局（如棋牌、卡牌）。缺点是共享进程资源，一个房间的 bug（如内存泄漏）会影响同进程的其他房间。

参考：AWS 在 “Well-Architected Framework: Game Server Processes” 中展示了游戏服务器进程的典型模型，包括“每进程一个游戏会话“和“每进程多个游戏会话“两种模式。 — https://docs.aws.amazon.com/wellarchitected/latest/games-industry-lens/game-server-processes.html ²

超时和异常处理：

房间在每个阶段都需要超时机制，否则可能出现“僵尸房间“——已经无人参与但永远不销毁，持续占用资源。

需要处理的典型场景：

• 等待阶段：玩家进房后长时间不准备，需要踢出
• 游戏中：玩家掉线，等待多久后判定逃跑？是否允许重连？
• 结算阶段：结算数据写入失败如何重试？
• 全局：服务器崩溃后，未结束的房间如何恢复？

对局结果的持久化：

虽然对局过程是临时的，但结果（胜负、积分变动、获得物品）必须可靠持久化。这里有一个常见陷阱：

对局结算时，如果先发奖励再写结果记录，或者反过来，都可能因为中途失败导致数据不一致。正确做法是将“结果写入 + 奖励发放 + 积分变动“作为一个事务来处理，或者使用幂等设计保证重试安全。

问题2：匹配系统

匹配系统的核心矛盾是速度与公平性的权衡：

• 要求快速匹配 → 放宽匹配条件 → 可能不公平
• 要求严格公平 → 匹配条件严格 → 等待时间长

匹配系统的设计要素：

匹配维度：

最基本的是段位/分数（ELO、MMR），但实际产品往往还有更多维度：

• 段位范围（公平性）
• 网络延迟/地域（延迟优化）
• 等待时间（防止过长等待）
• 玩家偏好（模式选择、语言等）
• 组队约束（队伍总段位不能差异过大）

匹配维度越多，匹配空间的稀疏度越高，匹配速度越慢。

匹配算法的演进：

简单队列 → 分层队列 → MMR桶 → 优化匹配（如 TrueSkill 2）

• 最简单：先进先出队列，不区分段位
• 进阶：按段位分层，每层一个队列
• 更优：将 MMR 划分为桶（bucket），桶内做匹配，超时后扩大桶范围
• 高级：使用概率模型（如微软的 TrueSkill 2）评估匹配质量

参考：微软研究院的 TrueSkill 2 是 Xbox Live 使用的匹配评分系统，其论文详细描述了如何用贝叶斯推断来评估玩家技能和预测对局质量。TrueSkill 2 相比初代 TrueSkill 考虑了更多因素（如个人表现、组队效应）。 — Tom Minka et al., “TrueSkill 2: An improved Bayesian skill rating system”, Microsoft Research, 2018 ³

超时扩展策略：

几乎所有匹配系统都采用“渐进放宽“策略：刚开始严格匹配，随着等待时间增长，逐步放宽匹配条件。

0-5秒：   同段位 ± 100 MMR，同地域
5-15秒：  扩大到 ± 200 MMR
15-30秒： 扩大到 ± 500 MMR，跨地域
30秒+：   几乎无条件匹配，或匹配 AI

超时策略需要根据玩家基数调整——大基数游戏可以用更严格的初始条件，小基数游戏需要更激进的放宽策略。

取消匹配的处理：

玩家取消匹配时，需要确保：

• 从队列中移除（不能被后续匹配选中）
• 如果已经开始组队匹配，需要通知队友
• 如果已经分配了房间服务器，需要释放资源

问题3：房间服务器调度

当匹配系统确定了参与的玩家后，需要分配一个房间服务器来运行这局游戏。

调度策略：

• 最少负载（Least Loaded）：选择当前房间数最少的服务器。简单有效，但需要实时感知负载。
• 轮询（Round Robin）：依次分配。简单但不考虑负载差异。
• 地域优先（Region-based）：优先分配距离玩家最近的服务器，减少网络延迟。对于强实时游戏尤其重要。

实际产品中的考虑：

调度不仅仅是“选哪台机器“。还需要考虑：

• 弹性伸缩：峰值时快速扩容（启动新服务器），低谷时缩容（回收空闲服务器）。云厂商的专用游戏服务器方案（如 Agones、Open Match）就是解决这个问题的。
• 优雅退出：缩容时不能直接杀掉正在运行对局的服务器，需要等待当前对局结束后再回收。
• 故障转移：如果一台服务器宕机，如何快速重新分配其上的房间？（答案：对于强实时游戏，通常无法转移，只能判定对局中断；对于弱实时游戏，可能可以从快照恢复。）

参考：Google 开源的 Agones 是一个基于 Kubernetes 的游戏服务器编排系统，专门解决“在 Kubernetes 上运行和管理专用游戏服务器“的问题。其设计文档详细描述了游戏服务器的生命周期管理（Scheduled → Allocated → Ready → Running → Unhealthy → Shutdown）。 — https://agones.dev/ ⁴

参考：Google 另一个开源项目 Open Match 是一个通用匹配框架，将匹配逻辑与房间服务器分配解耦。它提供了匹配系统的骨架（Ticket 管理、匹配函数接口、评估器），让开发者专注于匹配算法本身。 — https://open-match.dev/ ⁵

架构总览：Lobby + Room Server

客户端
  │
  ▼
Lobby 服务器（集群）
  ├── 登录验证
  ├── 匹配系统
  ├── 好友/社交
  └── 房间管理（元数据）
  │
  ▼
房间服务器（集群）
  ├── 运行具体对局
  ├── 游戏逻辑
  ├── 状态同步
  └── 结算 → 写数据库

关键设计原则：

• Lobby 和 Room Server 分离：Lobby 是有状态的（在线玩家、匹配队列），Room Server 是临时的（对局结束后销毁）
• Lobby 持久连接，Room Server 短连接：玩家始终与 Lobby 保持连接，对局期间额外连接 Room Server。对局结束后断开 Room Server，回到 Lobby
• 结算数据由 Room Server 写入：避免经过 Lobby 转发，减少一次网络跳转

参考：Bungie 的 Justin Truman 在 GDC 2015 演讲 “Shared World Shooter: Destiny’s Networked Mission Architecture” 中描述了 Destiny 如何在“房间制“和“共享世界“之间做融合——活动（Activity）是房间制的，但多个活动可以共享同一空间。这展示了房间制架构的一个有趣变体。 — https://www.youtube.com/watch?v=Iryq1WA3bzw ⁶

不同游戏类型的约束差异

虽然所有房间制游戏共享同一套问题模型，但不同游戏的约束条件差异很大，导致技术选型不同：

注意：MOBA 和 FPS 虽然都是强实时+房间制，但同步模型可能不同。MOBA 通常用状态同步（服务器权威），FPS 可能用帧同步或混合同步。这将在第4章详细讨论。

小结

1. 房间制游戏的三个核心特征：会话隔离、有限时长、固定人数。这些特征让它们天然适合水平扩展
2. 三个核心问题：房间生命周期、匹配系统、服务器调度。不同游戏的差异在于约束条件不同
3. 匹配系统的核心矛盾是速度与公平性的权衡，几乎所有系统都采用“渐进放宽“策略
4. 架构上采用 Lobby + Room Server 分离，二者职责清晰

下一节（2.3）我们将学习：强实时对战型游戏问题模型，在房间制的基础上深入讨论低延迟和同步的技术挑战。

参考文献

1. 腾讯游戏学院专家 Wade, “经典游戏服务器端架构概述”, https://zhuanlan.zhihu.com/p/336195014 ↩

2. AWS, “Well-Architected Framework: Game Server Processes”, https://docs.aws.amazon.com/wellarchitected/latest/games-industry-lens/game-server-processes.html ↩

3. Tom Minka et al., “TrueSkill 2: An improved Bayesian skill rating system”, Microsoft Research, 2018 ↩

4. Google, “Agones: Host, Run and Scale dedicated game servers on Kubernetes”, https://agones.dev/ ↩

5. Google, “Open Match: Flexible, extensible, and scalable video game matchmaking”, https://open-match.dev/ ↩

6. Justin Truman (Bungie), “Shared World Shooter: Destiny’s Networked Mission Architecture”, GDC 2015, https://www.youtube.com/watch?v=Iryq1WA3bzw ↩