团队规模	应完成的任务	实践建议
独立游戏（<10人）	核心任务（识别需求方、理解项目蓝图、确定需求-目的-目标、建立游玩体验构想、定义项目蓝图、获得认可、形成GDD）	省略复杂文档和正式评审
中型团队（10-50人，或周期≥6个月）	核心任务 + 重要任务（用有效性指标分析需求、确认需求具备双向溯源性）	文档留痕，评审简化
大型项目（>50人，或周期≥18个月）	全部任务（增加：获取工作产品——决策记录、依据说明、经验教训总结）	所有产出物文档化，走正式评审流程

分类优先规则：当团队人数和项目周期分属不同档次时，以更高的档次为准。例如10人团队做18个月的项目，按大型项目执行。

前置条件

输入项	说明
需求方的期望	发行商、制作人或项目负责人提出的需求、目标、要求和限制。需求方的直接期望是针对整个项目的，传达到策划、程序、美术层面时需转化为部门目标。注意：需求方的期望未必清晰完整，本流程的目标之一就是帮助他们把模糊想法转化为具体目标
其他相关方期望	QA团队、UX团队等的期望
额外支持	从公司层面可以提供的支持或资源

流程

图 4.1-1 展示了项目蓝图澄清流程的全貌：左侧为前置信息（需求方期望、相关方期望、额外支持），中间为核心任务的执行顺序，右侧为本流程的输出物。

流程概述

本流程包含以下关键任务：识别需求方、理解项目蓝图、确定需求-目的-目标、建立游玩体验构想、定义项目蓝图、用有效性指标分析需求、确认双向溯源性、获得需求方认可、形成GDD。

关键任务

识别需求方

需求方是指与项目有关联、会影响到项目的人或组织。不同阶段面对的需求方不同，下表列出各阶段的典型需求方：

项目阶段	需求方示例
阶段一（预研阶段）	公司管理层、战略部、外部顾问、发行方
阶段二（预制作）	制作人、主创团队
阶段三前期（全面制作-功能开发）	程序团队、美术、策划、制作人
阶段三后期（全面制作-集成打磨）	程序团队、反外挂组、运营部门、QA、供应商、制作人
阶段四（测试与打磨）	程序团队、反外挂组、运营、运维、验收团队
阶段五（上线与发行）	玩家、公司管理层、运营部门、反外挂组、运维、制作人、政府审批机构
阶段六（运营）	玩家、公司管理层、反外挂组、合规部门、公众、政府审批机构

从上表可以看出：越接近上线，需求方的范围越广——从内部管理层扩展到执行团队，再到外部玩家和监管机构。早期需求方以决策层为主，后期以执行层和外部方为主。

各方关注点差异

相关方	核心关注	常见诉求
发行商	投资回报、市场表现	按时上线、降低风险
PM	项目进度、资源利用	清晰的需求、稳定的设计
QA	可测试性、验收标准	明确的功能边界、可量化的指标
运营	长期表现、数据指标	可运营性、数据埋点需求

理解项目蓝图

通过会谈、调研、市场分析等手段，明确游戏的最终形态或目标，以及限定的资源（时间、成本、性能等）。

需求方会谈问题清单 以下是会谈中建议覆盖的问题，帮助需求方把模糊想法转化为具体目标：

• 玩家打开游戏后第一眼看到什么？第一个操作是什么？

• 玩家玩30分钟后应该体验到什么？玩3小时后呢？

• 这个游戏和市面上的同类产品比，最大的区别在哪里？

• 什么情况下你会认为这个项目失败了？

• 预算和上线时间的硬性底线是什么？

市场分析数据维度 理解蓝图时，以下数据维度帮助团队判断方向：

• 竞品表现：同品类Top3产品的下载量、收入、评分

• 目标市场规模：目标地区的该品类玩家数量和付费能力

• 趋势判断：该品类在过去12个月的搜索指数变化

需求方参与 在项目的每个阶段都要让需求方参与进来，建立反馈循环。这能建立信任，也是最后验收产品的依据。

程序团队沟通 程序团队需要和各领域专家（服务器架构、反外挂、用户体验调优、QA）多沟通。收集完整的期望集，可以避免后期出现"惊喜"（如突然发现需要加密算法，导致成本增加）。

约束条件清单收集需求时，必须同时收集以下约束：

• 预算限制：研发预算、运营预算

• 时间限制：上线时间、版本节点

• 技术限制：引擎版本、平台要求、兼容性

• 合规限制：分级标准、地区法规、平台审核

确定需求、目的和目标

引导各方表达真实想法，通过反复沟通达成共识。明确决策权归属。通过定义以下三个概念，形成"需求-目的-目标框架"：

需求-目的-目标三要素

• 需求：定义要解决的问题——不是"玩家想要什么"，而是"我们要解决什么问题"

• 目的：描述关键问题的处理手段

• 目标：游戏输出要达到的水准，要独特、可衡量、有挑战性

操作步骤

步骤	动作	说明
引导各方表达	用会谈问题清单逐个访谈	让每个人说出自己的真实想法，避免"会议沉默"
识别冲突	将各方意见并列对比	标记矛盾点（如发行商要求"3个月上线"vs制作人要求"品质优先"）
处理冲突	由决策权归属方做最终裁定	冲突不可怕，可怕的是没有明确的裁定人
一致性检查	确认需求、目的、目标三者不矛盾	需求定义问题，目的是手段，目标是量化结果，三者形成因果链

案例：一个RPG游戏的需求-目的-目标

• 需求：市面上缺乏好剧情的RPG，玩家对剧情深度有期待但少有产品满足

• 目的：通过分支剧情和多结局，让玩家感受到选择有意义

• 目标：

• 主线剧情30小时以上

• 至少3个不同结局

• 玩家满意度4.5/5以上

• 首月销量50万份

常见错误

• ❌ 需求：玩家想要好玩的游戏（这是玩家期望，不是要解决的问题）

• ❌ 需求：做一个像《原神》的游戏（这是模仿方向，不是问题定义）

• ✅ 需求：市面上缺乏好剧情的RPG，玩家对该品类有期待但少有产品满足（定义了要解决的市场问题）

• ✅ 需求：目标用户群（25-35岁轻度玩家）缺少能在碎片时间体验的策略游戏（定义了用户场景问题）

建立游玩体验构想

需求和目标确定后，接下来把抽象的目标转化为具体的体验描述——这就是游玩体验构想。它从玩家视角出发，描述游戏系统如何工作、创造什么体验。

游玩体验构想与项目蓝图的分工

文档	回答的问题	侧重点
项目蓝图	我们要解决什么问题？达到什么水准？	方向和约束
游玩体验构想	玩家在游戏中具体做什么？感受到什么？	体验和操作

类比：项目蓝图好比"建筑的功能需求书"（几室几厅、面积、预算），游玩体验构想好比"效果图"（呈现采光、动线、氛围）。

游玩体验构想的核心要素

• 核心循环：玩家在游戏中重复执行的核心行为链（如：探索→战斗→获取→成长）

• 体验关键词：用3-5个词概括目标体验（如：紧张、自由、协作）

• 关键场景描述：选取2-3个典型场景，描述玩家在其中的操作和感受

文档结构模板

章节	内容	示例
目标玩家画像	年龄、游戏经历、偏好品类	25-35岁，有RPG经验，偏好剧情驱动
核心循环	玩家重复执行的行为链	探索→战斗→获取→成长→探索
体验关键词	3-5个概括目标体验的词	沉浸、紧张、自由、成就感
关键场景	2-3个典型场景的操作和感受	场景1：首次进入开放世界，看到远处的山脉，自由选择方向
分阶段体验目标	原型/Alpha/Beta/上线各阶段的体验标准	原型阶段：核心循环可跑通
与蓝图的对应关系	每个体验要素对应哪条蓝图目标	核心循环→目标"主线剧情30小时以上"

定义项目蓝图

当大家的意见一致后，把共识整理为正式的《项目蓝图》文档。

撰写步骤

步骤	动作	产出
整合前序产出	将需求-目的-目标框架、游玩体验构想的结论汇总	统一的观点清单
提炼蓝图要素	从观点清单中提炼出验收标准、设计导向、范围边界	蓝图各章节草稿
引用约束条件	将理解蓝图阶段收集的约束（预算、时间、技术、合规）原样写入	约束条件章节
标注来源	区分哪些内容是引用前序文档的，哪些是本阶段提炼的	引用标记
团队审阅	核心团队逐条确认，确保无遗漏和无歧义	审阅通过记录

最小可行模板

章节	内容	备注
需求-目的-目标	要解决什么问题、用什么手段、达到什么水准	来自上一步的框架结论
验收标准	每个目标对应的可衡量指标	每条目标至少一个量化指标
设计导向	依赖游玩体验构想确定	如探索类游戏：地图大小、时长、操作界面
约束条件	预算、时间、技术、合规限制	引用理解蓝图阶段的收集结果
范围边界	明确哪些在范围内，哪些不在	用"包含/不包含"列表

用有效性指标分析需求

蓝图的各要素确定后，接下来用指标验证这些要素是否可衡量。

验收标准定义项目怎样才算成功。有效性指标（MOE: Measure of Effectiveness）从需求方视角判断项目是否成功。

本流程（概念评审阶段）适用的指标类型

• 概念验证指标：原型完成度、垂直切片验证结果

• 团队共识指标：需求方签字确认、核心团队对目标的认知一致性（可用问卷量化）

• 方向验证指标：目标市场数据支撑度（竞品数据、用户调研样本量）

后续阶段的指标类型（供参考）

• 阶段三（全面制作）：功能完成率、内存/CPU占用、帧率

• 阶段四（测试与打磨）：严重Bug清零、性能达标率、玩家测试反馈评分

• 阶段五（上线与发行）：首发稳定性（崩溃率、服务器可用性）、首日/首周活跃用户数

• 阶段六（运营）：玩家留存率、付费转化率、渠道评分

确认需求具备双向溯源性

指标验证完成后，还需要确认每条需求都有源头、每条目标都有落地——这就是双向溯源性。

所有需求都应该有据可查。每个功能都应能追溯到高层需求或公司战略；反过来，每个战略目标也应有具体的功能来支撑。需求管理工具（如需求追踪矩阵、JIRA等）能辅助维护这条双向链路。

追溯矩阵示例

战略目标	对应需求	对应功能	验证方式
首月销量50万份	玩家对剧情深度有期待	分支剧情系统（至少3个结局）	内部试玩评分≥4.5
玩家满意度4.5/5	玩家感受到选择有意义	选择→后果反馈机制	玩家测试问卷
主线剧情30小时	缺乏好剧情RPG	关卡设计→剧情节点分布	内容清单核对

追溯不通过时的处理

当发现某条战略目标没有对应功能，或某条功能找不到上游需求时：

异常类型	处理方式
战略目标无对应功能	回到"确定需求、目的和目标"步骤，补充遗漏的功能规划
功能无上游需求	评估该功能是否必要——如果必要则补充需求，如果不必要则标记为"范围外"
追溯链条断裂（中间有缺失）	补充中间层级的文档，确保链条完整

获得需求方的认可

溯源性确认通过后，进入最后两步：让需求方正式签字认可，然后把所有产出整合为GDD。

需求方和项目团队对《项目蓝图》和《游玩体验构想》文档达成一致后，正式确认。

这一步不是简单的"签字走流程"——游玩体验构想和项目蓝图之间是迭代关系：构想会暴露蓝图中的矛盾（如"30小时剧情"与"6个月上线"冲突），蓝图也会反过来约束构想（如预算限制导致无法实现开放世界）。两份文档需要交替修改，直到团队和需求方都认可。

确认通常通过初步设计评审（Preliminary Design Review, PDR）进行。PDR 是项目从"想清楚"过渡到"动手做"的正式评审关卡——只有通过了PDR，项目才正式进入开发阶段。

PDR评审要点

评审项	通过标准
需求完整性	所有关键需求方已表达期望，无遗漏
目标可衡量	每条目标有对应的量化指标
约束已确认	预算、时间、技术、合规限制已书面确认
溯源完整	每条需求可追溯到战略目标，每条战略目标有对应功能
冲突已解决	所有已知矛盾已裁定，裁定人签字

PDR通过后的动作

• 正式冻结项目蓝图（后续变更须走变更流程）

• 项目正式进入下一阶段（预制作或全面制作）

• 将蓝图和构想作为GDD的输入文档

形成《游戏设计文档 GDD》

一旦达成一致，将项目蓝图、游玩体验构想及各方的期望和约束整合为《游戏设计文档 GDD》的初始版本。

初始版本的章节结构

章节	内容来源	说明
项目概述	项目蓝图	需求、目的、目标
体验愿景	游玩体验构想	核心循环、体验关键词、关键场景
设计导向	项目蓝图	从蓝图推导的设计原则
约束与范围	项目蓝图	预算、时间、技术、合规限制
系统设计（待补充）	后续开发阶段	初始版本只列出目录框架
关卡设计（待补充）	后续开发阶段	初始版本只列出目录框架
数值设计（待补充）	后续开发阶段	初始版本只列出目录框架

三个文档的层级关系

这三个文档构成递进关系：项目蓝图定义"做什么"，游玩体验构想描述"做成什么样"，GDD是前两者的整合，并在后续开发中不断扩展为"怎么做"的完整手册。

GDD变更机制 GDD一旦正式发布，任何修改必须走以下变更流程：

• 发起：任何人可以提交变更请求，说明修改内容、原因、影响范围

• 评审：制作人或指定评审人评估变更的影响（时间、成本、范围）

• 批准/驳回：评审人决定是否通过，通过后更新GDD版本号

• 通知：将变更内容同步给所有相关人员

输出

输出项	说明
经确认的项目蓝图	需求、目的、目标、约束条件（预算/时间/技术/合规）
游玩体验构想	核心循环、体验关键词、关键场景、分阶段体验目标
有效性指标集	概念评审阶段适用的成功指标（概念验证、团队共识、方向验证）
工作产品	决策记录、依据说明、经验教训总结

验收标准

初步设计评审通过以下评审意味着项目蓝图澄清完成：

1. 核心需求方期望文档获批

2. 游玩体验构想通过

3. 核心设计方案确定

4. 进入下一阶段准备就绪

文档信息写给谁：程序团队、策划、技术负责人、QA、美术、制作人 阅读收益：掌握设计方案的定义方法、验收标准和常见误区

设计方案定义流程将项目蓝图中的需求转化为可执行的设计方案。方案写成规范文档的形式，用于后续工作分解结构（Work Breakdown Structure, WBS）和插件/中间件需求定义。

核心概念：需求与设计方案 需求描述"要什么"（来自4.1项目蓝图澄清流程），设计方案描述"怎么做"（本流程的产出）。两者是上下游关系，不可混用。

策划团队从顶层目标逐层拆解到具体模块，每一层验证是否对齐上层需求。每条设计方案都要写清楚输入输出、逻辑关系、约束条件，以及玩家、运营与其他模块之间的交互。

重要提醒 程序团队不应被动等待需求才开始工作。在需求定义阶段就参与讨论，能避免后期返工。程序团队需持续确认开发方向正确。

流程描述

图 4.2-1 展示了设计方案定义流程的工作流，包括输入、输出和具体任务。

前置条件

前置项	说明
项目蓝图已通过评审	初步设计评审（Preliminary Design Review, PDR）已通过
游戏需求概览已达成共识	核心团队对需求、目的、目标已确认
核心团队已组建	关键角色已到位，职责已明确

流程的输入

输入项	说明	来源
游戏需求概览	当前阶段达成共识的描述，包括需求、目的、目标、假设、约束条件	4.1 项目蓝图澄清流程
项目蓝图	描述游戏在整个生命周期如何运行	4.1 项目蓝图澄清流程
开发策略	配套工具，以及如何满足产出所需的开发、测试、运营需要	制作人/技术负责人
评估指标	需求方认为必须达到的度量数值（即有效性指标 MOE），作为项目成功的验收依据	4.1 项目蓝图澄清流程

流程中的任务

定义阶段

任务1：定义边界、能力、性质

1. 评审需求和项目蓝图，确定设计边界

2. 列出必须遵守的条件（平台、预算、时间、人力、技术栈）

3. 确立评价维度，收敛备选方案

4. 根据《游戏需求概览》，定义功能范围

5. 评估外部工具和插件的可行性，记录选型建议和约束

6. 基于确认的功能范围，搭建模块间接口框架

边界定义示例 角色移动系统——边界内包含行走、奔跑、跳跃；边界外不含攀爬（属于动作系统）。

完成标准： 边界文档已输出，约束条件清单已建立，功能范围已获确认。

任务2：确定设计方案

策划团队了解边界、接口和功能期望后，与程序团队共同制定有效性指标（MOE）和技术标准，使设计方案可量化、可测试。性能规格用定量数值表示，说明每个功能需要达到的程度。操作步骤如下：

1. 梳理需求和项目蓝图中的需求条目

2. 将需求条目按模块分组，确定优先级

3. 为每个模块定义可量化的有效性指标（MOE）

4. 识别技术标准和约束条件

5. 与程序团队确认可行性

以上步骤的产出示例如下。 设计方案描述"怎么做"——"角色通过快捷键切换主副武器，切换过程包含收起当前武器的动画和取出目标武器的动画"，对应的有效性指标（MOE）是"80%以上测试玩家评价武器切换体验为流畅"，对应的性能参数（TPM）是"武器切换动画时长不超过0.5秒"。

完成标准： 有效性指标（MOE）已制定，技术标准已明确，每个功能有对应的定量性能要求。

任务3：用规范的语言定义设计方案

设计方案以「游戏需要……」的形式写成完整句子，每条只说一件事。记录设计方案的来源文档和提出方。识别对成本或进度影响较大的需求，标记为高优先级。

设计方案书写模板

字段	说明	示例
编号	按模块编号	REQ-战斗-001
描述	一条方案只说一件事	角色在战斗中可随时切换主副武器
来源	上游需求出处	4.1 项目蓝图 / 战斗设计文档
优先级	高/中/低	高
验证方式	怎么确认这条方案被实现	原型测试 + 自动化回归

规范文档的价值

需求方的收益	程序团队的收益
确保游戏符合目的	减少因理解偏差造成的返工
方便版本验收	提供清晰的开发指南
明确项目目标和底线	优化资源分配和进度控制

完成标准： 每条设计方案为单句、有来源、有优先级标记。

任务3.5：设计方案的原型验证

原型验证是任务3（规范语言定义）的延伸——只有写成规范文档的方案才能做原型验证，因此编号为3.5而非独立的任务4。

对于核心玩法相关的方案，在正式验收前做原型验证。原型验证用于判断设计方案在交互层面是否可行。

验证类型	适用场景	时间约束
玩法原型	用最低可视化成本验证核心循环的规则和反馈	单次迭代 1-2 周
Playable 原型	新操作方式、新交互模式	2-4 周
技术原型	性能敏感的功能（如大规模同屏）	1-3 周

需要原型验证的场景：

• 涉及核心玩法循环

• 涉及新操作方式或新交互模式

• 涉及性能敏感功能（如大规模同屏、复杂物理模拟）

可跳过的场景：成熟系统的常规迭代。

原型验证未通过时：

1. 记录失败原因和核心反馈

2. 评估是否需要调整设计方案或约束条件

3. 修改后重新验证，或提交评审会议讨论

熔断机制： 连续 3 次未通过，或累计验证时间超过项目阶段预算的 30%，强制上报制作人决策。制作人决策选项：调整设计方案、调整约束条件、降低优先级、砍需求（Descope）。评审会议最低参与：制作人 + 策划负责人 + 技术负责人。

完成标准： 原型通过内部试玩测试，核心反馈已记录。

确认阶段

明确了设计方案并完成原型验证后，进入确认阶段——验收设计方案、定义性能指标、建立游戏设计文档。

任务4：设计方案的验收

评审团队根据项目蓝图、核心目标与约束条件、游玩体验构想文档以及验收标准，验收设计方案。

步骤	检查内容	通过标准	未通过时的处理
书写是否正确	格式错误或文字错误	无格式错误	修改后重新提交
技术层面是否正确	设计方案与项目蓝图可互相追溯——每条方案能找到对应的需求来源，每个需求能找到对应的方案	程序团队内部评审通过	程序团队内部修正
需求方是否满意	关键相关方参与评审	无异议或异议已解决	组织评审会议，逐条讨论
是否可行	技术上能够实现	有实现方案	重新评估需求或调整约束条件
是否可以测试验证	写法统一，信息充分	有明确的测试方法	重写设计方案，增加可量化指标
是否存在重复或描述过度	每条设计方案唯一	无重复或冗余	合并或删除冗余条目

验收通过的设计方案应满足：完整易懂、标准一致、符合需求、架构支撑、变更记录可追溯。

评审参与最低要求 技术负责人 + 策划负责人 + QA 代表必须到场。其余相关方根据议题邀请。

有条件通过 核心条目通过、非核心条目限期修改时，可标注"有条件通过"。修改期限：

• 中小型项目：1-3 个工作日

• 大型项目：1 周

完成标准： 所有条目通过或有条件通过，无未解决的阻塞性异议。

任务5：定义性能指标

任务5在任务2定义的有效性指标（MOE）基础上，进一步将其分解为可测量的性能参数。

有效性指标（Measure of Effectiveness, MOE）从需求方视角描述项目成功的标准，如"玩家30日留存率达到40%"。性能指标是 MOE 的技术实现层面分解，通常多个性能指标组成一个有效性指标。

技术团队对比参数的实际值与目标值，监控性能指标。性能指标分为两层——上层面向管理层汇报，下层面向技术团队日常监控：

层级	名称	说明
上层	关键性能参数（TPM, Technical Performance Measures）	从项目蓝图推导的技术性能参数，如帧率、崩溃率。TPM 是 MOE 的技术分解——一个 MOE"玩家体验流畅"可分解为"帧率≥60fps""加载时间≤2s"等多个 TPM
下层	具体性能参数	可直接测量的技术参数，如单帧 CPU 耗时、内存峰值

完成标准： 每个有效性指标（MOE）至少分解为 2-3 个可测量的性能参数（TPM），目标值和底线值已定义，MOE 与 TPM 的对应关系已建立。

任务6：建立 GDD 初始版本与更新机制

制作人确认设计方案通过验收并获得关键需求方认可后，将方案整合为《游戏设计文档 GDD》。GDD 是项目蓝图在设计细节层面的展开。项目蓝图描述"做什么和为什么做"，GDD 描述"怎么做和做到什么程度"。GDD 通常包含：核心玩法设计、系统设计（战斗、成长、社交等）、关卡设计、数值设计、UI/UX 设计、技术规格。

GDD 是持续演进的活文档（通常以 Wiki 或需求管理工具形式存在），纳入版本管理。文档管理员负责更新，修改需经制作人审批，确保团队随时访问最新版本。后续如需修改，走正式审批流程。

完成标准： GDD 初始版本已创建，核心设计方案已录入，版本管理已生效。

任务7：获取阶段产出物

项目团队在流程中产出以下内容：决策记录、决策依据、前提假设、经验教训总结。

流程的输出

输出项	说明	下游流向
已核准的设计方案	一套被认可的设计方案集，描述怎么做	WBS 工作分解
评估指标	定量度量指标（即有效性指标 MOE），达到预期值即视为对应需求已满足	开发阶段监控
性能指标	性能度量指标集，用于监控实际表现与预期的差距	技术管理流程
工作产品	决策记录、依据说明、经验教训总结	项目归档

设计方案定义流程指南

上面的流程描述了设计方案从定义到验收的完整步骤。接下来是执行中需要关注的要点，按以下主题展开：

1. 相关方识别——谁来参与、各自关注什么

2. 设计方案拆解与分类——功能设计、性能指标、接口管理

3. 跨领域需求——环境管理、反外挂、交互设计、数据埋点

4. 设计方案的层级分配与变更管理——拆分、追溯、变更流程

5. 设计方案的记录与 Wiki 管理——元数据、验证方法、工具

6. 技术标准——标准选取与应用

7. 常见失败模式——镀金、分析瘫痪、设计债、沉默的假设

相关方识别

定义设计方案时，必须识别所有相关方：

相关方	关注点	常见遗漏
需求方	功能是否符合预期	—
程序团队	实现成本、技术风险	—
QA	测试成本、验收标准	经常遗漏
美术	工作流变化、资源规格	经常遗漏
运营	配置复杂度、埋点需求	经常遗漏
客服	玩家常见问题	经常遗漏
运维	部署复杂度、监控需求	经常遗漏
音频	音效触发时机、音乐情绪节点、音频资源规格	经常遗漏
外包团队	接口精度、验收标准	设计意图传递、接口精度、验收标准
发行方	上线时间、商业目标	—

相关方冲突处理: 不同相关方的诉求可能冲突：

• 策划想做新玩法，程序想还技术债 → 排优先级，用数据说话

• 制作人想赶档期，团队想保证质量 → 定 MVP，分期迭代

• 发行方要求加商业化功能，策划担心破坏体验 → A/B 测试，数据决策

设计方案拆解与分类

设计方案按 WBS 拆分到下游环节，用于设计具体模块，分为三类：功能设计（做什么）、性能指标（做到什么程度）和接口设计（各模块如何交互）。

图 4.2-2 需求的流动、类型和所有权

1. 功能设计

策划团队指定游戏在全生命周期中所有应用下的功能设计方案。设计方案按相似性分组，分配到子功能、目标、人员和流程中。

每个功能包含输入、输出、异常处理、边界条件和接口需求，策划团队自顶向下描述。功能按逻辑顺序排列，确保任何运行任务都能在系统中溯源。

思考问题：

• 系统需要执行什么功能？

• 在什么环境和条件下执行？

• 由谁操作？

• 执行多久？

2. 性能指标

性能指标是对游戏功能「做到什么程度」的量化定义。

• 功能的执行频次是多少？

• 需要达到多高的精度？

• 会产生哪些输出？

• 在多大的强度下运行？

• 需要持续多久？

• 允许有多大的误差？

性能指标定义示例 功能陈述描述"做什么"，性能指标描述"做到什么程度"。

示例： 镜头系统需支持第三人称视角的角色跟随。

需求	目标值	底线值
镜头转动速度	120 度/秒	60 度/秒
输入响应延迟	≤16ms（1帧@60fps）	≤33ms（1帧@30fps）
镜头跟随距离	3-5m	2-8m

3. 接口规范管理

技术团队为游戏系统定义所有接口规范方案。外部接口是游戏产品与外界沟通的边界。

接口类型	说明	最小必要字段
操作指令接口	玩家的操作控制	指令名、参数、触发条件
客户端-服务端接口	服务器与客户端通信	协议、序列化格式、错误码、版本兼容策略、降级策略
人机接口/UI	界面显示	交互流程、响应时间、适配分辨率
数据接口	存档和配置	数据格式、读写频率、容量上限
第三方服务接口	SDK集成	接入方式、回调机制、错误处理、降级策略

架构师在系统模块确定后画出流程图，展示主要组件的互联关系。架构师还需考虑游戏整个生命周期的所有接口，比如与测试设备、发布系统、运营保障系统以及玩家之间的接口。

跨领域需求

前面讲的是按功能拆解的设计方案。但有些需求不是某个模块的专属问题，而是横跨所有模块的——比如性能、安全、交互体验。这类需求不能简单拆分到某个子系统，需要单独管理。包括设备性能、反外挂、交互设计和稳定性。

1. 设备性能管理

每个游戏项目都有运行环境要求。程序团队分析和量化游戏在不同硬件、不同网络下的表现，建立性能余量。

需求应涵盖	参考指标
CPU 占用	建议不超过单核 70%
内存负载	预留 10% 安全余量
发热控制	连续运行 30 分钟不触发降频
网络带宽	弱网环境（3G/丢包 20%）可玩

以上数值基于移动端（iOS/Android）主线程负载的经验值。主机/PC项目需根据目标硬件和引擎特性重新评估。

2. 反外挂需求

游戏安全性涵盖玩家安全、环境安全和资产安全。按实际防护维度分类：

防护维度	具体措施
客户端防护	内存保护、反调试、反注入
通信安全	协议加密、重放攻击防护
服务端校验	关键逻辑服务端判定、异常行为检测
运营监控	异常数据分析、封号策略

3. 交互设计/UX

玩家是游戏设计的关键部分。设计方案必须考虑玩家的能力和局限性。

设计要点	说明
操作反馈	按键响应延迟不超过 1 帧
信息层级	UI 元素按重要性分层，核心信息优先展示
新手引导	前 5 分钟引导玩家完成核心循环
可访问性	支持色盲模式、字幕、按键自定义
多平台适配	手柄、键鼠、触屏操作均需覆盖

4. 数据埋点与分析

运营团队需要的数据埋点横跨所有系统。设计方案阶段定义埋点需求，避免后期补埋点的高昂成本。

设计要点	说明
关键事件埋点	用户注册、首次付费、关卡完成等核心转化节点
行为追踪	玩家路径、功能使用频率、流失节点
性能监控	帧率、加载时间、崩溃堆栈自动上报
数据口径	统一事件命名规范和数据格式，确保各模块上报一致

设计方案的层级分配与变更管理

设计方案按层级从顶层目标逐层向下拆解，每层对照项目蓝图确认。

图 4.2-4 需求的层级分解流程

设计方案变更管理

在阶段二（预制作）和阶段三（全面制作）前期，设计方案可能变化。变更管理流程：

步骤	内容	责任人
提议	填写变更提议，说明原因和影响范围	任何相关方
评估	评估对上下游设计方案、成本和进度的影响	技术负责人
审批	根据影响范围，由对应层级审批	制作人/技术负责人
执行	修改设计方案，更新 Wiki	文档管理员
通知	通知所有受影响的相关方	项目经理

变更执行后，受影响的相关方如有异议，可启动变更复审。变更如涉及已验收的设计方案，须回归任务4的验收流程。涉及性能指标的变更须同步更新任务5的指标定义和任务6的GDD。

设计方案的记录与 Wiki 管理

文档管理员整理设计方案时，写清楚方案本身。同时记录与之相关的「元数据」——方案的背景资料，帮助理解和连接各项方案。

制定每条设计方案时，文档管理员同时考虑如何测试验证。如果一条设计方案没法测试验证，要么重写，要么不能算正式方案。比如"尽量减少卡顿"没法测试，写成"帧率稳定在 60 帧以上"就可以测试验证。

方法	说明
测试	通过实际运行来检测功能是否正常
美术跑包	检查画面的视觉表现是否符合要求
定量分析	通过数据统计来判断指标是否达标
Demo 演示	通过原型展示来确认逻辑是否正确

游戏需求属性	在游戏设计与开发中的作用描述
需求唯一编号	为游戏版本、功能模块或具体任务提供唯一标识符，用于在 TAPD、Jira 等项目管理工具中快速定位。
设计意图与背景	陈述为什么要做这个功能,在需求开发初期就明确其商业或体验价值。
关联与追踪	建立需求间的父子级嵌套或引用关联。确保上层需求被完整落实。
负责人（Owner）	指派主策 / 系统策划 / 程序负责人，主要负责该需求的方案撰写、开发跟进及后续的变更审批。
验收与测试方案	确定该功能开发完成后如何判断合格。例如：“单元测试”（程序自测）、“QA 功能验收”、“策划体验测试”、“A/B 灰度测试”等，需在设计开发初期同步确定。
验收负责人	被指派负责该功能最终验收的人，通常是主策、主程序或主测（QA Lead）。他们拥有最终“签字/通过”该需求的权限。
验收/测试层级	定义该需求应该在哪一层级进行验证。例如：单一功能点（单体逻辑测试）、子系统集成（如技能和装备联调）、全系统/完整游戏体验（跨模块的综合体验测试或性能压测）。

图 4.2-3 需求类型的组织架构

表 4.2-2 需求元数据类型

客观依据记录设计方案时，应当包含以下参考信息：

元数据	说明
方案的理由	解释为什么要加这个功能
前提假设	比如假设某个插件/中间件已经研发完成
关联关系	记录该方案与玩家实际游戏体验之间的联系
设计约束	记录因为之前的决策而必须遵守的限制条件

项目团队使用 Wiki 或需求管理工具记录这些信息。工具展示设计方案之间的双向溯源关系，随时存储最新状态，方便整个团队查看。

技术标准

1. 应用标准的重要性

标准是建立公共设计方案的基础，防止各功能模块产生不兼容，确保游戏达到行业标准的质量基线。有效应用标准能降低开发和运营成本，因为标准基于过去的经验教训总结，是最佳实践。

反面案例：两个战斗模块各自定义了不同的伤害计算公式，合并时发现无法互通，导致返工。统一标准能避免这类问题。

2. 标准的选取

优先级	标准类型	游戏行业实例
1	法律规定的强制标准	版署审批要求、个人信息保护法、平台审核指南
2	游戏行业通用的公共标准	平台技术标准（TRC/XRC、App Store Review Guidelines）、引擎官方最佳实践
3	公司或工作室内部的通用标准	编码规范、资源命名规范、Git工作流规范
4	针对特定项目的技术标准	项目特有的技术约束

常见失败模式

失败模式	表现	识别信号	应对措施
镀金	策划往设计方案里加需求方没要求的功能	设计方案数量远超需求数量	每条方案必须有上游需求来源，无来源的标注为"待确认"
分析瘫痪	团队在方案细节上反复讨论，不做决定	同一议题超过3次会议未定论	设置决策截止日期，到期未定由制作人裁决
设计债	为赶进度在设计方案里留模糊地带	方案中出现"待定""后续补充"等标记	模糊区域不超过总方案的10%，超限须补充完整后再推进
沉默的假设	方案基于未显式记录的假设	出现问题时才"原来我们一直假设……"	所有前提假设写入方案元数据，定期审查

不同规模项目的执行差异

任务裁剪矩阵

任务	独立游戏（<10人）	中型项目（10-50人）	大型项目（>50人）
定义边界	必做	必做	必做
确定设计方案	必做	必做	必做
规范语言定义	简化（任务清单即可）	必做	必做
原型验证	核心玩法必做	核心玩法必做	所有新系统必做
验收	制作人确认即可	关键角色评审	正式评审流程
性能指标	关键指标即可	完整指标体系	完整体系 + 自动化监控
确立 GDD	一页纸文档	Wiki 文档	需求管理系统
变更管理	口头沟通 + 简要记录（IM消息或任务卡片备注）	Wiki 记录变更	正式变更控制流程