[T.13] 团队项目：Alpha 阶段项目展示
| 项目 | 内容 |
|---|---|
| 课程 | 2026 年春季软件工程 |
| 作业 | [T.13] 团队项目：Alpha 阶段项目展示 |
| 团队 | MAGICCELL |
| 项目 | Z-Spire / 植胜僵场 |
| 项目定位 | PvZ 题材的单机 Roguelike 卡牌策略游戏 |
| Alpha 展示视频 | Bilibili：戴夫——这把高端局 |
一句话介绍：玩家扮演戴夫，在可自由移动的地图中探索，用植物卡牌与僵尸进行回合制战斗，并通过奖励、事件、休息点和商店不断构筑自己的牌组。
第一部分：项目与团队亮点
1. 团队成员、分工与管理方式
1.1 成员分工
| 成员 | Alpha 阶段分工 |
|---|---|
| 丁宇城 | PM、项目管理、代码审查、平衡性调整 |
| 周子强 | 美术、策划、卡牌与地图设计、UI 设计 |
| 罗春宇 | 技术负责人、整体框架、核心开发 |
| 琚长昊 | 动画、UI 设计、地图与事件表现 |
| 刘昶 | 策划、测试、卡牌机制与奖励流程 |
| 陈申学佳 | 美术、开发、卡面与地图素材 |
1.2 我们如何管理项目
团队使用 GitHub 管理代码，通过 Issue 拆分任务、Pull Request 合并代码；任务以主动接取为主、PM 分配为辅。日常沟通使用微信，阶段讨论通过腾讯会议或线下研讨完成，关键文档留存在飞书和团队博客中。
Alpha 阶段共留下 7 次 Scrum Meeting 记录，主题覆盖文档、卡牌设计、UI、卡面美术、地图设计、地图实现和关卡流程。我们的管理原则是：
- 先完成可连续游玩的核心闭环，再扩展内容；
- 每个任务有负责人、交付物和验收方式；
- 通过 PR 合并，避免多人直接修改主分支；
- 临近里程碑时优先修复阻断主流程的问题，视觉微调进入后续迭代。
实际开发中，团队根据进度对初始 WBS 进行了范围调整：将原计划中的 25 张卡牌、Boss 和部分复杂机制安排至后续迭代，Alpha 阶段优先交付 8 张可用卡牌、5 类僵尸、6 个战斗关卡以及完整的探索—战斗—奖励—补给流程。这是团队在时间、质量和资源之间做出的主要取舍。
2. 典型用户场景
2.1 目标用户
- 喜欢《植物大战僵尸》角色、美术和世界观的玩家；
- 喜欢《杀戮尖塔》等卡牌构筑游戏的玩家；
- 希望短时间上手、同时又能研究牌组配合的大学生玩家。
2.2 一次典型游玩过程
Alpha 版本已经满足这条典型路径：
地图探索 → 僵尸战斗 → 获得金币和卡牌 → 事件/休息/商店调整状态 → 精英战斗 → 通关
3. 杀手级功能：可自由探索的“植物卡牌冒险”
项目的特色在于把三个系统连接成同一局游戏：
- PvZ 元素：豌豆射手负责攻击、坚果墙负责防御、寒冰射手施加控制，玩家能借助已有认知快速理解卡牌。
- Roguelike 卡牌构筑：阳光、卡池、敌人意图、奖励三选一和商店删牌共同形成持续变化的策略空间。
- 2D 自由地图探索：玩家直接控制戴夫移动、选择路线并接触事件，而不是只在抽象节点图中点选下一关。
| 对比对象 | 主要体验 | 《植胜僵场》的差异 |
|---|---|---|
| 原版《植物大战僵尸》 | 塔防、阵线布置 | 植物被重构为卡牌，戴夫成为可操控的探索角色 |
| 《杀戮尖塔》 | 节点地图、卡组构筑 | 加入 PvZ 元素和可直接操作的 2D 探索地图 |
| 一般同类改编作品 | 更换角色或素材 | 地图、战斗、奖励、事件、商店和牌库之间存在连续状态 |
原版 PvZ 侧重塔防，《杀戮尖塔》侧重卡牌构筑和节点选择。本项目利用玩家熟悉的植物能力降低学习成本，并通过自由探索强化“冒险感”，形成差异化体验。
4. Alpha 版本交付结果
| 模块 | Alpha 版本结果 |
|---|---|
| 地图 | 1 张可自由移动的地图，小地图、敌人、事件、商店、休息点、教程和传送点均可交互 |
| 战斗 | 玩家/敌人回合、阳光、生命、金币、抽牌、弃牌、目标选择、逃跑、胜负结算 |
| 卡牌 | 8 张可用卡牌，包含攻击、技能、能力三类及四档稀有度设计 |
| 敌人 | 普通僵尸、路障僵尸、铁桶僵尸、撑杆跳僵尸、旗帜僵尸共 5 类 |
| 关卡 | 5 个普通关卡、1 个精英关卡 |
| 构筑 | 战后卡牌三选一、商店购买、休息点删牌、园艺卡册 |
| 发布 | Windows 与 macOS 可运行包、Bilibili 演示视频、玩家交流群 |
Alpha 版本已具备完整的可玩流程，仍有以下待改进项：部分图片和文字清晰度不足；卡牌术语和解释需要统一；地图界面生命值归零时的失败判定仍需修复。这些问题均已纳入 Beta 迭代计划。
5. 发布、推广与活跃用户
5.1 发布与推广动作
- 同时打包 Windows 和 macOS 版本，降低不同设备用户的试玩门槛；
- 通过北航网盘和百度网盘分发 Alpha 安装包；
- 在 Bilibili 发布 6 分 18 秒的完整演示视频；
- 建立玩家交流群，通过朋友圈和群聊邀请目标用户试玩；
- 在发布说明中公开已知问题和反馈入口。
Alpha 下载地址：
5.2 实际数据与统计口径
截至 2026 年 6 月 29 日，Bilibili 视频页面显示 169 次播放、11 个点赞、4 个投币、3 个收藏和 1 次分享。
团队通过安装包分发、交流群和试玩反馈进行去重核对，可确认的活跃试玩用户约为 40 人。其中，169 次视频播放属于宣传曝光数据；约 40 人来自安装、试玩和群内反馈记录。Alpha 版本尚未接入用户账号和遥测埋点，因此本阶段未形成基于产品日志的逐日 DAU 统计。
6. 软件工程质量
团队从版本管理、代码规模、自动化测试、缺陷修复、文档和持续集成等维度评估工程质量。
| 指标 | Alpha 阶段结果 | 证据口径 |
|---|---|---|
| Git 提交记录 | 125 条，其中 100 条为非合并提交 | 截止 2026-05-10 的 Git 历史 |
| Scrum 记录 | 7 次 | 团队每日例会博客 |
| TypeScript 源文件 | 96 个 | Alpha 截止提交 701e938 的 src/**/*.ts |
| 自动化测试脚本 | 11 个 | Alpha 截止提交的 test/ 目录 |
| 自动化测试声明 | 37 个 | node:test 中的测试声明 |
| Bug 修复 | 约 25 个 | 测试报告按 fix/bug/修复提交归类 |
| 文档 | README、地图设计/系统/路线图、功能规格、技术规格、测试与发布说明 | 仓库与团队博客 |
| CI | GitHub Actions | PR/main 触发 Prettier 检查和 node --test |
| 发布平台 | Windows、macOS | build:exe、build:mac 与公开安装包 |
项目采用 TypeScript + Phaser 3 + Vite + Electron。卡牌、敌人、事件和商店内容集中在数据层；GameState 管理一局游戏的全局状态，战斗、卡牌、地图和 UI 按目录拆分。Alpha 后期还对过大的 BattleScene 和 ShopPanel 进行了职责拆分，减少单一场景文件持续膨胀的问题。
GitHub Actions 在主分支 Push 和 Pull Request 时自动安装依赖、执行 Prettier 检查和 Node 自动化测试。README 提供了从克隆仓库、安装依赖到开发运行、生产构建和 Windows 打包的步骤。Beta 阶段将进一步增加新机器独立复现测试，记录环境搭建用时、遇到的问题和文档修订结果。
7. Demo演示
完整演示视频：https://www.bilibili.com/video/BV1eeRXBGEB9
第二部分：项目与团队总结
1. 项目管理
1.1 成员简介与个人博客
| 成员 | 角色 |
|---|---|
| 丁宇城 | PM |
| 周子强 | 美术/策划 |
| 罗春宇 | 技术负责人/美术 |
| 琚长昊 | 动画/UI 设计 |
| 刘昶 | 策划/测试 |
| 陈申学佳 | 美术/开发 |
1.2 任务分解与协作
Alpha 初始 WBS 将工作分为设计与计划、编码实现、测试与发布三个阶段，预计总工时 176 小时，人均约 29.3 小时。模块按地图、卡牌、战斗、事件、商店、UI、美术、测试和发布拆分。
协作中形成的主要接口包括：
- 地图负责移动和交互入口，战斗/事件/商店结束后将状态返回 GameState；
- 卡牌数据描述费用、目标和效果，战斗系统负责解释并执行；
- 奖励、商店和休息点统一修改金币、生命值和牌库；
- UI 从状态层读取数据，不自行保存另一套游戏状态；
- 美术资源按场景和用途整理，避免代码中散落临时路径。
1.3 沟通与记录
Alpha 阶段的 7 次 Scrum Meeting：
- Scrum Meeting 1：文档撰写
- Scrum Meeting 2：卡牌设计
- Scrum Meeting 3：UI 完善
- Scrum Meeting 4：卡面美术
- Scrum Meeting 5：地图设计
- Scrum Meeting 6：地图实现
- Scrum Meeting 7：关卡流程
1.4 时间、质量与资源的平衡
团队采取弹性工作制。正常阶段以成员主动接取任务为主；出现阻塞或里程碑临近时，由 PM 重新分配任务。Alpha 阶段做出的关键取舍包括：
- 优先打通完整游戏循环，不追求一次做完所有卡牌和关卡；
- 优先解决崩溃、卡死、状态丢失和主流程中断，轻微 UI 问题登记后延期；
- 先建立数据驱动的卡牌/敌人框架，再扩充内容；
- 为 Windows 和 macOS 都提供安装包，把“能交付给用户”作为完成标准；
- 临近期末时减少低价值会议，把时间留给联调、测试和发布。
1.5 实际进度与燃尽情况
Alpha 阶段尚未统一每日剩余工作量的记录口径，本节使用 7 次 Scrum 记录、Issue/PR 和 Git 历史呈现实际进度。Beta 阶段将统一任务粒度和完成标准，并在迭代过程中持续更新燃尽图。
| 时间段 | Git 提交记录数 | 过程观察 |
|---|---|---|
| 截至 4 月 19 日 | 2 | 需求、文档和仓库准备阶段 |
| 4 月 20—26 日 | 49 | 核心系统和首轮 UI 集中实现 |
| 4 月 27—5 月 3 日 | 24 | 地图、事件、战斗重构与联调 |
| 5 月 4—10 日 | 50 | 内容整合、Bug 修复、发布前打磨 |
最后一周共有 50 条提交，说明联调、重构和缺陷修复主要集中在发布前。后续迭代需要进一步前移集成测试与验收工作。
2. Alpha 阶段成员贡献
贡献分以 0.5 为基准、总和为 3.0。提交数量用于提供可验证的开发记录，最终分数同时综合策划、美术、测试、管理、代码审查和关键任务支援等成果。
| 成员 | 角色 | 团队贡献分（0.5为基准） | 具体 |
|---|---|---|---|
| 丁宇城 | PM | 0.6 | 代码审查、动员、项目管理、平衡性调整 |
| 周子强 | 美术/策划 | 0.6 | 大部分卡牌设计、地图设计、BOSS关设计、UI设计 |
| 罗春宇 | 技术负责人/美术 | 0.5 | 整体代码框架搭建、动画音效导入 |
| 琚长昊 | 动画/UI设计 | 0.6 | 动画制作、大部分UI设计 |
| 刘昶 | 策划/测试 | 0.4 | 整体游戏设计、平衡性测试 |
| 陈申学佳 | 美术/开发 | 0.3 | 卡牌贴图收集、玩法测试 |
统计方法：对截止 2026-05-10 的 Git 历史按作者邮箱归并；总计 125 条唯一提交记录。成员使用多个 Git 邮箱的情况已合并统计。
3. 用户场景与实际发布
3.1 开发前目标与发布结果
| 预期场景 | Alpha 结果 | 说明 |
|---|---|---|
| 玩家在地图中探索并选择路线 | 已满足 | 可自由移动，小地图标识主要交互点 |
| 使用植物卡牌进行回合战斗 | 已满足 | 阳光、抽弃牌、目标选择、敌人意图和状态结算均可用 |
| 通过战斗持续构筑牌组 | 已满足 | 奖励三选一、商店购买、休息点删牌 |
| 体验随机事件和资源管理 | 已满足 | 事件、金币、生命、商店和休息点已接入主流程 |
| 完成 Alpha 一局并结算 | 已满足 | 击败精英关后通过传送点进入通关界面 |
| 新用户无需解释即可上手 | 部分满足 | 有教程，但术语解释和卡牌清晰度仍需改进 |
| 长期反复游玩 | 未完全满足 | Alpha 内容量和数值平衡仍不足 |
3.2 用户反馈与 Bug
Alpha 阶段的用户反馈主要通过试玩、交流群和开发者现场观察收集。可追溯的改进包括：
| 反馈/问题 | 处理结果 |
|---|---|
| 卡牌拖拽时与僵尸点击区域冲突 | 禁用拖拽期间的敌人命中区并调整层级 |
| 奖励页面查看地图/牌库出现问题 | 修复场景覆盖逻辑，并允许跳过奖励 |
| 手牌太小、关键词不易理解 | 放大手牌，并在悬停时显示关键词解释 |
| 冰冻、易伤卡牌效果错误 | 修正卡牌技能实现 |
| 地图素材在合并冲突中丢失 | 恢复本地素材并同步场景代码 |
这些问题包括 UI 优化，也包括场景叠加、拖拽层级和合并冲突等联调阶段发现的问题。团队将用户反馈、Bug 修复与 Git 提交关联，形成可追溯的处理记录。
4. 特色功能复盘
4.1 团队自评
Alpha 达到了“验证 PvZ + 卡牌 Roguelike + 自由探索能否形成完整体验”的核心目标。地图、战斗、奖励、事件、休息和商店共同作用于生命值、金币和牌库，形成了连续的游戏系统。
与预期仍有差距的部分是内容量、数值平衡、术语一致性和动画反馈。8 张卡牌足以验证框架，但还不足以支撑大量不同构筑；一张地图能够验证探索方式，但重复游玩的变化有限。
4.2 用户侧信号
约 40 名可确认试玩用户、169 次视频播放以及点赞、投币和收藏说明项目对 PvZ 和卡牌玩家具有一定吸引力。试玩中最容易被理解的是植物能力与卡牌效果之间的对应关系；反馈最集中的是卡牌文字清晰度、术语解释和交互反馈。
5. 软件工程质量总结
5.1 文档与规范
项目已有：
- README：环境要求、快速开始、构建、打包、操作方式和目录结构；
- 功能规格说明书与技术规格说明书；
- 地图设计、地图系统和地图路线图文档；
- Alpha 发布说明、测试报告和 CI/CD 实践文档；
- Prettier 统一代码格式；
- GitHub Issue、PR 和分支协作流程。
主要问题是部分文档仍存在历史内容和当前实现不完全同步的情况。Beta 阶段需要把“代码变更时同步文档”加入 PR 验收清单。
5.2 测试与质量门禁
Alpha 截止提交中已有 11 个自动化测试文件、37 个测试声明，覆盖地图素材、战斗布局、奖励、事件、休息点、商店、牌库等模块。CI 会在 PR 和主分支 Push 时运行格式检查与自动化测试。
Alpha 测试报告基于提交历史归类出约 25 个已修复 Bug。现有测试主要覆盖数据完整性、界面布局和回归检查；Beta 阶段将进一步补充核心逻辑单元测试、覆盖率统计和极端边界场景。
5.3 CI/CD
项目使用 GitHub Actions：
- 拉取代码和 Git LFS 美术资源；
- 安装 Node.js 与依赖；
- 执行 Prettier 格式检查；
- 执行 Node 自动化测试；
- 通过本地脚本生成 Windows 和 macOS 安装包。
选择 CI 的原因是游戏包含大量资源文件和跨平台构建步骤，人工打包容易遗漏资源或产生环境差异。Alpha 的流水线主要承担持续集成质量门禁，桌面包仍由团队按发布清单生成和上传。
6. 经验教训与 Beta 计划
6.1 Alpha 阶段的经验与教训
- 可工作的完整闭环比孤立功能更重要。 地图、战斗、奖励和补给串起来后，用户才能真正评价玩法。
- 接口约定必须早于多人并行开发。 地图、战斗和奖励都修改 GameState，接口不清会带来大量联调成本。
- 任务完成标准需要包含测试与文档。 功能实现后还应完成自动化检查、跨模块验证和文档同步。
- 真实发布会暴露内部测试看不到的问题。 字体清晰度、术语理解和首次操作成本只有交给新用户后才明显。
- 燃尽图需要在迭代过程中维护。 团队应统一任务粒度和完成标准，按日更新剩余工作量。
- 活跃用户必须先定义统计口径。 视频播放、安装人数、完成一场战斗和逐日 DAU 是不同指标。
6.2 Beta 阶段计划
| 方向 | 计划 | 验收标准 |
|---|---|---|
| 内容扩充 | 扩展到 5 张章节地图、49 张卡牌和 20 余种关卡 | 内容数据可正常进入主流程并通过回归测试 |
| Boss 与机制 | 增加章节特色、Boss 战和更丰富的卡牌配合 | 玩家可完成完整多章节流程 |
| UI/动画 | 放大关键信息，统一术语，补充卡牌/僵尸动画与音效 | 新用户无需口头指导完成第一场战斗 |
| 稳定性 | 修复 Alpha 已知问题，补充自动化回归 | 阻断性 Bug 清零 |
| 存档 | 增加自动保存与继续游戏 | 退出后可恢复当前进度 |
| 用户数据 | 记录启动、战斗、通关与反馈 | 能区分曝光、下载、活跃和留存 |
| 工程流程 | 明确 Done 标准，保持 CI 和文档同步 | PR 必须通过格式、测试和评审 |
浙公网安备 33010602011771号