[T.5] 团队项目：功能规格说明书

项目	内容
这个作业属于哪个课程	北航2026年春季软件工程
这个作业的要求在哪里	[T.5] 团队项目：功能规格说明书
我在这个课程的目标是	提升团队协作能力，项目管理能力；学会编写一个完整软件项目的技能，为职业发展打下坚实基础；培养批判性思维和解决复杂工程问题的能力。
这个作业在哪个具体方面帮助我实现目标	说明本团队项目的功能规格

1. 前言

1.1 写作目标

明确本游戏的功能范围、设计标准、验收要求，为开发、测试、验收提供统一依据；清晰界定文档叙述范畴，避免功能歧义，确保团队成员对产品认知一致；同时满足课程作业要求，呈现产品设计思路与实现规划。

本说明书需说明的核心问题：游戏核心玩法、各系统功能的逻辑、用户与应用场景的匹配度、功能边界与风险应对、分阶段实现计划与验收标准；叙述范畴仅限于本游戏的功能设计、用户交互、系统逻辑，不涉及底层代码实现、硬件配置要求、第三方工具调用细节。

1.2 文档适用范围

适用对象：本课程小组所有开发、测试、设计成员，课程指导老师

适用阶段：Alpha阶段、Beta阶段的开发、测试、验收全流程

不适用范围：非游戏相关的功能设计、代码开发细节、硬件适配的具体技术方案。

2. 概念与术语定义

本章明确本说明书中所有专用术语、缩写的含义，对易混淆的术语进行特别说明，确保无理解偏差。

- 卡牌rougelike：核心玩法结合卡牌收集/组合与rougelike随机生成机制，每局游戏流程随机（关卡、怪物、卡牌、道具），单次失败后需重新开始，注重策略性与重复性体验的游戏类型。

- 探图：本游戏核心玩法之一，玩家操控角色从出生点出发，逐步挑战关卡，击败遇到的僵尸、精英僵尸，获取道具卡、战斗卡等奖励，最终抵达屋顶战胜最终 boss 完成通关。

- 戴夫：玩家的游戏操控对象，有固定的初始卡牌、初始血量。

- 卡牌：游戏核心交互载体，分为战斗卡和道具卡；卡牌有稀有度区分（普通、稀有、史诗），稀有度越高，获取难度越大（不一定能力更强）。

- 战斗卡：存在于玩家卡牌库中的卡牌。

- 道具卡：玩家在探图过程中获取的卡牌，不进入牌库。放在道具卡槽时可永久提升角色属性或卡牌效果，可选择在战斗中使用，造成一定效果，使用后消失。

例如：装备在道具卡槽时，获得 2 力量，投出时造成 10 点伤害。

- 血量/护盾：角色生存核心，血量为角色基础生命值，血量为0则游戏失败；护盾为临时防御值，可抵御伤害，回合结束后不保留（部分卡牌可让护盾保留）。

- 阳光：战斗中的唯一资源。每回合开始重置为 3 点（基础值），溢出不保留。

- Alpha阶段：产品基础功能开发阶段，实现核心玩法，满足基本可玩需求。

- Beta阶段：产品增量功能开发阶段，完善玩法（新增卡牌、僵尸、难度模式），修复bug，优化体验，达到课程要求的发布标准。

- 易混淆术语区分：① 战斗卡vs道具卡：战斗卡是存在于玩家牌库中的牌，可以在战斗中使用，道具卡可以为玩家在探图过程中和对战过程中提供增益，也可以在战斗中打出，打出后在整轮探图中消失。类比杀戮尖塔中的概念：战斗卡=卡牌，道具卡=遗物+药水。

3. 产品描述

3.1 项目简述

本项目为卡牌rougelike游戏，核心玩法围绕“探图+卡牌组合”展开，玩家通过逐个挑战关卡、收集卡牌、组合最优卡组，击败最终 boss 完成通关；游戏融合随机生成与策略组合元素，每局游戏体验不同，兼顾趣味性与挑战性。本项目背景设定为“戴夫带着植物逐步达到僵尸老家，大战僵王博士”，既保留卡牌对战的核心乐趣，又通过融合 PvZ IP 设计，打造差异化体验。项目意义在于掌握卡牌rougelike游戏的功能设计与开发逻辑；为卡牌游戏爱好者提供一款轻量化、体验不同的游戏，为 PvZ 二创游戏爱好者提供一款不同游戏类型的新尝试。

3.2 用户和应用场景

3.2.1 用户画像

本游戏用户主要分为3类，具体如下：

1. 核心用户：rougelike游戏爱好者

- 身份特征：年龄15-30岁，以大学生、年轻上班族为主，男女比例约7:3，有过杀戮尖塔、月圆之夜等同类游戏体验，熟悉rougelike随机机制与卡牌组合逻辑。

- 潜在总量：结合校园与团队成员朋友圈中同类游戏爱好者数量，潜在核心用户约30人，占总潜在用户量的30%。

- 使用习惯：多在整块时间集中游玩，一次游玩可能包括至少两次重开的过程；偏好挑战高难度关卡，注重卡组组合的策略性，会反复尝试不同卡组搭配。

- 用户期望：希望游戏有足够的随机性与策略性，卡牌组合丰富，无明显平衡漏洞，难度梯度合理，能获得挑战成功的成就感。

- 付出代价：物质上，如果有可能，接受单次买断或小额内购；非物质上，愿意投入时间熟悉角色特性、卡牌效果，反复尝试不同卡组，接受失败后重新开始的机制。

2. 次要用户：PvZ 二创游戏爱好者

- 身份特征：年龄15-30岁，喜欢 PvZ 及其二创游戏，熟悉PvZ IP，但对rougelike机制了解较少，希望在游戏中看到对 PvZ IP 的创意性使用，希望一些机制符合原 IP。

- 潜在总量：约30人，占总潜在用户量的30%。

- 使用习惯：使用时间较为零碎；偏好体验更多游戏内容，对难度要求和通过获得的成就感不高。

- 用户期望：希望卡牌特效丰富、形象美观，能在其中看到有创意的 PvZ IP 二创；新手引导清晰，能快速上手，获得收集的乐趣。

- 付出代价：愿意投入少量时间学习基础玩法，但不喜欢过于复杂的策略搭配，排斥反复失败的挫败感。

3. 边缘用户：吃瓜/休闲玩家

- 身份特征：年龄16-22岁，无明确游戏偏好，喜欢轻量化、易上手的休闲游戏，用于消磨时间，对卡牌、rougelike游戏了解较少，因为看到熟人转发想要尝试游玩。

- 潜在总量：约40人，占总潜在用户量的40%。

- 使用习惯：使用时间随机，每次使用时长5-15分钟，游玩频率不会太高；仅体验基础玩法，不追求通关或收集，遇到高难度关卡会放弃。

- 用户期望：希望游戏操作简单、节奏明快，新手门槛低，无需投入过多精力，能快速获得即时反馈。

- 付出代价：不愿意投入时间学习复杂玩法，若操作繁琐或难度过高，会直接放弃使用。

3.2.2 典型应用场景

结合游戏核心玩法与用户画像，分为3类典型应用场景，每类场景包含用户类型、系统服务方式、用户关系、用户收益，并辅以场景叙述，增强直观性。

1. 场景一：核心用户挑战高难度游戏

- 涉及用户：核心用户（rougelike游戏爱好者）。

- 系统服务方式：玩家第一次通关后，可选择“困难”模式。

- 用户收益：通过挑战高难度关卡，获得稀有卡牌、解锁高难度成就，获得策略成功的成就感；积累游戏经验，优化卡组组合，提升自身游戏技巧。

- 场景叙述：小李是一名rougelike游戏爱好者，熟悉杀戮尖塔等类似游戏玩法，打开本游戏后选择“困难”模式，操控“戴夫”开始探图。过程中他不断调整卡组，删除冗余卡牌，保留核心输出与防御卡牌，一路过关斩将，最终战胜 boss 僵王博士，截图分享给同学，随后开始新一轮游戏，尝试不同的卡组组合。

2. 场景二：PvZ 二创游戏爱好者想看看游戏是如何利用 PvZ IP 的

- 涉及用户：PvZ 二创游戏爱好者。

- 系统服务方式：普通难度模式。

- 用户收益：收集各类卡牌，点亮图鉴，获得收集的满足感；同时看到 PvZ IP 被融入游戏中，感到新奇和有趣。

- 场景叙述：小张喜欢 PvZ 二创游戏，第一次打开本游戏，通过新手引导了解基础玩法后，选择普通难度模式。他的核心目标是尽量多地探索游戏内容。他开启一轮游戏，尝试进行游玩，虽然最终未能通关，但他收集了30张新卡牌，很有成就感，计划下次继续收集剩余的卡牌。

3. 场景三：边缘用户碎片化休闲体验

- 涉及用户：边缘用户。

- 系统服务方式：普通难度模式。

- 用户收益：利用碎片化时间完成一局游戏，获得即时娱乐体验，消磨时间，缓解压力；无需投入过多精力，即可获得游戏乐趣。

- 场景叙述：小王是一名大学生，看到朋友圈里有人转发本游戏，于是下载了游戏，在提交完冯如杯材料后感到如释重负，想开始一局游戏体验体验。在游戏中他并不想多动脑，简单地体验了游戏流程，失败后也没有很大的挫败感，玩完游戏该睡觉了，他可能不会再次打开游戏，直到他得知游戏有了新内容或较大改动想要体验。

4. 产品功能

4.1 功能描述（分系统）

本游戏核心功能围绕“探图+卡牌+战斗”展开，本部分明确各功能的实现效果、对应应用场景、依赖关系、潜在问题及应对方案，区分基础功能与增量功能，规划分阶段实现计划。

4.1.1 角色系统

• 功能实现：记录玩家“戴夫”的相关属性，如最大生命值，当前生命值，牌库内容等。

• 对应场景：所有应用场景。

• 依赖关系：依赖卡牌系统（角色系统需记录玩家拥有的卡牌）、探图系统（角色状态需在探图过程中实时更新）、对战系统（角色生命值改变）。

• 潜在问题及应对：① 问题：角色数值失衡；应对：Alpha阶段测试后调整角色数值，Beta阶段根据用户反馈优化各项数值，保证游戏可玩性。

4.1.2 卡牌系统

• 功能实现：

  • ① 基础功能（Alpha阶段）：包含25张基础卡牌（20张战斗卡、5张道具卡）；支持卡牌获取（击败怪物、开宝箱、商店购买）、卡牌在战斗中使用、卡牌升级、卡牌删除（商店层可删除卡牌）；支持手牌显示、卡牌效果实时反馈、抽牌洗牌等。

  • ② 增量功能（Beta阶段）：新增30张卡牌（原版植物不够则使用其他二创游戏中的相关植物），新增卡牌特效；支持卡牌图鉴（记录已收集、未收集卡牌，显示卡牌详情）。

• 对应场景：所有应用场景，用户可组合最优卡组、升级卡牌，使用卡牌完成战斗。

• 依赖关系：依赖战斗系统（卡牌效果需在战斗中生效）、探图系统（卡牌获取场景与探图绑定）。

• 潜在问题及应对：① 问题：卡牌组合过于单一，策略性不足；应对：Beta阶段新增多样化卡牌，设计卡牌羁绊，提升策略性。② 问题：卡牌强度失衡；应对：可能的话，收集玩家游玩过程中的相关数据（如选择某张卡牌的通关率，某张卡牌在所有通关时的出现频率），进行平衡性调整。

4.1.3 探图系统

• 功能实现：

  • ① 基础功能（Alpha阶段）：生成白天和黑夜草坪部分的地图，随机刷新不同的部分。包含战斗部分（怪物）、事件部分（恢复血量/删除卡牌/出现墓碑等）、商店部分（购买卡牌/遗物）；支持角色移动（逐地图挑战，不可回溯）；支持通关判定（击败黑夜关的首领即为通关）。对于每一个地图，我们都能提供一个特殊关卡。

  • ② 增量功能（Beta阶段）：生成6个地图，支持难度模式切换（普通、困难、地狱）；支持关卡进度保存（退出游戏后保留当前进度）；支持成就系统（如“通关困难模式”“收集所有遗物”）。

• 对应场景：所有应用场景，核心用户挑战高难度，次要用户体验普通难度、收集奖励，边缘用户体验快速模式。

• 依赖关系：依赖角色系统（角色状态决定进度）、卡牌系统（卡牌是击败怪物的核心）、战斗系统（怪物需通过战斗击败）。

• 潜在问题及应对：① 问题：进度保存失效，用户退出后需重新开始；应对：优化存档机制，本地保存进度，定期备份，避免进度丢失。

4.1.4 战斗系统

• 功能实现：

  • ① 基础功能（Alpha阶段）：采用回合制战斗，玩家回合：抽卡、使用卡牌、消耗阳光、效果结算→ 怪物回合：攻击玩家、进行增益、减易、施加特殊效果；怪物有固定的行动逻辑；支持战斗结算（击败怪物获得奖励，玩家血量为0则游戏失败）；有简单的战斗动画。

  • ② 增量功能（Beta阶段）：新增怪物debuff、玩家buff；完善战斗动画；新增怪物。

• 对应场景：所有应用场景，所有用户都需通过战斗推进进度。

• 依赖关系：依赖卡牌系统（卡牌是战斗的核心）。

• 潜在问题及应对：① 问题：战斗节奏过慢，边缘用户失去耐心；应对：优化战斗速度，增加“快速战斗”选项，缩短动画时长。② 问题：怪物简单，核心用户缺乏挑战性；应对：Beta阶段优化精英、首领逻辑，增加攻击策略，提升挑战性。

4.1.5 辅助系统（设置、存档、图鉴）

• 功能实现：① 基础功能（Alpha阶段）：支持基础设置（音量调节、画面分辨率）；支持本地存档（保存当前游戏进度）；支持简单的卡牌查看功能。② 增量功能（Beta阶段）：支持图鉴系统（卡牌图鉴，显示收集进度）；支持成就系统（解锁条件、成就奖励）；支持数据统计（通关次数、胜率、常用卡组）。

• 对应场景：所有应用场景，辅助用户提升游戏体验，满足收集、设置、反馈需求。

• 依赖关系：依赖所有核心系统（图鉴需调用卡牌数据；存档需保存探图、卡牌、成就数据）。

• 潜在问题及应对：① 问题：存档冲突，多个用户使用同一设备导致进度覆盖；应对：支持多账号存档，区分不同用户的进度，避免覆盖。

5. 产品目标（课程作业阶段）

结合课程作业要求，明确本项目在Alpha阶段、Beta阶段的产品目标，确保可量化、可验证。

5.1 Alpha阶段目标（基础功能完成）

• 功能目标：详见 4. 产品功能

• 用户目标：积累至少10名真实测试用户（以开发团队成员的熟人为主），确保数据可信；日活跃用户达到10人以上）。

• 数据目标：系统内部积累基础数据，包括：卡牌使用记录、战斗记录、通关记录。

• 发布目标：完成PC端可执行文件打包，上传至Github仓库，确保可正常下载、安装、运行；无需上架应用商店，仅用于课程内部测试。

5.2 Beta阶段目标（增量功能完成）

• 功能目标：详见 4. 产品功能

• 用户目标：积累至少20名真实测试用户，其中核心用户占40%、次要用户占3%、边缘用户占30%；日活跃用户达到30人以上；用户留存率达到40%以上（统计首次登录后7日内再次登录的用户比例）。

• 数据目标：在 alpha 阶段的基础上，收集用户反馈至少15条。

6. 界面原型设计

本章提供游戏各核心界面的原型设计说明，若未使用原型设计工具，将提供详细的草图描述与布局说明，确保界面交互清晰、符合游戏玩法逻辑。

6.1 原型设计工具

采用Figma进行原型设计（可提供Figma链接，供团队成员查看、修改）；若未使用Figma，将提供手绘草图（拍照插入文档），并配合文字描述，明确各界面元素的位置、功能。

6.2 核心界面描述

1. 登录界面：简洁风格，顶部显示游戏名称，中间为“开始游戏”“继续游戏”“退出游戏”三个按钮，底部显示游戏版本号、团队信息；点击“开始游戏”进入角色选择界面，点击“设置”进入音量、分辨率调节界面，点击“退出游戏”关闭应用。

2. 难度选择界面：顶部显示“选择难度”标题，中间为三个难度按钮（普通、困难、地狱，Beta阶段），每个按钮显示难度说明（如普通：怪物血量正常，奖励一般）；底部为“开始游戏”“返回角色选择”按钮；选择难度后，点击“开始游戏”进入游戏界面。

3. 地图界面：左侧显示当前地图（如“白天草坪”）、角色状态（血量、金币），中间为地图（显示当前位置、可前往的下一层），右侧显示当前拥有的卡牌、遗物预览；通过移动触发，进入战斗/事件/商店界面。

4. 战斗界面：顶部显示怪物信息（血量、名称、状态），中间左侧为角色状态（血量、护盾），中间右侧为手牌区域（显示当前可使用的卡牌，标注阳光消耗），底部为操作按钮（“结束回合”“快速战斗”“暂停”）；点击卡牌即可使用（消耗对应阳光），怪物回合自动进行攻击，战斗结束后显示奖励界面。

5. 奖励界面：顶部显示“战斗胜利”“宝箱奖励”等标题，中间为奖励选项（如3张卡牌选择1张、1件遗物、少量游戏货币），底部为“确认选择”按钮；选择奖励后，返回地图界面，继续游戏。

6. 图鉴界面（Beta阶段）：分为“卡牌图鉴”“遗物图鉴”两个标签，每个标签显示已收集、未收集的卡牌/遗物；已收集的显示完整效果、获取途径，未收集的显示灰色占位图及“未收集”提示；支持搜索功能，可快速查找特定卡牌/遗物。

7. 功能验收验证标准

明确各功能的验收标准，区分基础功能（Alpha阶段）与增量功能（Beta阶段），确保开发完成后可精准验证，符合产品设计要求。

7.1 Alpha阶段验收标准（基础功能）

功能模块	验收标准
卡牌系统	1. 25张基础卡牌可正常获取、显示、使用；2. 卡牌消耗阳光正确，效果（伤害、护盾）实时生效；3. 休息层可正常删除卡牌。
探图系统	1. 地图正确生成，地点分布合理；2. 角色可移动，会受到障碍物阻挡；3. 所有 boss 后通关。
战斗系统	1. 回合制战斗正常运行，玩家回合与敌人回合切换流畅；2. 怪物行为正常；3. 战斗结算正确（击败怪物获奖励，血量为0游戏失败）。
辅助系统	1. 基础设置可正常调节；2. 本地存档可正常保存、读取，进度不丢失。

7.2 Beta阶段验收标准（增量功能）

功能模块	验收标准
卡牌系统	1. 新增卡牌可正常获取、使用，特效显示正确；2. 卡牌可正常升级，升级后效果提升；3. 卡牌图鉴可实时更新，收集状态准确，支持搜索。
探图系统	1. 全部地图正常生成；2. 难度模式可正常切换，难度有差异；3. 关卡进度可正常保存、读取；4. 成就系统可正常解锁。
战斗系统	1. 新增buff可正常生效，显示正确；2. 战斗动画流畅，无卡顿。
辅助系统	1. 数据统计功能可正常显示（通关次数、胜率等）；2. 反馈功能可正常提交，提交的内容可查看；3. 多存档可正常使用，无进度覆盖问题。

8. 产品设计的问题、副作用及风险应对

8.1 产品设计的问题及副作用

结合游戏功能设计，分析可能存在的问题、副作用，并提出具体的应对、解决方式，确保产品体验良好。

- 问题1：卡牌平衡失衡

- 副作用：部分卡牌过于强势，导致游戏难度过低，核心用户失去挑战性；部分卡牌过于弱势，导致用户不愿使用，浪费设计资源，同时使游戏变得单调。

- 应对方式：① 开发阶段（Alpha、Beta）收集用户游玩信息，记录卡牌的抓取频率、使用频率、胜率，收集反馈；② 建立数值平衡表，明确各卡牌的效果数值、属性，根据测试结果调整数值。

- 问题2：游戏随机性过高，用户挫败感强

- 副作用：地图随机生成不合理（如连续出现较难关），卡牌获取过难，导致用户反复失败，尤其是次要用户、边缘用户，容易放弃使用；核心用户也可能因随机性过高，无法发挥策略优势，产生挫败感。

- 应对方式：① 优化随机算法，控制精英怪的出现频率；② 普通难度提升卡牌的获取概率，降低僵尸的强度，降低用户挫败感；高难度保持随机性，满足核心用户的挑战需求；③在非地狱模式下， 新增“保底机制”，连续3层未获取稀有卡牌，下一层必出稀有奖励。

- 问题3：操作繁琐，新手门槛高

- 副作用：边缘用户对卡牌rougelike游戏不熟悉，难以快速上手，操作流程繁琐，导致用户流失；核心用户也可能因操作繁琐，影响游戏体验。

- 应对方式：① 优化新手教程，第一个地图用简单的战斗和事件引导玩家快速上手，确保新手用户能快速掌握，同时没有新手教程这种让人厌倦的内容；② 卡牌效果采用简洁明了的文字描述，搭配图标，避免专业术语过多，便于所有用户理解。

8.2 产品可能面临的风险及解决方案

结合课程项目的开发环境、用户群体、技术限制，分析产品发布后可能面临的风险，提出具体的解决方案，确保项目顺利完成。

潜在风险	风险描述	解决方案
开发进度风险	Alpha、Beta阶段功能开发进度滞后，无法按时完成验收，影响课程作业提交；核心功能开发出现技术难题，无法正常实现。	1. 制定详细的开发计划，明确各功能的开发周期、责任人，定期召开小组会议，同步开发进度；2. 优先开发核心功能，增量功能可根据进度适当简化；3. 遇到技术难题，及时向课程指导老师、同学请教，或查阅相关资料，必要时调整功能设计，降低开发难度。
用户测试风险	测试用户数量不足，无法全面发现功能bug、平衡问题；测试用户反馈不及时、不全面，影响产品优化；用户留存率低，无法达成产品目标。	1. 扩大测试用户范围，可邀请身边的卡牌/rougelike游戏爱好者参与测试；2. 制定测试反馈表，明确测试重点（bug、平衡、体验），引导用户提交详细反馈；3. 对参与测试的用户给予小奖励，提高用户参与度、反馈积极性；4. 根据用户反馈，快速优化产品，提升用户体验，提高留存率。