从玩法到架构的分析方法

Category

industry / methodology 子树。节点定位：五步分析法——玩家行为 → 状态归属 → 链路时效 → 部署组织 → 故障恢复，从玩法循环推到技术实现，而不是从组件倒推。

Definition

游戏架构分析最容易犯的错，是从技术组件倒推需求：先讨论要不要微服务、要不要 ECS、要不要 Actor、要不要 Redis，再去给这些方案找适配场景。更稳妥的顺序应该反过来，从玩法循环开始，逐层推到状态、链路、边界和技术实现。

Problem

从技术组件倒推需求（先讨论要不要微服务/ECS/Redis 再找场景）是最常见的分析病：方案先行，问题失配。分析必须从玩家反复做什么出发，逐层推到状态归属、链路时效、组织方式与恢复设计。

第一步：先看玩家反复做什么

架构服务的不是“功能列表”，而是高频行为。分析时先抓核心循环：

• 玩家是在短时间内反复开局、结算、再开局。
• 还是长时间停留在同一世界里持续移动、交互、成长。
• 还是主要围绕养成、收集、经营、活动和异步社交。

核心循环决定系统最忙的链路在哪里，也决定故障最不能出现在哪里。对于房间游戏，进房、开局、同步、结算是命门；对于成长型产品，登录、角色加载、配置刷新、奖励发放、活动结算更关键。

第二步：识别状态归属

接下来要问的不是“放哪个库”，而是“谁拥有这个状态的最终解释权”。常见状态大致分为：

• 瞬时交互状态：如局内位置、技能、子弹、碰撞、倒计时。
• 会话状态：如房间成员、匹配进度、临时 Buff、局内掉线信息。
• 长期持久状态：如角色属性、库存、任务、付费记录、排行积分。
• 平台与治理状态：如实名、防沉迷、风控标签、处罚记录、客服审计。

状态归属一旦定义清楚，很多技术问题自然就落位了。局内战斗状态适合靠权威战斗节点推进，长期角色资产适合落入可审计的数据存储，平台治理状态通常不能散落在业务服务里随意修改。

第三步：识别链路时效性

不是所有请求都值得走同样昂贵的架构。需要区分：

• 必须毫秒级反馈的链路。
• 可以百毫秒到秒级处理的链路。
• 可以异步落地、稍后对账的链路。

一旦把时效性混在一起，系统就会要么过度设计，要么关键体验不达标。比如把支付补单、埋点清洗和战斗同步塞进同一套实时执行路径，最后通常三者都做不好。

第四步：推导部署和组织方式

当玩法循环、状态归属和链路时效性都清楚后，才轮到架构形态：

• 房间是否要独占执行上下文。
• 世界是否要按地图、分区、Shard 或逻辑域拆分。
• 匹配、战斗、聊天、背包、活动这些能力是合并还是拆开。
• 哪些服务必须强隔离，哪些服务更适合共享底座。

这里的关键不是“拆得越细越先进”，而是让主链路简单可控，让外围链路能独立演进。

第五步：把故障恢复一起设计

游戏系统不能只设计正常路径。任何架构分析都必须同时回答：

• 掉线后玩家怎么回来。
• 节点重启后状态怎么恢复。
• 版本不一致时哪些链路必须拒绝，哪些链路可以兼容。
• 平台接口失败时如何重试、补偿和审计。

如果恢复策略是事后补的，通常说明前面的状态和边界定义还不够扎实。

常见错误

• 直接复用上一个项目的架构，而不重新分析当前玩法循环。
• 只看功能，不看状态，把“背包、商城、邮件”视为彼此独立模块。
• 只设计正常流程，不设计掉线、重试、回滚和补偿。
• 过早迷信某种工程风格，比如“全部微服务化”或“全部单进程化”。

从玩法推到架构的意义，不是让分析过程更学术，而是让每个技术决定都有明确来源。架构应该能被追溯回玩家行为和系统约束，而不是追溯回团队过去熟悉的工具。

Used By

架构分析与评审的方法论；新玩法的技术评估流程。

Related

关系链：玩家行为 → 状态归属 → 链路时效 → 部署组织 → 故障恢复。上游：methodology/02（三输入）。下游：methodology/04（取舍的具体展开）。

Reference

本页为工程经验归纳。