《游戏项目系统工程手册》合订本vol.8

本文出自鸿杰撰写的《游戏项目系统工程手册》第四章——4.3 需求拆分流程、4.4 设计方案确定流程

前文回顾：【PM手册】什么是系统工程？研发管线和制作流程如何规划？

《游戏项目系统工程手册》合订本vol.2

《游戏项目系统工程手册》合订本vol.3

《游戏项目系统工程手册》合订本vol.4

《游戏项目系统工程手册》合订本vol.5

《游戏项目系统工程手册》合订本vol.6

《游戏项目系统工程手册》合订本vol.7

文档信息写给谁：架构师、组长、制作人、技术负责人、游戏设计师 阅读收益：读完本文，你能将设计方案逐层拆解为可执行的开发任务，为每个子任务明确负责人和验收条件；能用WBS和PBS两种视角确保开发工作无遗漏、无重复；能识别团队中因分工模糊导致的冲突并知道如何升级处理

设计方案定义流程（4.2）产出了一套经核准的设计方案（即开发需求集）。这些方案有的指向完整模块，有的指向具体功能，粒度不一。直接把这些方案丢给开发团队，结果是：有人重复做同一件事，有人做的功能没人认领，还有人做到一半才发现跟其他模块冲突。

需求拆分流程的目标，是把设计方案逐层分解，直到每个子任务都有明确的负责人、接口定义和验收条件。下面的流程描述了"谁参与、输入输出是什么、三个核心任务分别做什么"——回答这些问题之后，文章后半段的"流程指南"会展开具体操作方法。

流程描述

图 4.3-1 展示了需求拆分流程的工作流，包括输入、输出和具体任务。

图 4.3-1 需求拆分流程

流程的输入

开发需求集即顶层需求的集合，是需求拆分的源头。后续所有功能分解和任务分解都从它出发，最终结果须能追溯到它。

流程的输出

相关方与职责

冲突升级机制详见任务​2​的​Baseline​选定阶段。

流程中的任务

任务1：架构设计

架构师根据开发需求设计技术架构。技术架构定义目标平台约束、软件、系统模块、数据、网络及玩法之间的关系，把功能单元组织起来，厘清依赖关系和接口。常用方法包括绘制模块依赖图、定义接口契约文档、搭建原型验证关键路径。

复杂项目可设计多个备选方案对比。每个架构方案包含功能单元的技术文档、接口定义和《需求概览》。任务1的产出是候选架构方案集，供任务2评估和选定。

技术预研与决策记录

多方案对比示例： 玩家匹配功能的网络架构可选方案——中心化服务器（延迟可控，但服务器压力大）、P2P模式（服务器负载低，但延迟和作弊风险高）、混合架构（平衡两者，实现复杂度高）。选择取决于团队技术能力、目标平台和项目规模。

技术预研

当架构方案涉及未验证的技术风险时，在正式选定方案前安排限时技术预研。

技术预研的目标是在规定时间内产出技术可行性结论，而非可交付的功能代码。预研耗时按范围分层：局部算法验证2-5个工作日；新引擎或中间件评估1-3周；平台级技术验证应作为独立Sprint规划。

需要做技术预研的典型场景：团队无使用经验的引擎或中间件、性能瓶颈不确定的算法方案、跨平台兼容性未知的技术选型。

技术预研结束后，产出可行性报告，纳入候选架构方案的评估依据。

记录决策 架构设计过程中的每个技术选型及其理由，都应记录为决策点，供任务3汇总。

分层架构设计

需求拆分到架构层的示例：

分层架构的特点：在接口定义不变的前提下，各层可独立开发、独立测试，修改某一层的内部实现不影响其他层。

注意： 以上三层架构适用于传统MVC模式的项目。实际项目中可能出现ECS架构、微服务架构等不同模式，各层职责划分方式会有差异。

任务​2：功能分解与选定​Baseline（基线）

架构设计产出候选架构方案后，程序团队用功能分析方法（将需求转化为功能、再拆解到架构层的技术，具体方法见"功能分析技术"一节）将需求逐层拆解到对应模块。任务2分为两个阶段：功能分解（执行阶段）和Baseline​选定（审批阶段）。

前置条件： 任务1产出的候选架构方案已形成。需求分解过程中发现的问题，应及时反馈到任务1修正架构设计。架构修正后，受影响的需求拆分须重新评估——评估范围取决于架构修正的影响面：如果修正仅涉及单个模块的内部实现，只需重评该模块的功能分解；如果修正改变了接口定义或层级关系，则须重评所有依赖该接口的模块，形成任务1→任务2的闭环。当多个接口同时变更时，按接口依赖层级从低到高依次重评——先评估数据层接口变更的影响，再评估逻辑层，最后评估表现层。

迭代策略： 先基于候选架构做初步功能分解，分解结果反馈修正架构方案，经迭代后锁定​Baseline。建议不超过​2​轮迭代，否则升级到制作人决策——要么强制选定一个方案，要么调整需求范围。升级时应附带以下决策依据材料：各方案的迭代趋势数据（每轮评估的变化情况）、风险评估报告、资源需求对比。

功能分解阶段（执行阶段，负责人：程序组长及各模块负责人）

功能分解的核心目标：识别并定义达成项目目标所必需的功能集（PBS视角），并将它们分配到技术架构的各个层级。功能分解的结果可进一步转化为任务分解（WBS视角），详见"工作分解结构"一节。

功能分解的三个步骤：

1. 将需求转化为必备功能

2. 将功能拆解并分配到对应架构层（表现层、逻辑层、数据层。拆分示例见任务1的"需求拆分到架构层"表格）

3. 描述各功能接口和模块之间的关系

每个功能须写清输入、输出、异常情况和接口要求。分解到最底层时，每个功能必须能向上追溯到顶层需求，确保没有无来源的"孤岛功能"。如果追溯链断裂（某个功能无法追溯到顶层需求），有两种处理方式：如果是拆分时遗漏了上层关联，补全追溯链；如果确认该功能不对应任何顶层需求，则标记为"待确认"并提交架构师裁定是否保留。

需求拆解可以有多种方案，拆解结果取决于团队技术能力和项目经验。

Baseline​选定阶段（审批阶段，负责人：架构师推荐，制作人最终决策）

只有当所有候选方案在可行性上达成共识，Baseline​才能最终确定。共识判定标准：架构师提出推荐方案并给出技术依据，制作人根据项目目标和资源约束做出最终决策。如果被淘汰方案的提出方不认同评估结论，须在决策记录中保留其异议意见和依据，作为后续方案回溯的参考。

冲突解决与升级机制 当团队对架构方案无法达成共识时，按以下规则升级：

• 迭代2轮仍未收敛 → 架构师提出推荐方案，制作人最终决策

• 决策输出选项：强制选定一个方案，或调整需求范围排除争议点

• 相关方之间的其他冲突（如技术预研争议、进度与设计矛盾），同样由制作人仲裁

• 如果制作人也无法决策（如涉及外部合作方的硬性约束），应将问题升级至项目出资方或管理层裁定，并记录未决原因和影响范围

记录决策： Baseline​选定中的备选方案评估、争议点和最终结论，均记录为决策点，供任务​3​汇总。

架构方案选定、需求分配完成后，下一步是收集整个拆分过程中的关键决策信息，确保后续开发有据可查。

任务3：获取阶段产出物

汇总拆分过程中的决策信息。任务1和任务2中标注的"记录决策"动作，在此步骤统一整理。决策依据来源包括：任务1的技术预研（Spike）结论、任务2的方案评估结果，以及拆分过程中出现的需求变更、外部依赖变化（如第三方SDK版本更新、平台政策调整）等信息。

产出物清单：

记录格式：

实际项目中，前提假设应成组出现。每个假设需标注如果假设不成立的影响和应对方案。

拆分完成的验收标准

验收由架构师牵头，各模块负责人参与，在任务​2​的​Baseline​选定阶段同步执行。验收不通过时，须标注不合格项并退回对应的任务环节（功能分解不完整退回任务​2，架构方案不可行退回任务​1），修正后重新验收。退回修正由制作人或​QA​跟踪进度，修正完成后由架构师确认是否触发重新验收。

上述验收标准按项目规模差异化执行：

上表中"可测试"一栏提到了RTM全量追溯。下面说明RTM的用途和结构。

需求-测试追溯矩阵（RTM）

验收标准中的"可测试"项，需要通过需求-测试追溯矩阵（Requirem​ents Traceabi​lity Matrix，RTM）来落实。RTM​是一张需求与测试用例的对应表，确保每条需求至少有一个测试用例覆盖。

RTM在需求拆分阶段建立初始版本，随开发推进持续更新，确保需求变更时不遗漏测试覆盖。RTM由QA主导维护，架构师审核。每次需求变更时，QA在3个工作日内更新RTM的追溯状态。规模适配：独立游戏优先覆盖核心功能，外围需求标注"待补充"。

需求拆分流程指南

上一节描述的是流程框架。具体操作需要两个工具——工作分解结构和功能分析技术。

工作分解结构（WBS & PBS）

WBS的两种构建方法：

两种方法可以结合使用：先用自顶向下确定大框架，再用自底向上补充遗漏的子任务。

分解粒度判断标准——何时停止分解：

满足以上三个条件时，停止分解。任一条件不满足时，继续拆分。

需求拆分流程的总耗时建议控制在项目总开发工期的3%-5%以内。如果拆分工作超过两周仍未收敛，说明需求本身存在重大问题——此时应暂停拆分，回到4.2（设计方案定义流程）重新澄清需求。

WBS与PBS如何配合使用：

先用PBS确定"要交付哪些模块"（产品视角），再用WBS确定"每个模块要做哪些工作"（任务视角）。PBS解决"做什么东西"，WBS解决"怎么把东西做出来"。

WBS的最底层应能落实到具体负责人。

图 4.3-2 产品分解结构示例

功能分析技术

逻辑流程图法——操作步骤：

1. 列出当前系统涉及的所有状态（如：待机、移动、攻击、死亡）

2. 用箭头连接状态转换路径，标注触发条件（如：收到伤害指令→进入攻击状态）

3. 在每个状态旁标注输入、输出和异常处理

4. 检查是否存在无法到达的孤立状态

示例： 玩家背包系统的状态转换——三个核心状态：空（物品数=0）、未满（0 < 物品数 < 最大容量）、满（物品数=最大容量）。触发条件：拾取物品（空→未满，未满→满）、丢弃/使用物品（满→未满，未满→空）。整理背包不改变物品数量，属于状态内操作，不触发状态转换。每个状态转换需标注：物品数量变化、UI更新逻辑、满状态下的拾取拒绝提示。

交互矩阵法——操作步骤：

1. 列出系统中的所有模块（如：背包、装备、商店、战斗）

2. 画一个模块×模块的矩阵表格

3. 在每个交叉格中标注交互类型：数据传递（D）、事件触发（E）、无交互（-）

4. 重点检查标注为D和E的交叉格，定义接口规范

示例： 背包与装备模块的交互矩阵——装备模块从背包读取装备数据（D），装备变更时背包更新物品列表（E），背包与战斗模块无直接交互（-）。

时间线分析法——操作步骤：

1. 画出时间轴（横轴为时间，单位为毫秒或帧）

2. 标注每个动作的开始时间、持续时间和结束时间

3. 标注动作之间的依赖关系（A完成后B才能开始）

4. 标注网络延迟和同步容忍范围

示例： 玩家释放技能的时间线（移动端ARPG典型值，参考主流MOBA和ARPG产品实测数据；PC端或格斗游戏的延迟要求更严格）——第0ms：客户端发送技能指令→第50ms：服务端校验→第100ms：广播伤害结果→第150ms：客户端播放受击动画。每一步的延迟上限需要在时间线上标注。PC端格斗游戏的单次输入到响应延迟通常要求低于66ms（一帧@60fps），服务端校验流程需相应压缩。格斗品类建议以50ms为延迟预算上限，网络同步方案需针对性优化。

不同规模项目的差异

以上方法和工具适用于大多数项目。实际操作中，不同规模的项目在拆分深度和文档要求上有差异。

核心原则:流程服务于项目。小项目过度拆分会增加管理成本，大项目拆分不足会导致责任不清。

需求变更管理

需求拆分完成后，变更不可避免。按变更影响范围分两级处理：

判定责任人：架构师负责鉴定变更范围，制作人确认。对范围判定有争议时，以制作人最终意见为准。

变更记录须标注变更原因、影响范围、审批人和日期，纳入任务3的产出物管理。

常见失败模式

4.4 设计方案确定流程

假设你的团队正在确定一个关键的游戏设计方案。策划提交了一份涵盖多个系统的需求文档，每个系统都有几种不同的实现方式——帧同步还是状态同步、自研物理还是商用插件、单体架构还是微服务。选错了方案，后期的返工成本可能让项目陷入困境。

设计方案确定流程就是解决这个问题的。它的目标是将高层需求转化为可实现的方案。具体而言，就是把已确定的需求拆解后生成多个备选方案，通过评估选型确定最终方案，并输出技术文档，作为后续开发实现和测试验证的依据。

流程定位 本流程主要适用于游戏生命周期的阶段二（预制作）和阶段三（全面制作）。不同规模项目可根据实际情况简化或扩展——独立游戏可简化为「设计方案评审会」，大型项目则需要完整的方案选型流程。具体执行深度见文末「项目规模适配」表。

相关方与职责

流程概述

图 4.4-1 设计方案确定流程的标准工作流，包括该阶段需要考虑的输入、输出和任务。

流程的输入

启动设计方案确定流程时，需准备好以下内容：

• 策划需求：玩家和项目方的原始诉求，包括玩法需求、体验目标、商业目标等。

• 技术需求：策划需求转化后的实现规格，如性能指标、平台要求、技术约束等，包括所有接口需求。

• 项目蓝图：包含功能范围定义、核心系统清单、里程碑节点和资源约束。项目蓝图是方案构思的前提，缺少蓝图将导致备选方案偏离项目目标。

分解方法的选择取决于项目类型：功能分解适用于系统模块拆分，时间线分解适用于流程阶段划分，行为分解适用于 AI 和行为树设计，数据流分解适用于网络同步等场景。各类分解方法的特点和游戏行业示例见下表。

逻辑分解方法与游戏行业示例

核心任务

本流程分为五个环节：方案构思、方案评估与选型、方案细化与定稿、验证与验收、明确辅助需求。其中前四个环节按顺序执行，明确辅助需求（特别是长周期插件/中间件选型）须与方案构思同步启动、尽早锁定，具体需求在方案定稿后最终确认（详见该环节说明）。每个环节的输入来自上一环节的输出，最终产出技术文档和相关计划。

方案构思

方案构思由项目蓝图驱动，生成多个备选方案。各备选方案需附带技术架构草案、运营构想文档和初步需求说明，三份文档之间的一致性将在后续评估与选型环节中通过系统化评分来验证。每个备选方案应附带应急方案（由技术负责人整理维护），覆盖关键依赖无法获取、核心人员流失、技术路线受阻等场景。

构思方法：

注意事项：

• 技术研发、设计流程和 UX 设计之间保持持续互动。

• 避免过度依赖不成熟的技术。评估团队掌握度的建议阈值：

• 团队中缺少该技术的负责人

• 知识集中在 1-2 人手中

• 无人有完整交付经验 满足以上任一条件时，应在方案中标注风险并准备备选技术路线。 例外：若项目以技术差异化为核心竞争力（如采用前沿渲染技术作为卖点），可有意选择低成熟度技术，但须安排专项预研时间并设定熔断标准。

备用方案：每个备选方案应标注对应的备用方案。备用方案与应急方案不同——应急方案针对外部风险（关键依赖无法获取、核心人员流失等），由技术负责人维护；备用方案针对设计替代（在首选方案基础上裁剪非核心特性、替换高风险组件或降低性能指标），是首选方案的可接受降级版本。当首选方案在评估阶段被淘汰或后期实施受阻时，团队可直接切换至备用方案，无需从头重新构思。

随着设计方案的实施，游戏特征逐渐明确，但改动成本持续上升。方案构思阶段的目标是在进度允许的条件下，产出多个可评估的备选方案草案。每个草案需覆盖核心功能路径，并附带初步的成本估算和风险标注。构思阶段信息不完整，成本估算采用​T​恤尺码法（S/​M/​L/​XL 四档快速标注方案规模）或量级估算（允许偏差 -50% 到 +100%），以便进入评估与选型环节进行系统化比较。

方案评估与选型

开发团队或技术组分析每个备选方案，通过系统化评估完成选型。

评估维度：

各维度并非等权重——不同项目类型的侧重点差异显著，需在评分前明确各维度的权重分配。

权重调整说明 各维度权重根据项目类型调整：对战类项目调高「性能与延迟」权重（建议 0.3）；单机内容向项目调高「团队适配度」权重；服务型游戏调高「成本（LCC）」权重。下表示例采用对战类项目的权重分配。

LCC 在游戏项目中的成本构成

单机游戏的 LCC 以研发成本为主，上线后维护成本较低；服务型游戏的运营阶段成本（服务器、带宽、持续更新）往往超过研发阶段（基于行业经验估算，具体比例因用户规模和架构复杂度而异），选型评估时需单独列出运营期年度预算。详细成本项拆分见「附录：LCC 成本项详细估算表」。

选型步骤：

1. 明确技术路线：从项目蓝图提取不可妥协的技术约束（如必须支持的平台、性能底线、合规要求），作为评估的硬性边界

2. 方案评分：按评估维度对每个备选方案逐项打分，汇总加权总分。评分时各角色独立打分后汇总，减少群体思维影响

3. 方案排序：按总分排序，标注各方案的突出优势和关键短板，识别是否存在"高分但高依赖风险"或"低分但高可控性"的异常情况

4. 筛选淘汰：淘汰不满足硬性约束（如预算上限、工期上限）的方案，保留 1-2 个候选方案。若仅剩一个方案，仍需经过评估维度复核，确保其达标而非"仅因存活而胜出"

回退路径 若所有备选方案均被淘汰（不满足硬性约束），则回到方案构思阶段重新生成备选方案。此时应重新审视项目蓝图中的约束条件是否过于严格，或考虑调整需求优先级。若第二轮生成的方案再次全部淘汰，则触发升级机制——由制作人召集技术负责人和策划负责人，裁定是否放宽硬约束、终止该技术方向或提交管理层决策。

评分示例（以某对战系统为例，1 分最低、5 分最高）：

上表中，方案A 的性能与延迟评分 3 分——自研方案的优势在于可控性和定制空间，但初始性能通常不如商用引擎，需多轮优化才能达到同等水平。方案A 团队缺乏自研物理引擎经验（适配度 1 分），研发成本也超出预算硬约束，加权总分最低，因此被淘汰。这体现了硬约束优先于加权总分的筛选逻辑。

为减少团队政治和隐性动机对选型的影响（如高级工程师偏爱熟悉的技术栈、制作人偏向特定供应商等），建议评分前各角色书面提出对方案的倾向和理由，评分时匿名处理，保证评估视角全面。若匿名评分后仍存在分歧，按下表规则仲裁。

团队分歧仲裁：当程序、策划、制作人在选型上出现分歧时，按以下规则处理：

多种分歧同时出现时，按影响范围从大到小依次裁决。例如：外部强加技术要求可能同时引发成本争议和技术可行性争议——先评估外部要求的技术可行性和成本影响，再处理内部优先级争执。

游戏行业常见选型失败模式

方案细化与定稿

选定方案后，需持续细化直到满足以下判断标准：

方案细化到满足上述标准后，需为方案设定一个不可随意变更的基准版本，即 Baseline。将方案归档并纳入配置管理（Configur​ation Manageme​nt，CM）。Baseline 的具体形态包括：冻结的技术设计文档版本、配套的接口定义文档和测试验收标准文档。

Baseline 在游戏项目中的常见形态

• GDD（Game Design Document）版本锁定，标记为不可随意变更的基线版本

• TDD（Technical Design Document）签收记录，经技术负责人和制作人签字确认

• Git tag 或 Perforce label 标记里程碑快照，用于回溯和发布管理

• 配套资源清单冻结（美术规格表、音频规格表等附件同步归档）

Baseline 确立后，团队专注于选定方案的后续开发，后续变更需走正式的变更控制流程（详见第 5 章或项目的配置管理规范）。

方案细化到 Baseline 标准的过程并非线性推进，常见以下三类偏差，各有对应的处理路径：

典型问题与决策示例：

细化阶段常见的问题包括：技术方案在细化过程中实现难度远超预期、第三方库许可证限制影响分发方式、不同模块之间的接口协议存在冲突。遇到此类问题时，决策路径如下：

细化阶段的每个决策都须记录决策理由和参与方，便于后续回溯。

验证与验收

• 测试验证：通过设计评审（同行评审）检查方案是否符合需求。若发现问题，记录问题清单并反馈至方案细化环节修正。

• 验收检查：

验收是一个迭代的过程，直到架构、构想和需求都满足制作人或产品负责人的要求。设定可量化的退出标准有助于控制迭代次数：高优先级问题归零、中优先级问题不超过 5 个（或按项目规模调整：小型项目不超过 3 个，大型项目不超过 10 个）、所有评审意见已闭环处理（含"已知悉不修改"的书面确认）。

这与全面制作阶段中后期功能实现后的 QA 测试不同——本阶段的验收聚焦于设计方案层面的验证。

不同验证方法的实践案例（这些方法可以组合使用，并非互斥）：

问题追踪流程：验证过程中发现的问题按以下等级分类管理：

判定权归属：P0/P1 等级由技术负责人和制作人共同确认，P2 由技术负责人自行判定。如对等级分类存在争议，由制作人终裁。

方案通过验证后，还需明确实施该方案所需的工具链和人力资源——这些辅助要素若在开发启动后才暴露缺失，将直接阻塞进度。如流程概述所述，「明确辅助需求」虽列在流程末尾，其中的长周期项（插件/中间件选型）须在方案构思阶段同步初步识别并尽早锁定，此处聚焦最终确认。

明确辅助需求

根据选定方案，确定需要哪些插件、中间件和人员：

辅助需求若交付延迟，需有应急方案：识别替代工具、调整开发优先级或缩减相关功能范围。若发现关键中间件无法获取或替代方案成本过高，应将此信息反馈至方案评估与选型环节，重新评估技术方案的可行性。由于插件/中间件开发周期长，必须在方案确定阶段尽早明确。

流程的输出

设计方案确定流程的输出，包括提交给技术团队的设计方案和计划。这些文件规定了游戏如何设计、开发、培训及测试，且必须符合审批过的 Baseline。

设计方案确定流程指南

以上是按标准流程展开的五个核心环节。在实际执行中，还有三个需要特别关注的领域——技术评估、UX 评估和工程设计要点，它们贯穿或补充前述流程，以下分别说明。

技术评估

备选方案的技术评估聚焦两个层面：方案可行性评估和新技术成熟度评估。与前述「方案评估与选型」环节的区别在于：评估选型是对多个备选方案横向比较后做决策，而技术评估是对选定方案或关键技术点的纵向深入分析。构成"关键技术点"的判定标准为：(1) 涉及团队未曾交付过的核心技术领域；(2) 依赖未经验证的第三方库或协议；(3) 性能指标超出当前引擎已知上限。满足任一条件即需触发纵向深入分析，两者互为补充。

方案可行性评估关注备选方案本身能否在项目约束内实现。评估内容包括：技术架构是否合理、模块间接口是否清晰、性能指标是否可达。

新技术成熟度评估关注方案中涉及的新技术是否具备落地条件。此处的「技术就绪度」聚焦本项目团队的实战经验（实验室验证 → 原型验证 → 项目实战），与前述评估维度表中的行业级「技术成熟度」（TRL 1-5）互补——前者回答"我们能不能做"，后者回答"行业能不能做"。需从以下三个维度逐项评估：

特殊设计方案指涉及团队未曾交付过的核心技术领域、依赖未经验证的第三方库或协议、或性能指标超出当前引擎已知上限的方案。发现研发难度后需进行技术攻关以验证设计可行性。由于资源有限，优先实现那些最有希望满足设计需求的技术。攻关超时或未达成功标准时，触发熔断机制：回到方案构思阶段重新评估备选方案，或启用备用方案。注意：启用备用方案时，该方案须在当前项目约束下经过评估维度复核（即使是之前已评分的方案，也应重新确认外部依赖、团队适配度等维度的状态未发生变化），确保其达标而非仅因"曾是次选"而自动采用。

需注意，中大型项目（10 人以上）中某些高风险高回报的技术储备（如次世代渲染管线原型）即使短期不直接满足当前需求，也值得分配少量资源持续探索，避免技术债累积至项目后期无法弥补。

若未明确技术研发所需的资源投入就急于确定策划需求，项目将面临风险。技术评估应反复进行，直到策划需求和可用资源都处于可接受的风险范围内（由技术负责人与制作人共同判定，退出标准为：高优先级风险项已制定缓解方案且剩余风险在项目容忍度内——容忍度由制作人在方案评估启动前以"可接受的延期天数"和"可接受的额外成本百分比"两个量化指标明确设定）。

开发团队应帮助项目其他成员理解技术对项目的深远影响，同时策划、制作人和其他角色也应及时向开发团队传递需求变化和项目目标调整。技术研发不仅包括满足策划需求开发新技术，还包括改进老系统、优化运行逻辑或升级开发环境。若系统改进或环境变化超出团队过往经验，应评估是否需要专项技术研发。

UX 评估

技术可行性确认后，还需从玩家视角审视方案——技术可行不等于体验可行。UX 评估的核心是确认设计方案在用户体验层面的可行性。

评估目标：确认玩家在方案设计的能力范围内可以完成预期操作，不会因设计压力导致流失。

评估方法：

评估指标：

尽早把 UX 纳入评估计划，目的是在方案阶段识别体验风险，避免后期因设计不合理而产生高额返工成本。

工程设计要点

在设计方案确定流程中，需关注以下工程特性。

稳定性设计

核心对战系统的稳定性要求最高，普通功能根据资金和风险权衡。稳定性分析要点：

长连接、实时同步、热更新是游戏区别于传统软件的三个持续性运行特征。以下场景直接对应这些特征，需在设计阶段额外关注：

设计团队中应有稳定性分析经验的成员参与。若等方案定稿后再补充稳定性设计，效果会打折扣。

原型验证

原型既是验证设计方案可行性的工具，也可用于探索性目的——在方案不确定时，通过原型试探不同方向的技术边界和设计可能性。原型验证在构思阶段作为生成备选方案的手段，在验证阶段作为确认高风险模块的关卡，两处定位不同但方法相通。

原型验证需明确以下要素：

项目规模适配

不同规模的项目在本流程中的执行深度有差异：

以上是本流程的完整框架。无论项目规模如何，核心原则不变：在改动成本尚低的阶段充分评估备选方案、在信息充分的条件下做决策。下一章将进入游戏开发流程，探讨如何将此处确定的设计方案转化为可交付的游戏版本。

关于作者

鸿杰

• 20年游戏开发经历，游戏美术、全栈美术、主美、技术美术。

• 跨多岗位的全链路经历，让我能从不同角色视角理解项目全流程的痛点，更懂如何让工程方法落地。

• 可关注公众号“系统联结”最快追更《游戏项目系统工程手册》