2.1 游戏类型的分类方法

传统的游戏分类（MOBA、FPS、RPG）是从玩家体验角度划分的。但对于后端开发者来说，“我的游戏是MOBA“这个信息对技术选型的帮助很有限——《英雄联盟》（端游PC+有线网络）和《王者荣耀》（手游+移动网络）虽然都是MOBA，网络架构、同步模型、部署策略完全不同。

本文提出三个技术维度来重新分类游戏：实时性、在线模式、经济复杂度。三个维度组合起来，能直接映射到架构选型。

参考：这种按技术特征而非玩法类型来分析游戏的思想，在 Glenn Fiedler（Gaffer On Games）的网络模型选型文章中有类似体现——他建议根据“权威服务器 vs 客户端权限“和“输入同步 vs 状态同步“来选择网络架构，而非根据游戏类型名称。 — Glenn Fiedler, “Choosing the Right Network Model for Your Multiplayer Game” ¹

维度1：实时性——决定了网络协议和同步模型

实时性是影响后端架构最剧烈的维度。它直接决定你用什么传输协议、需要多复杂的同步机制、以及是否要做客户端预测。

四个实时性等级

回合制（Turn-based）

操作以回合为单位，玩家之间不存在严格的时序依赖。典型如国际象棋、围棋、回合制RPG。

• 网络层：HTTP 轮询或 WebSocket 均可，甚至邮件协议都能用（早期国际象棋就是如此）
• 同步模型：不需要实时状态同步，服务器只需保证“回合顺序“正确
• 容忍延迟：几乎无上限，几分钟甚至几小时都可以

参考：Fabien Christen 在 “Networking of a Turn-Based Game” 中从形式化角度分析了回合制游戏的网络设计，指出回合制游戏的核心约束是“操作顺序“而非“操作时序“。 — https://longwelwind.net/blog/networking-turn-based-game/ ²

弱实时（Weak Real-time）

操作有实时性要求，但容忍度较高（几百毫秒级）。典型如卡牌对战（皇室战争）、回合制MMO（梦幻西游手游）、SLG策略游戏。

• 网络层：WebSocket 或 TCP 长连接即可满足
• 同步模型：状态同步，不需要客户端预测
• 容忍延迟：通常 200-500ms

强实时（Strong Real-time）

操作响应必须在百毫秒内，否则体验明显劣化。典型如 MOBA（英雄联盟、王者荣耀）、FPS（CS:GO、守望先锋）、大逃杀（PUBG）。

• 网络层：UDP 或基于 UDP 的可靠协议（KCP、QUIC），TCP 的重传机制在此场景会导致不可接受的延迟尖刺
• 同步模型：状态同步 + 客户端预测 + 服务器回溯（Lag Compensation），或帧同步
• 容忍延迟：通常 < 100ms

参考：Valve 在 Source 引擎的官方文档 “Source Multiplayer Networking” 中详细描述了强实时 FPS 的网络模型：服务器以固定 tick rate（通常 64或128Hz）运行模拟，客户端发送用户命令，服务器执行并广播状态快照。 — https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ³

参考：ITU-T G.1051（2023）标准将“交互式在线游戏“的最大单向延迟阈值定义为 50ms（5QI class 3），这从电信标准层面量化了强实时游戏的延迟要求。 — https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.1051-202303-I!!PDF-E&type=items ⁴

超实时（Ultra Real-time）

对延迟极度敏感，通常要求 < 50ms 甚至更低。典型如格斗游戏（街霸、铁拳）、音乐节奏游戏、VR多人游戏。

• 网络层：必须 UDP，且需要特殊优化（如帧同步 + 回滚）
• 同步模型：确定性帧同步（Deterministic Lockstep）+ 回滚（Rollback），参考 GGPO 网络
• 容忍延迟：< 50ms，通常目标 16ms 以内（一帧）

参考：帝国时代的首席程序员 Mark Terrano 和 Paul Bettner 在 GDC 演讲 “1500 Archers on a 28.8” 中开创性地将 RTS 游戏的同步问题转化为“确定性帧同步 + 滑动窗口“模型。这篇演讲是理解帧同步思想的经典材料。 — https://zoo.cs.yale.edu/classes/cs538/readings/papers/terrano_1500arch.pdf ⁵

延迟阈值的来源

上述分级中的延迟数值（500ms、100ms、50ms）并非精确的硬边界，而是行业实践中形成的经验区间。Kjetil Raaen 在其博士论文 “Response Time in Games” 中系统测量了不同游戏类型的响应时间需求，结论是：

• 回合制：响应时间对体验几乎无影响
• 弱实时：200-500ms 内可接受
• 强实时：100ms 是体验分水岭，超过后玩家能感知到明显延迟
• 超实时：50ms 以下才能保证体验

— Kjetil Raaen, “Response Time in Games: Requirements and Improvements”, Simula Research Laboratory http://home.simula.no/~paalh/students/KjetilRaaen-phd.pdf ⁶

实时性如何影响技术选型

实时性等级直接决定了以下技术选择：

维度2：在线模式——决定了服务器架构和数据持久化策略

在线模式描述的是“玩家之间如何产生交互“，它决定了你的服务器拓扑结构。

四种在线模式

单机（Offline）

无服务器参与，或仅在启动时做版权验证。存档在本地。

技术关注点：本地存档加密/防篡改（如果在意的话）。

弱联网（Lightly Online）

核心玩法是单机，但附加联网功能（排行榜、云存档、成就同步）。典型如单机手游加排行榜、开心消消乐。

技术关注点：

• 数据同步：本地进度如何与服务器同步
• 离线处理：断网时如何降级
• 防作弊：单机数据上传时的校验

房间制（Session-based）

玩家通过匹配进入一个独立的房间（对局），房间有明确的生命周期（创建→等待→游戏中→结算→销毁）。房间之间互不影响。典型如棋牌、MOBA、FPS、大逃杀。

这是最常见的多人游戏模式。技术关注点：

• 匹配系统：如何快速找到合适的对手/队友
• 房间服务器调度：如何高效创建和销毁房间进程
• 对局状态管理：房间内的状态如何同步和仲裁
• 断线重连：玩家掉线后如何恢复对局

参考：腾讯游戏学院专家 Wade 在“经典游戏服务器端架构概述“中系统列举了几种经典架构，其中对房间制架构（包含 Lobby 服务器、房间服务器、游戏服务器）的进程关系有清晰描述。 — https://zhuanlan.zhihu.com/p/336195014 ⁷

参考：Riot Games 工程师在 GDC 演讲 “Evolving the Server-Side Architecture of League of Legends” 中回顾了英雄联盟服务器架构的演进历程，展示了房间制游戏从简单到复杂的典型路径。 — https://gdcvault.com/play/1020404/Evolving-the-Server-Side-Architecture ⁸

持久化世界（Persistent World / MMO）

所有玩家共享一个持续存在的虚拟世界，世界状态在玩家下线后仍然运行。典型如 MMORPG（魔兽世界、最终幻想14）、沙盒生存（Rust、ARK）。

技术关注点：

• AOI（Area of Interest）：如何高效管理大量玩家在同一空间中的可见性
• 世界分片（Sharding）：如何将世界拆分到多个服务器进程
• 数据持久化：如何高效存储和加载海量玩家数据
• 跨服交互：不同分片/服务器的玩家如何交互

参考：EVE Online 是极少数采用“单世界“（Single-Shard）架构的 MMO——所有玩家在同一个服务器集群中，而非传统的分区/分服。CCP Games 在 GDC 演讲 “The Server Technology of EVE Online” 中详细讲解了如何支撑30万+在线玩家的单世界架构。 — https://gdcvault.com/play/1030721/The-Server-Technology-of-EVE ⁹

参考：MMO 架构中数据 I/O 层面的瓶颈分析，可参考 prdeving 的 “MMO Architecture: Source of Truth, Dataflows, I/O Bottlenecks”。 — https://prdeving.wordpress.com/2023/09/29/mmo-architecture-source-of-truth-dataflows-i-o-bottlenecks-and-how-to-solve-them/ ¹⁰

在线模式如何影响架构

维度3：经济复杂度——决定了安全要求和事务处理需求

经济系统复杂度往往被低估，但它对后端架构的影响不亚于前两个维度。核心原因是：涉及虚拟货币的操作，其安全要求远高于普通游戏逻辑。

四个复杂度等级

无经济（No Economy）

没有虚拟货币系统，或者只有纯装饰性物品。典型如纯 PvP 竞技游戏。

技术影响：无特殊要求。

简单经济（Simple Economy）

有1-2种虚拟货币（如金币+钻石），玩家只能与系统交互（买商城道具、升级消耗），不存在玩家间交易。

技术影响：

• 所有货币变动在服务器端完成，客户端只展示结果
• 需要防刷单检测（异常获取、重复领取）
• 事务性要求不高（单用户操作，不会出现并发冲突）

复杂经济（Complex Economy）

多种货币、复杂的产出/消耗循环、可能有拍卖行。典型如 MMORPG 的经济系统。

技术影响：

• 需要事务保证（数据库层面 ACID）
• 需要经济监控（产出/消耗的统计和告警）
• 拍卖行是典型的并发热点

玩家交易（Player Trading）

允许玩家间直接交易或通过市场自由定价交易。典型如梦幻西游的摆摊、EVE Online 的市场。

技术影响：

• 事务要求极高（必须保证双方原子性）
• 反外挂/反刷单要求极高（RMT 问题）
• 可能需要审计日志（交易记录不可篡改）
• 经济监控必须实时化（否则经济崩溃无法及时止损）

参考：EVE Online 的经济系统被认为是游戏史上最复杂的虚拟经济之一，甚至有专职经济学家（Economist）负责监控。CCP Games 在 GDC 演讲中提到 EVE 的经济数据量级和监控需求。 — https://gdcvault.com/play/1030721/The-Server-Technology-of-EVE ⁹

经济复杂度如何影响后端设计

三个维度的组合分析

单独看每个维度，只能做局部决策。真正的架构选型需要三个维度组合来判断。

组合示例

以几个真实游戏为例，用三个维度分析：

《英雄联盟》（端游）

→ 技术推论：需要 UDP 级别的低延迟协议 + 房间制架构 + 服务器权威判定。经济系统不是架构瓶颈。

参考：Riot Games 在其工程博客 “Determinism in League of Legends: Implementation” 中讨论了游戏确定性的处理方式，对理解 MOBA 同步机制有直接参考价值。 — https://www.riotgames.com/en/news/determinism-league-legends-implementation ¹¹

《梦幻西游》手游

→ 技术推论：TCP/WebSocket 即可，但需要 MMO 级别的分布式架构 + 严格的交易事务保证 + 实时经济监控。

《CS:GO》

→ 技术推论：极度关注网络层优化 + 反作弊。经济系统不是关注点。

参考：Valve 的 “Lag Compensation” 文档详细描述了 FPS 游戏中服务器端如何做时间回溯来实现延迟补偿，是理解强实时 FPS 网络架构的必读材料。 — https://developer.valvesoftware.com/wiki/Lag_Compensation ¹²

《EVE Online》

→ 技术推论：架构复杂度的核心瓶颈不在实时性，而在单世界的并发处理和经济系统的事务保证。

组合决策树

用以下步骤快速定位你的游戏：

第一步：确定实时性等级
├─ 延迟不影响体验 → 回合制
├─ 几百ms可接受 → 弱实时
├─ 必须百ms以内 → 强实时
└─ 必须一帧以内 → 超实时

第二步：确定在线模式
├─ 无联网需求 → 单机
├─ 联网是辅助功能 → 弱联网
├─ 核心玩法在房间/对局中 → 房间制
└─ 核心玩法在持久化世界中 → MMO

第三步：确定经济复杂度
├─ 无虚拟货币 → 无经济
├─ 有货币但无玩家交易 → 简单经济
├─ 多货币+拍卖行 → 复杂经济
└─ 玩家自由交易 → 玩家交易

分类后的阅读路径

确定你游戏的三个维度分类后，可以直接跳转到对应章节：

小结

1. 不要用传统分类做技术选型。MOBA、FPS、RPG 是玩家视角的分类，对后端开发者帮助有限
2. 用三个技术维度分类：实时性（决定网络和同步）、在线模式（决定服务器架构）、经济复杂度（决定安全和事务）
3. 三个维度组合判断，单独看任何一个维度都不够
4. 分类完成后，按推荐阅读路径深入学习

下一节（2.2）我们将学习：单局房间型游戏问题模型，了解棋牌、卡牌、MOBA 的技术架构。

参考文献

1. Glenn Fiedler, “Choosing the Right Network Model for Your Multiplayer Game”, https://mas-bandwidth.com/choosing-the-right-network-model-for-your-multiplayer-game/ ↩

2. Fabien Christen, “Networking of a Turn-Based Game”, https://longwelwind.net/blog/networking-turn-based-game/ ↩

3. Valve, “Source Multiplayer Networking”, https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ↩

4. ITU-T G.1051, “Latency Measurement and Interactivity”, 2023, https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.1051-202303-I!!PDF-E&type=items ↩

5. Mark Terrano, Paul Bettner, “1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond”, GDC, https://zoo.cs.yale.edu/classes/cs538/readings/papers/terrano_1500arch.pdf ↩

6. Kjetil Raaen, “Response Time in Games: Requirements and Improvements”, Simula Research Laboratory, http://home.simula.no/~paalh/students/KjetilRaaen-phd.pdf ↩

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

8. Riot Games, “Evolving the Server-Side Architecture of League of Legends”, GDC, https://gdcvault.com/play/1020404/Evolving-the-Server-Side-Architecture ↩

9. CCP Games, “The Server Technology of EVE Online: How to Cope with 300K Players”, GDC, https://gdcvault.com/play/1030721/The-Server-Technology-of-EVE ↩ ↩2

10. prdeving, “MMO Architecture: Source of Truth, Dataflows, I/O Bottlenecks”, https://prdeving.wordpress.com/2023/09/29/mmo-architecture-source-of-truth-dataflows-i-o-bottlenecks-and-how-to-solve-them/ ↩

11. Riot Games, “Determinism in League of Legends: Implementation”, https://www.riotgames.com/en/news/determinism-league-legends-implementation ↩

12. Valve, “Lag Compensation”, https://developer.valvesoftware.com/wiki/Lag_Compensation ↩