游戏类型的分类方法

Category

industry / models 子树。节点定位：六个问题给项目分型——共享实时状态？时间精度决定结果？状态是否闭合？最贵故障是什么？平台是否主链路？压力先爆哪端？

Definition

游戏类型如果只能服务市场传播，就不够支撑技术设计。技术上真正有用的分类方法，必须能帮助团队回答三件事：主链路在哪里，最贵的故障在哪里，第一阶段架构应该先为哪些问题付成本。

所以这里不打算重复“RPG、FPS、SLG、卡牌、MMO”的百科定义，而是直接给一套更适合立项、评审和技术选型的分型框架。

Problem

按题材分类支撑不了技术设计；有用的分类必须能回答主链路在哪、最贵故障在哪、第一阶段为谁付成本。六问把品类语言译成工程语言，是后续六种问题模型的共同入口。

不要按题材分，要按失败模式分

从工程角度看，一个分类方法是否有价值，取决于它能不能把系统最容易失败的地方直接暴露出来。比如：

• 某个项目最怕输入延迟、不同步、判定争议和外挂，那它更接近强实时问题。
• 某个项目最怕开局失败、断线回不去、结算错和房间脏状态，那它更接近房间问题。
• 某个项目最怕错发漏发、活动事故、数据污染和补偿失控，那它更接近长周期成长问题。
• 某个项目最怕漏单、重复发货、对账不一致和风控失效，那它更接近平台与经济问题。
• 某个项目最怕掉帧、爆内存、加载雪崩和广播过载，那它更接近高频对象与重表现问题。

如果一个分类方法只能告诉你“这看起来像某类游戏”，却不能告诉你“系统最可能死在哪里”，那它对架构帮助有限。

用六个问题给项目分型

拿到一个新项目时，可以先连续问下面六个问题。

1. 玩家是不是共享同一份实时状态

这是第一问，因为它能最快把项目从“主要是数据与配置问题”分到“必须处理同步与共享状态问题”。

• 如果玩家 A 的一次操作，必须在几百毫秒内改变玩家 B 当前看到的世界，那项目就已经进入房间型、强实时型或持续在线世界型区间。
• 如果玩家之间主要通过排行榜、战报、交易、赠送、联盟和异步进度互相影响，那项目更可能接近长周期成长型或平台型。

这个问题的意义在于先区分“共享实时世界”与“共享长期结果”，因为两者的架构代价完全不同。

2. 结果是不是由时间精度决定

不是所有多人对抗都属于强实时。最直接的判断法是看：50 到 150 毫秒的输入差异，是否足以显著改变胜负。

• 如果会，那同步模型、预测、裁决、回放和反作弊就必须尽早进入核心设计。
• 如果不会，那它可能只是房间对局、回合对抗或带对战外壳的成长系统，不必直接套最高成本的实时架构。

这一问能挡掉很多“有 PVP 就按 MOBA 做”的误判。

3. 核心状态是一局内闭合，还是会长期积累

这个问题决定系统是更像会话型系统，还是更像长期资产系统。

• 一局结束后，大部分运行时状态都能销毁，只留下积分、战绩和奖励，通常更接近单局房间型或强实时型。
• 一次错发、错配、错结算会影响玩家几周甚至几个月，通常更接近长周期成长型。
• 世界状态本身长期存在，玩家和场景、组织、生态关系持续成立，通常更接近持续在线世界型。

判断时不要只问“有没有养成”，而要问“玩家最贵的状态到底在局内，还是在局外”。

4. 最贵的故障是体验故障，还是资产故障

这一步能帮助团队决定系统优先优化“低延迟”还是“强审计”。

• 体验故障优先时，项目更怕卡顿、漂移、掉线回不去、不同步、迁移失败。
• 资产故障优先时，项目更怕漏单、错发、任务错乱、背包污染、活动事故、回档边界失控。

很多讨论之所以混乱，就是因为这两类故障被放在同一层里比较。它们都重要，但主导系统设计的方式完全不同。

5. 外部平台是不是主链路的一部分

问法很简单：没有渠道、支付、广告、社交平台、创作者生态或外部审核，这个产品还能不能完整成立。

• 如果能，平台更多是外围支撑。
• 如果不能，平台与经济能力就已经进入主线。

这意味着账号、订单、回调、风控、对账、审核和适配层，不再是上线前补的集成工作，而是需要正式建模的系统能力。

6. 压力先爆在服务端，还是客户端

这是纯服务端视角最容易忽略的一问。判断方式是：如果在线人数不变，只把同屏对象、技能特效、资源体积和脚本量翻倍，项目会不会先死。

• 如果会，那高频对象与重表现问题就已经是主导约束之一。
• 如果不会，主要矛盾可能仍然在同步、数据或平台链路。

这一步能避免把端上吞吐与资源组织问题，误判成单纯的服务端扩容问题。

一张足够实用的分型表

项目更像这样	主导模型	第一阶段优先设计什么	最怕的线上事故
多人快速成局，结算后局内状态大多清空	单局房间型	匹配、组房、生命周期、重连、结算	开不了局、回不去、结算错
输入时差会直接改变结果	强实时对战型	Tick、同步模型、预测纠正、裁决、回放	不同步、误判、外挂、争议无证据
世界与玩家关系长期存在	持续在线世界型	分区分片、迁移、场景组织、恢复、控制平面	场景卡死、迁移丢状态、合服跨服事故
长期资产和活动驱动留存	长周期成长与异步交互型	资产模型、配置管线、奖励链路、补偿修复	错发漏发、活动事故、数据污染
增长与收入依赖平台和外部生态	经济与平台型	账号、订单状态机、回调补偿、对账、风控	漏单、重复发货、风控失效
同屏对象和表现密度极高	高频对象与重表现型	对象生命周期、资源预算、网络裁剪、性能预算	掉帧、爆内存、加载雪崩、广播过载

如果一个项目同时命中多行，不说明分类失败，反而说明它更接近真实情况。关键是继续判断主次，而不是试图找一个单一标签覆盖一切。

一个直接可用的判断流程

实际做方案评审时，可以按下面顺序分诊：

1. 列出三个玩家最核心的高频行为。
2. 判断这些行为依赖的是实时共享状态、长期资产，还是外部平台。
3. 找出“最贵且最难回滚”的故障链路。
4. 判断这条链路更怕延迟、错判、丢状态、错发资产，还是外部依赖失败。
5. 给项目确定一个主导模型，再标出一到两个次级模型。
6. 第一阶段只围绕主导模型付最高成本，次级模型先做边界和扩展预留。

常见误判

• 把“有 PVP”直接等同于强实时，结果在不必要的同步复杂度上投入过多。
• 把成长型产品当普通 CRUD，忽略审计、补偿和配置事故的长期成本。
• 把平台与经济问题当成上线前收尾，结果账号、订单和对账体系长期失控。
• 把重表现项目当后期优化问题，前期不设预算，后期只能局部救火。

分类方法真正的价值，不是把项目说得更漂亮，而是让团队尽早知道第一阶段该先把钱、时间和复杂度砸在哪一层。

Used By

项目分型评审；技术方案的主导矛盾判断。

Related

关系链：失败模式分类 → 六问 → 分型结果 → 模型选择。上游：models/00（标签转译）。下游：models/02–07（六种问题模型）。

Reference

本页为工程经验归纳。