[T.19] 团队项目：Beta阶段项目总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[T.19] 团队项目：Beta 阶段项目总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习软件工程理论，在完成高质量的软件开发项目中深入学习软件工程经验
这个作业在哪个具体方面帮助我实现目标	总结Beta阶段经验，持续改进团队协作与工程实践

《植胜僵场》Beta 版项目总结

1、总体回顾

Alpha 阶段我们的目标是做出一版“可玩的游戏 Demo”。当时我们已经完成了启动界面、主菜单、地图探索、战斗、奖励、事件、商店、休息点和通关/失败提示等主流程，并发布了 Windows / macOS 版本 Demo。这个阶段最重要的成果，是证明《植胜僵场》的核心循环是成立的：玩家可以在地图中探索，进入回合制卡牌战斗，胜利后获得奖励，并通过卡牌、金币、事件和商店逐步构筑牌组。

进入 Beta 阶段后，我们的目标从“能玩”转向“更稳定、更完整、更像一个真正的游戏版本”。因此，Beta 阶段并不是简单增加功能，而是围绕 Alpha 暴露出的问题进行补强：提升 UI 清晰度、统一卡牌和状态规则、修复流程边界问题、加强自动化测试、完善存档继续流程，并继续拆分复杂模块。

从当前结果看，Beta 阶段基本达到了预期。项目已经拥有较完整的地图探索、战斗、奖励、商店、休息、事件、Boss 和结算流程，工程上也形成了更清晰的 TypeScript + Phaser + Vite + Electron 技术链路。目前项目约有 155 个主要源码/文档/测试文件，源码和测试约 3.9 万行，测试文件 30 个，已经不再只是课程原型，而是一款结构较完整的学生游戏作品。

2、Alpha 问题回顾与 Beta 改进

Alpha 阶段总结中，我们记录了几个主要问题：部分 UI 和卡牌文字清晰度不够，卡牌术语不统一，新手理解成本偏高，地图界面 HP 归零后的失败判定存在缺陷，自动化测试、CI 出口条件和真实用户数据统计还不够完整。

Beta 阶段我们主要围绕这些问题做了改进：

Alpha 阶段问题	Beta 阶段改进	当前状态
UI 信息不够清晰	重构战斗顶部栏、卡包面板、商店界面、地图提示等 UI	明显改善
卡牌/状态规则理解成本高	增加状态标签、效果预览、卡牌说明和统一格式化逻辑	基本改善
地图和战斗流程边界问题	修复战斗结束、失败判定、奖励跳转、地图交互等流程问题	基本稳定
测试覆盖不足	增加地图、商店、奖励、状态、存档、战斗表现等测试	有基础覆盖
场景文件职责偏重	将部分 UI、业务逻辑、数值计算拆到独立模块	持续改善
发布流程不够系统	增加 build、typecheck、Electron 打包等脚本	基本可用

可以说，Alpha 解决的是“有没有游戏”，Beta 解决的是“游戏能不能比较顺畅地玩下去”。

3、目标完成情况

Beta 阶段的主要目标完成情况如下：

目标	完成情况	说明
完整主流程	已完成	地图、战斗、奖励、事件、商店、休息、Boss、结算流程已打通
卡牌构筑体验	已完成	当前已有约 42 张植物卡牌，并支持不同费用、稀有度、状态和效果
敌人与战斗挑战	已完成	当前已有约 30 种敌人，包括普通、精英、Boss 和特殊敌人
事件与地图探索	已完成	当前已有约 14 个事件，并支持脚本节点和地图实体交互
商店与道具	已完成	支持买卡、买一次性道具、付费删牌和楼层商店状态记录
存档继续流程	部分完成	已有 SaveManager 和继续游戏能力，但完整恢复体验仍需继续打磨
自动化测试	已完成基础建设	当前有 30 个测试文件，覆盖多个关键模块
桌面打包	基本完成	支持 Electron 打包 Windows / macOS 版本

Beta 阶段最重要的成果，是项目已经形成了一个较完整的闭环。玩家不只是进入一个孤立战斗，而是可以在一局游戏中经历探索、成长、消耗、奖励和挑战。

4、软件工程质量提升

Alpha 阶段后期我们已经意识到数据驱动和模块拆分的重要性。Beta 阶段这方面进一步加强。

维度	Alpha 阶段	Beta 阶段
架构	主流程已跑通，但部分逻辑集中在场景中	拆分出 core、card、battle、data、ui 等模块
数据	卡牌、敌人、事件已开始数据化	数据结构更稳定，便于扩展和平衡
战斗	基本回合制玩法可用	增加状态、预览、动画、敌人意图、结算等完整体验
UI	能显示必要信息	顶部栏、卡包、商店、地图提示、战斗反馈更完整
测试	有少量测试，更多依赖手动试玩	建立 30 个测试文件，开始覆盖核心规则
发布	能发布 Demo	构建、检查、桌面打包脚本更明确

比较成功的工程实践包括：

• 使用 src/data/ 管理卡牌、敌人、事件、商店和平衡参数；
• 使用 DamageMath 统一伤害和格挡计算，减少预览和实战不一致；
• 使用 ShopService 管理商店购买、删牌、售罄状态，避免逻辑散落；
• 使用 RunStatusBar、DeckPackPanel、ShopPanel 等 UI 组件降低重复实现；
• 使用 Node test runner 对地图、商店、奖励、状态、存档等模块做回归测试。

5、计划与执行

Alpha 阶段的经验告诉我们，“能完整玩一局”比“堆很多孤立功能”更重要。因此 Beta 阶段的计划重点是补齐主流程和稳定体验。

计划项	执行结果	复盘
修复 Alpha 暴露问题	基本完成	UI、流程边界、状态显示等问题明显减少
丰富卡牌和敌人内容	完成	卡牌和敌人数量足以支撑基础构筑体验
完善地图探索	完成	2D 地图、实体、商店、事件、Boss 形成完整路线
强化战斗表现	超预期投入	动画和反馈提升明显，但也消耗较多开发时间
增加测试保障	部分完成	测试数量提升，但复杂组合测试仍不足
完善文档与发布	部分完成	README 和协作说明较完整，但部分旧文档仍需同步更新

Beta 阶段最大的计划偏差，是表现层和 UI 打磨比预期更耗时。游戏项目中“看起来顺畅”和“逻辑上能跑”之间有很大距离，动画、状态同步、按钮反馈、卡牌预览都会消耗额外时间。

6、设计与实现

当前项目采用 TypeScript + Phaser 3 + Vite + Electron。相比早期评审材料中设想的 Unity/C#，最终实现更偏 Web 技术栈，优点是开发迭代快、调试方便、跨平台打包路线清晰。

模块	当前实现	评价
场景系统	Boot、Menu、Map、Battle、Reward、Event、Rest、Victory 等	主流程完整，但 BattleScene 和 MapScene 仍偏大
卡牌系统	CardData、CardEffect、Deck、CardPreview、ChanceResolver	数据驱动较好，扩展成本较低
战斗系统	BattleManager、Player、Enemy、StatusEffect、DamageMath	核心规则较完整，复杂状态仍需更多测试
地图系统	WorldMapData、MapGenerator、WorldMapRenderer、MinimapPanel	探索感增强，但地图维护成本提高
商店系统	ShopService、ShopPanel、shopItemFormatters	业务逻辑和 UI 有一定分离
存档系统	SaveManager、GameState	基础能力可用，恢复流程仍可增强
表现系统	卡牌动画、敌人动画、音效、状态视觉	体验提升明显，但维护复杂度增加

Beta 阶段最有价值的设计改进，是把许多原本可能写死在场景里的规则抽离出来。对于卡牌游戏来说，这一点非常重要，因为后续新增卡牌、敌人、事件时，如果每次都要改场景代码，项目会很快失控。

7、测试与发布

Alpha 阶段发布后，我们发现真实玩家反馈能暴露很多内部测试发现不了的问题，例如 UI 清晰度、术语理解、地图失败判定等。Beta 阶段我们在此基础上增加了自动化测试，但仍然需要更多系统化试玩。

测试类型	当前情况	后续改进
单元测试	已覆盖部分规则模块	增加卡牌效果、状态叠加、敌人行动组合测试
回归测试	修复 bug 后逐步补测试	每个历史 bug 尽量保留最小复现用例
手动测试	依赖开发者完整试玩	制定固定验收路线，例如“新游戏到 Boss”
构建验证	支持 npm run build	发布前固定执行 typecheck、test、build
桌面验证	支持 Electron 打包	加强 Windows/macOS 实机验证

发布方面，Beta 版本已经具备更清楚的打包链路，但最终版本仍需要把发布检查表固定下来，例如：是否能新开局、是否能继续游戏、是否能打到 Boss、失败/胜利结算是否正确、资源是否全部加载成功。

8、团队协作

Alpha 阶段团队已经进入“规范阶段早期”：大家开始围绕 issue、PR、文档、发布说明和测试反馈协作。Beta 阶段这种协作方式进一步成熟，尤其是在模块拆分和问题修复上，团队不再只是各写各的功能，而是更关注整体流程是否稳定。

做得比较好的地方：

• 能把 Alpha 反馈转化为 Beta 的具体改进项；
• 能围绕核心玩法优先级推进，而不是无节制扩展；
• 开始重视测试、文档和发布出口；
• 对战斗、地图、商店、UI 等模块形成了初步分工。

仍需改进的地方：

• 任务验收标准还可以更量化；
• Code Review 应更关注行为风险和测试覆盖；
• 文档更新有时落后于代码实现；
• 大型模块仍容易集中到少数人维护。

9、对照敏捷原则

Alpha 阶段我们做得最好的是“以可工作的软件作为进度的主要度量”。Beta 阶段这一点仍然成立，而且更进一步：我们不只是交付一个能打开的 Demo，而是交付一个流程更完整、问题更少、结构更清楚的版本。

Beta 阶段最符合敏捷精神的一点是：

根据真实反馈持续调整，而不是固守最初设计。

Alpha 发布后暴露出的问题，直接影响了 Beta 阶段的优先级。比如 UI 清晰度、状态显示、战斗结算、地图交互、测试覆盖，这些都不是一开始写在设计文档里最显眼的内容，但它们决定了玩家是否能顺畅玩下去。

10、主要收获

• Alpha 的意义是证明方向可行，Beta 的意义是证明流程可靠。
• 游戏开发中，最难的不是实现单个功能，而是让地图、战斗、奖励、商店、事件、存档一起稳定工作。
• 数据驱动是卡牌游戏后续扩展的基础。
• UI 和动画能显著提升体验，但必须控制范围，否则会压缩测试和修 bug 时间。
• 自动化测试虽然不能完全替代试玩，但能保护核心规则不反复回退。
• 文档必须跟着项目一起更新，否则早期设想和实际实现会逐渐脱节。

11、下一阶段计划

优先级	改进项	目标
高	完善发布验收流程	明确最终版发布前必须通过哪些检查
高	强化战斗规则测试	覆盖更多卡牌、状态、敌人组合
高	拆分大型场景类	降低 BattleScene、MapScene 的维护成本
中	完善存档恢复	提升继续游戏的可靠性
中	数值平衡调整	通过试玩反馈优化难度曲线
中	同步文档	修正旧材料中与当前实现不一致的内容
低	增加原创素材	提升项目独立辨识度，减少素材依赖

12、总结

回看 Alpha 阶段，我们完成的是“从 0 到 1”：让《植胜僵场》真的可以被下载、运行和试玩。进入 Beta 阶段后，我们完成的是“从能玩到更稳定”：补齐主流程，修复边界问题，改善 UI 反馈，增加测试，并让项目结构更适合继续维护。

当前版本仍有不足，例如复杂战斗组合测试不够、存档恢复还可增强、部分场景类仍然偏重、数值平衡仍需更多玩家反馈。但相比 Alpha 阶段，Beta 版本已经更接近一个完整游戏：它不只是展示玩法想法，而是能让玩家较完整地体验探索、战斗、成长和通关目标。

下一阶段，我们最重要的任务不是继续无限加功能，而是提高最终版本质量：稳定核心循环，完善测试和发布流程，打磨新手体验和数值平衡，让《植胜僵场》从“一个不错的课程 Demo”继续走向“一个真正完整、可靠、好玩的游戏作品”。