游戏类型与问题模型

Category

industry / models 子树总览。覆盖：玩法标签转译（00）、六问分型（01）、六种问题模型（02–07）、组合与主次（08）。

Definition

游戏项目不能只按玩家熟悉的品类名词来理解，也不能一上来就跳到抽象技术术语。更稳妥的做法是承认两层事实同时存在：第一层是玩家、市场、团队日常沟通中的玩法类型；第二层是这些玩法背后真正主导架构的技术问题模型。

这一章的目标，就是把这两层关系讲清楚。因为真正决定网络、同步、服务组织、数据治理和运营成本的，通常不是“它叫不叫 RPG、FPS、SLG”，而是下面这些问题：

• 玩家是否共享同一份实时状态。
• 几十到几百毫秒的时差会不会直接改变结果。
• 关键状态是一局内闭合，还是要长期积累几个月。
• 最贵的故障是体验故障、资产故障，还是平台协作故障。
• 压力首先爆在服务端、客户端，还是支付与渠道链路。

如果这些问题没有先分清，团队就很容易两边都做错。一种错法是只按品类名词讨论技术，最后把所有“RPG”都做成一个样；另一种错法是只讲抽象模型，不给项目一个能落回现实玩法的入口。

本章的结构就是为了解决这个断层：

• 先用常见玩法类型建立直观入口。
• 再用可落地的分类方法把项目映射到问题模型。
• 然后分别展开几类最常见、最能主导架构的问题模型。
• 最后说明真实项目为什么往往是组合型，而不是单一标签。

Related

关系链：标签（00）→ 六问（01）→ 单局房间（02）→ 强实时对战（03）→ 持续在线世界（04）→ 长周期成长（05）→ 经济平台（06）→ 高频重表现（07）→ 组合（08）。下游：genres 子树（类型速览）、server/system/networking 树（各模型的技术展开）、树根 industry 总览。

Reference

节点清单见下节。

本章文章

• 常见玩法类型概览：先把行业里最常用的玩法语言和它对应的第一批技术警报绑在一起。
• 游戏类型的分类方法：给出一套比“按 RPG、FPS、SLG 分”更能指导技术判断的分型方法。
• 单局房间型游戏问题模型：讨论以“一局”为边界时，为什么主问题会收敛到匹配、房间、重连和结算。
• 强实时对战型游戏问题模型：讨论时序精度、公平性和裁决权如何共同决定同步体系。
• 持续在线世界型游戏问题模型：讨论世界常驻后，服务组织、迁移、恢复和控制平面为什么会变成主轴。
• 长周期成长与异步交互型游戏问题模型：讨论长期资产、配置、活动和补偿为何会主导系统复杂度。
• 经济与平台型游戏问题模型：讨论支付、订单、渠道、风控和外部平台如何重塑系统边界。
• 高频对象与重表现型游戏问题模型：讨论对象吞吐、资源组织和表现预算为何必须前置进架构设计。
• 模型之间如何组合：说明真实项目如何识别主导模型和次级模型，而不是平均对待所有复杂度。