常见玩法类型概览

Category

industry / models 子树。节点定位：玩法标签（MOBA/卡牌/MMO/放置）是沟通语言不是架构结论——映射表把标签译成技术问题模型。models 子树入口。

Definition

技术分析不能跳过玩家熟悉的玩法语言。因为立项、竞品、发行、招聘、团队日常沟通，几乎都是先从“这是个 MOBA”“这是个卡牌”“这是个 MMO”“这是个放置”开始。真正有问题的不是玩法标签本身，而是把玩法标签直接当成架构结论。

这一页的作用，就是把常见玩法类型和它们最先暴露出的技术警报绑在一起。它不负责替代后面的模型分析，但负责给后面的模型分析一个现实入口。

Problem

立项、竞品、招聘全用玩法语言沟通，但把标签直接当架构结论必然误判：同样叫 RPG，技术形态可能完全不同。标签的价值是索引到问题模型，不是替代分析。

玩法标签能解决什么，不能解决什么

玩法标签至少有三种现实价值：

• 它能快速建立体验预期，让团队先对玩家核心循环形成基本共识。
• 它能提前暴露第一批技术压力，比如 MOBA 会先让人想到同步，MMO 会先让人想到世界状态，放置会先让人想到长期资产。
• 它能帮助新人先用熟悉语言进入问题，再逐步下钻到更抽象的问题模型。

但它也有明确边界：

• 它不能代替状态分析，因为同样叫 RPG，可能分别落在强实时、持续在线或长周期成长问题上。
• 它不能代替故障分析，因为“同属卡牌”不代表最贵事故都一样。
• 它不能直接给出技术选型，因为玩家标签只告诉你外形，不告诉你主链路成本落点。

所以正确做法不是抛弃玩法分类，而是先承认这层分类，再继续往下钻。

一张够用的映射表

玩法类型	玩家最先在意什么	技术上的第一警报	常见主导模型
棋牌 / 桌面对局	公平、顺序、托管、结算	房间状态机、随机可信、争议证据	单局房间型
派对 / 房间制轻竞技	开局快、能组朋友、掉线能回	匹配、组房、广播、重连	单局房间型
MOBA	手感、公平、技能博弈、团战	同步、裁决、回放、反作弊	强实时对战型
FPS / TPS / 战术射击	枪感、命中、视角、公平	命中判定、弱网、补偿、外挂	强实时对战型
格斗 / 竞速 / 体育对抗	帧感、先后手、极限操作	回滚、确定性、输入延迟	强实时对战型
RTS / 即时战术	多单位控制、全局运营	命令同步、路径、批处理更新	强实时对战型 / 高频对象型
卡牌 / CCG / 自走棋	构筑、随机、阵容、结算	状态机、RNG、效果链、经济系统	长周期成长型 / 房间型
回合制 RPG / 战棋	结算顺序、数值、说明一致性	效果链、断点恢复、日志复盘	长周期成长型
MMORPG / 大世界在线	长期角色、世界共存、公会社交	分区分片、迁移、跨服、运维	持续在线世界型
ARPG / 刷宝 / 副本驱动	战斗爽感、Build、掉落成长	技能系统、房间副本、资产审计	组合型
放置 / 经营 / 模拟养成	长线积累、离线收益、活动节奏	资产一致性、离线结算、配置运营	长周期成长型
SLG / 4X / 赛季沙盘	城建、联盟、行军、赛季	持续世界、异步协作、关系链	持续在线世界型 / 长周期成长型
生存 / 建造 / 沙盒	建造、破坏、共享世界	对象持久化、区域负载、资源组织	持续在线世界型 / 高频对象型
Roguelike / Roguelite	重开速度、随机感、局外成长	随机种子、复现、局内外切分	房间型 / 长周期成长型
UGC / 平台生态	创作、分享、分发、交易	审核、权限、沙盒隔离、生态治理	经济与平台型

这张表的目的，不是把项目塞进唯一答案，而是让团队先知道应该警惕哪类问题会最早出现。

几类最容易误判的玩法

棋牌 / 桌面对局

这类玩法经常因为操作简单而被误判成“技术也简单”。实际上它们对以下几点要求非常硬：

• 顺序不能错。
• 随机过程必须可信。
• 断线托管要可恢复。
• 争议局要能复盘。
• 结算必须可审计。

所以它的核心矛盾通常不是低延迟，而是房间状态机、权威裁决和证据留存。

派对 / 房间制轻竞技

这类玩法玩家最先感知的是能不能快速开局、组队、拉人、掉线回来继续玩。它常见的技术重心是：

• 匹配和组房效率。
• 房间生命周期清晰。
• 广播和快照恢复可靠。
• 散局、结算和异常销毁干净。

最常见的错误，是把“轻竞技”误解成“后端也轻”，最后炸在开局链路和房间尾部状态上。

MOBA / FPS / 格斗 / 竞速

这些玩法外形不同，但有一个共同点：时间精度直接影响结果。于是它们都会把问题推向：

• 同步模型。
• 裁决权划分。
• 预测、补偿与纠正。
• 回放与争议证据。
• 反作弊。

这里真正的技术结论不是“它有 PvP”，而是“它已经进入强实时问题区间”。

卡牌 / 回合制 / 自走棋

这类玩法常被误判为“网络轻、技术轻”。实际上它们虽然不一定怕毫秒级延迟，却很怕：

• 效果链解释不清。
• 状态机出现脏状态。
• 随机过程不可复盘。
• 长周期卡池、资源和活动系统失控。

所以这类玩法常常是“实时性不高，但结算复杂度和长期资产复杂度很高”。

MMORPG / SLG / 大世界在线

这几类玩法常见的共同特征不是战斗形式，而是：

• 世界不会因为一局结束而整体销毁。
• 角色和组织关系长期存在。
• 迁移、扩缩容、跨服和恢复是日常问题。
• 运维和控制平面迟早进入主线。

它们真正重的地方，往往不是单场战斗，而是世界长期活着这件事本身。

ARPG / 刷宝 / 副本驱动

ARPG 是最典型的组合型玩法之一。它往往同时要求：

• 战斗手感成立。
• 技能、Buff、词缀和构筑系统足够复杂。
• 掉落和长期成长足够有驱动力。
• 副本或房间生命周期可高频周转。

所以它通常不会只落在一个模型里，而是强实时、房间生命周期、长线资产三种压力一起出现。

放置 / 经营 / 模拟养成

这类玩法不怕几十毫秒的输入误差，但极度怕：

• 错发漏发。
• 计时器和离线收益错乱。
• 活动配置事故。
• 资源污染和补偿失控。

因此它的技术难度通常集中在长期资产、配置系统、离线结算和运营链路，而不是局内同步。

UGC / 平台生态

一旦产品核心从“玩官方内容”变成“生产、分享、分发、交易内容”，技术边界就已经变了。关键问题会迅速转向：

• 内容审核。
• 创作者权限与沙盒隔离。
• 举报、治理和生态规则。
• 收益分配与对账。

这类产品最容易被误判成“游戏加编辑器”，但只要生态开始自增长，它很快就会变成平台工程问题。

为什么同样叫 RPG，技术形态可能完全不同

“RPG”是最容易误导技术讨论的标签之一。因为它可能包含：

• 回合制 RPG
• ARPG
• MMORPG
• 放置养成 RPG
• Roguelite RPG

这些项目的技术重心可能分别落在：

• 效果链与状态机
• 强实时战斗
• 持续在线世界
• 长期资产与活动系统
• 程序生成与局内局外切分

也就是说，玩家标签可以帮助项目进入讨论，但不能替代问题模型分析。

这一页应该怎么和后文配合

更合理的使用方式是两层下钻：

1. 先用玩法类型建立体验入口和第一批技术直觉。
2. 再用后面的模型分析判断主链路真正落在哪。

举例来说：

• 说“这是 MOBA”，是在说明玩家体验外形。
• 说“它是强实时对战型主导”，才是在说明架构主轴。

少了第一层，内容会显得脱离现实；少了第二层，架构讨论就会停在标签层面。

Used By

立项沟通到技术分析的转译；竞品分析的第一层定位。

Related

关系链：标签 → 映射表 → 易误判玩法 → 同名异构 → 与后文配合。上游：methodology/02（类型三输入）。下游：models/01（六问分型法）。

Reference

本页为工程经验归纳。