[T.18] 团队项目：Beta 阶段项目展示

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[T.18] 团队项目：Beta 阶段项目展示
我在这个课程的目标是	接触理解应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力
这个作业在哪个具体方面帮助我实现目标	展示 Beta 阶段团队项目成果

项目与团队亮点

引言

Alpha 阶段结束时，HexaVigil 已经具备塔防战斗、资源采集、干员部署、基础商店和夜晚防守等核心原型能力，但整体功能较为零散，各模块间关联性较弱，有趣性不足。因此我们 Beta 阶段的工作目标，是在 Alpha 原型基础上完成一次系统化升级：将项目推进为一款能够从开局到结算完整游玩、玩法循环清晰、视听表现完整、并具备持续迭代能力的 Roguelike 塔防游戏。

围绕这一目标，Beta 阶段主要从两个维度展开：

产品质量提升：完善战斗、养成、地图、关卡、Boss、随机事件、剧情教程、音频和界面体验，使玩家能够获得更完整、更稳定、更具策略性的游戏体验。
工程质量提升：重构关键系统，推动内容数据化，建设自动化测试、调试工具、美术生产流程、持续集成和文档治理，为后续开发提供可维护、可扩展的工程基础。

总体介绍

本节集中呈现 Beta 阶段在代码仓库层面的客观数据。

总体规模

指标	数值
时间跨度	2026-05-25 ~ 2026-06-15(约 3 周)
有效活跃天数	11 天
提交(commit)数	230
变更文件数	1742
代码增减	新增 53687 行 / 删除 8339 行
协作方式	多人并行 + 线性 rebase 集成无杂乱的合并记录，历史清晰可追溯

提交类型分布

类型	数量	占比
新功能 `feat`	111	48%
缺陷修复 `fix`	55	24%
文档 `docs`	35	15%
杂务与配置 `chore`	17	7%
测试 `test`	5	2%
重构 `refactor`	3	1%
其他：平衡、样式、回退等	4	2%

说明：测试与重构工作有相当一部分随功能提交一并完成，因此其实际工作量高于独立提交前缀反映的数量。

关键内容规模变化

项目	Alpha 阶段	Beta 阶段
GDScript 脚本文件	92	155
Godot 场景文件	26	31
资源文件总量	991	1746
随机事件配置	8	34
遗物/增益配置	31	45
夜战波次模板	6 套固定波次	21 套模板化波次
夜晚词缀	无独立表	7 个词缀
音频文件	21	46

具体分工

Beta 阶段主要分为“玩法”和“美工”两条主线：

玩法统筹：刘笑晨、肖一涵。
美工统筹：黎嘉旋。
地图协作及音效处理：李延博。
基建/路线/事件协作：赵栩栩。
美术资产协作：于忠雨、初浩然。
全员参与灰度测试和 QA。

总体进程

发布详情

最终发布于网页版（itch），并且新增Windows桌面版。

第一部分：玩法与体验更新

本部分对应软件质量的提升，玩家可以直接感受到的产品质量提升。

一、战斗系统升级

Beta 阶段对战斗系统进行了系统性增强，使战斗反馈更明确、操作节奏更可控、判定规则更可靠。

统一攻速体系
所有单位引入了统一的「攻击速度」数值。过去各单位的出手节奏由零散设定决定，容易互相打架、数值叠乱；现在干员和敌人共用同一套攻速规则，遗物、光环对攻速的加成也统一归算，出手快慢一目了然，并且会直接显示在干员面板上，便于玩家理解输出节奏。
子弹时间机制
新增战斗中的时间放缓能力。玩家在高压波次、Boss 技能或密集部署时，可以获得更充分的判断时间，提升关键操作的容错空间，高难关卡的操作空间更大。
更可靠的命中判定
实现“脚印命中”逻辑，敌人身体覆盖到的格子都会被纳入可命中范围。该改动解决了敌人处于格子边缘时可能出现的漏判问题，使射程反馈更符合玩家直觉。
高地与人工高台
新增高地地形，并将其接入部署校验。狙击、术师等远程职业可以利用高地获得部署优势；同时新增人工高台建筑，允许玩家通过消耗资源临时创造远程部署点。人工高台被摧毁时，台上单位会受到直接影响，形成高收益与高风险并存的战术选择。
技能自动释放
新增技能自动释放开关，支持全局和单个干员层面的设置。该功能减少了重复操作，使玩家能够将更多注意力放在阵容布置、路线判断和资源管理上。

二、构筑与养成系统完善

Beta 阶段把原本各自孤立的成长点，串成了一条完整的「成长—取舍—构筑成型」的 Roguelike 循环。

遗物系统重做
遗物库从冗杂的七十余件整理为三十余件精炼遗物。新遗物按稀有度、类别、职业过滤、来源事件等维度组织，并支持稀有度门控和定向抽取（按游戏进度控制稀有度——前期只出普通遗物，越往后越能遇到稀有与传说。三选一的槽位进行分工：一个偏向用户正在走的盟约流派、一个完全随机、一个保底经济收益。打完阶段性 Boss 后，还会额外给用户一次高稀有度遗物的保底奖励），降低纯随机带来的失控感，同时增强长期构筑的方向性。
盟约流派系统上线
实装 7 类盟约，包括不屈、精准、坚守、迅捷、突袭、萨尔贡、远见。盟约会根据已部署或已拥有干员实时统计人数、层数和档位，并将加成统一接入单位、商店和战斗逻辑。玩家可以围绕盟约组合形成不同流派。
事件与盟约联动
地图事件中的“古代祭坛”可以为指定干员灌注盟约印记，使单个干员获得跨流派构筑价值。灌注结果也会在界面上以角标和状态信息呈现，方便玩家追踪。
商店策略增强
商店新增锁定功能，玩家可以保留关键卡牌到下一天。商店费用档位和出现权重按前、中、后三幕调整，让后期更容易凑齐高费强卡；中后期会根据玩家已有盟约倾向提升相关干员出现概率，帮助构筑更稳定成型。
升星与出售机制
新增指定干员升星功能，玩家可以消耗资源直接强化核心单位；不再需要的干员也可以出售回收资源。该机制提升了阵容调整能力，减少了随机商店带来的被动感。

三、九天三幕关卡节奏

Beta 阶段将整体流程升级为九天三幕结构，使游戏从短流程原型转向有阶段推进、有压力递增、有高潮节点的完整战役。

三幕式流程
游戏被组织为 9 天流程，第 3、6、9 天分别作为幕末 Boss 夜。该结构让整局游戏具备更清晰的起承转合，也为难度、奖励和内容解锁提供了稳定节奏。
多波次夜战
夜晚不再只是单波敌人进攻，而是可以由多波敌潮组成。波次之间存在短暂间隔，玩家需要根据前一波战况及时调整部署和技能策略。
模板化波次系统
原有少量固定波次被替换为 21 套模板化波次。波次按照 early、mid、late、boss 等阶段组织，并通过 lane 角色映射到实际出怪口，提高了复用性和变化度。
夜晚词缀机制
新增 7 个夜晚词缀，包括急行军、嗜血、空袭、重甲推进、巫术潮汐、亡语之夜、出怪失衡。词缀会在白天提前展示，并随天数推进逐步增加数量，使每一晚的战斗目标和威胁点有所不同。
难度曲线重调
新增全局强度系数，使敌人数量、数值和 Boss 压力随天数逐步提升，后期爬升更明显。同时调整起始经济、阶段奖励和后期声望收益，避免玩家过早滚雪球导致挑战不足。

四、Boss 战表现与机制强化

Beta 阶段重点完善了 Boss 战的机制差异和视听表现，使幕末战斗具备更明确的高潮感。

奶龙酋长表现增强
接入专属 Boss BGM，以及登场咆哮、阶段变化、二阶段笑声、普通语音和死亡音效。声音反馈会随战斗阶段触发，显著提升 Boss 战辨识度。
凑凑企鹅完整实装
新增凑凑企鹅 Boss，具备双阶段机制：第一阶段以近战、反弹和范围法术普攻形成阵地压力；第二阶段会制造持续火雨，迫使玩家调整部署位置和防线结构。
专属美术与特效
凑凑企鹅接入正式立绘，并配套寒焰火雨、冲击环、反弹火花、阶段爆发等特效。Boss 技能不再只是数值变化，而是具备可见、可听、可识别的战斗表现。

五、地图生成与敌人行为升级

地图与敌人移动是 Beta 阶段改动最深的系统之一。其目标是让地图更自然、路线更可信、敌人推进更稳定。

自然地貌生成
新地图生成器采用 terrain-first 思路：先生成高度、湿度和地形分类，再布置核心、出怪口、资源与事件点。地图不再只是随机障碍集合，而是具备高地、河流、浅滩、山地、水域和平原等自然结构。
五出怪口与动态启用
地图边缘生成 5 个出怪口，每天根据种子和规则启用其中一部分。玩家需要根据当天实际来袭方向调整防线，而不是长期固定防守单一路线。
封门与事件影响
玩家和部分随机事件可以临时影响出怪口启用状态，例如封锁某个出怪口或改变当晚来袭方向。这让地图资源、行动力和夜晚压力之间产生更强的策略联系。
路线覆盖预览
路线预览从单条线改为覆盖面高亮。不同出怪口使用固定颜色和编号，地图高亮与右侧信息栏保持一致；鼠标悬停时可以联动显示对应区域，提升可读性。
Flow Field 敌人推进
敌人寻路由单体路径计算逐步重构为共享距离场推进。所有敌人基于同一份到核心的距离信息行动（敌人始终朝核心稳定推进、自然地铺开队形，遇到拦路的干员还会聪明地绕行），减少重复寻路计算，并修复了左右摇摆、回头、卡住和绕行失效等问题。

六、随机事件地图化

Beta 阶段将随机事件从简单奖励入口升级为地图探索中的重要决策点，变成了有故事、有取舍的玩法。

事件数量扩充
随机事件从 Alpha 的 8 个扩展到 Beta 的 34 个，涵盖商人、祭坛、市场、仓库、晚餐、剑、战争艺术、粉龙等多类事件主题。
地图事件点机制
事件不再只以弹窗形式随机出现，而是铺设在地图上的可交互点位。玩家需要结合行动力、资源和探索路线决定是否前往触发。
契约式选择
事件选择包含资源消耗、核心生命变化、声望变化、遗物奖励、盟约灌注、当晚出怪影响等后果。玩家需要在短期收益和长期风险之间做判断，每次选择都可能影响你这一局的走向。
插画与文本补齐
每个事件状态均配套专属插画和剧情化文本，事件面板也支持多选项展示和结果反馈。事件由“功能按钮”升级为具有叙事表达和策略权衡的系统。
开局铺设与触发链路重构
最新实现会在第 1 天开局时一次性铺设事件点，并通过地图交互确认、事件面板展示、结果结算和地图刷新形成完整链路，避免误触并提升流程清晰度。

七、剧情、教程与音频体验

Beta 阶段补齐了新玩家进入游戏所需的叙事、引导和声音反馈。

正式开场剧情
新增游戏剧情引入。开局剧情具备双角色对白带你进入世界观；对话系统支持角色立绘、多档背景、逐字显示与快进/跳过，使游戏开场更加完整。
独立新手教程
主菜单新增教程入口，玩家可以在独立的不影响正式存档的关卡中跟着对话式引导学习建造、部署、战斗和基础操作。教程结束后能够衔接正式游戏，降低首次上手门槛。
关键音效补齐
新增夜晚开始、波次推进、胜负结算、技能释放、物理/法术命中、弹道、敌人死亡、建筑受击、核心受击、对话反馈等音效。游戏从反馈较少的原型状态，提升为具备完整听觉反馈的版本。

八、界面与操作体验提升

Beta 阶段对主 HUD、部署栏、单位详情、遗物面板、事件面板、结果界面和设置界面进行了系统性打磨，界面更好看、更好用、数值更准。

信息展示更完整
HUD 中新增夜晚词缀、波间倒计时、当前波次、出怪口说明、事件数量、盟约状态、遗物来源等信息，使玩家能更准确地理解当前局势。
操作效率更高
部署卡组加入职业筛选；路线预览支持快捷键；音量、显示、快捷键等设置项被集中到设置面板中，减少操作成本。
单位详情更实用
单位详情面板展示干员属性、技能、升星状态、盟约和遗物影响，并提供定向升星等操作入口，让成长决策更集中。
遗物和事件界面更清晰
遗物界面补齐稀有度样式、图标框、过滤标签和卡片状态；事件界面增加专属选择按钮、插画区域和结果描述，信息层级更加明确。
美术风格统一
大量 UI 框体、按钮、图标、面板和状态贴图被替换为统一美术风格。assets/ui/generated、assets/ui/source、assets/ui/styles 和 assets/ui/templates 均有大规模更新，使界面从原型风格转向较完整的视觉交付状态。

九、发布展示与品牌素材

Beta 阶段补充了面向发布和展示的资源，使项目具备更完整的外部呈现能力。

主菜单和结算界面打磨
主菜单、结果页和启动相关按钮接入新 UI 资产，提升游戏开始和结束流程的完整度。
品牌素材补齐
新增游戏图标、itch.io 封面、页面背景、banner 和嵌入页背景等素材。项目不再只停留在开发运行层面，而是具备对外发布和展示所需的基础包装。
导出配置更新
更新 Godot 导出配置和 CI 发布脚本，为 Windows 版本和 Web 版本发布提供支持。

十、稳定性与体验修复

在大量功能落地的同时，Beta 阶段持续修复影响体验的问题。

修复敌人在特定地形中来回摇摆、回头、卡住或绕行失败的问题。
修复路线预览与实际敌人移动不一致的问题。
修复出怪口格子被误探索、误消耗行动力的问题。
修复部分弹窗、浮层和结果面板因层级或可见性问题无法显示的问题。
修复商店、探索、出售等数值显示与真实消耗不一致的问题。
修复祭坛离开选项、随机事件结果、教程进入正式游戏等流程问题。
修复缺失贴图、滚动条显示异常、重复波次警告等 UI 问题。

这些修复提升了版本稳定性，也减少了玩家在长流程中遇到中断、误导或无法继续操作的风险。

第二部分：工程质量与过程保障

本部分对应软件工程质量的提升，玩家不一定直接感知，但对项目可维护性、稳定性和持续迭代能力至关重要的工程改进。

一、更稳固的底层架构

敌人寻路重构
旧方案更依赖单体路径与局部补丁，容易在复杂地形或拥挤场景中出现摇摆和卡顿。Beta 阶段引入共享距离场和 Flow Field 推进逻辑，所有敌人共享同一份「到核心的距离地图」，每一步只需查表即可决定走向，既根治了来回踱步，又因为不必为每个敌人单独反复计算路径而显著降低了性能开销。该方案同时提升了行为稳定性和运行效率。
拆分臃肿的核心逻辑：
把几处越长越大、职责混杂的核心代码，拆分成各司其职的小模块。模块边界清晰后，后续维护和排错都更轻松。
- 地图生成模块拆分
  地图生成从单一大流程拆分为随机种子、地形场、核心选择、出怪口布置、路径连通、资源放置、高地生成、修复 pass 等多个模块。职责边界更清楚，便于单独测试和调参。
- 敌人与 Boss 职责拆分
  敌人移动、攻击、Boss 阶段控制和特殊技能逻辑逐步拆分到独立控制器中，降低单个 Actor 脚本的复杂度。
- 剧情系统独立化
  新增剧情数据层和播放控制层，使剧情内容、界面表现和游戏流程控制分离，便于后续扩展更多剧本。

二、内容数据驱动化

Beta 阶段将大量规则从代码中迁移到数据表或配置文件中，提高内容扩展效率。

夜战内容由 wave_templates.json 管理，新增波次主要通过配置完成。
夜晚词缀由 night_affixes.json 管理，效果统一由服务类解析。
随机事件由 events.json 管理，支持前置条件、奖励、隐藏结果和多选项。
开场剧情由 data/stories 下的数据文件管理。
地图生成参数由 map_generation.json 管理，便于快速调参和回归。

数据驱动化的结果是：策划和内容迭代不再高度依赖修改核心逻辑，新增内容的风险更低，版本调整也更可控。

三、确定性地图生成与可复现调试

为保证程序化生成的地图既随机又可调试，Beta 阶段建设了确定性随机基础。

同一随机种子可以稳定生成同一张地图，便于复现问题。
不同生成阶段使用派生随机流，调整某一阶段参数时不会无意影响全部结果。
地图生成保留 report 和 fallback 信息，便于定位失败原因。
出怪口、波次、词缀等运行时内容也使用种子驱动，保证预览和实际执行一致。

这套机制让地图生成不再只是“随机出图”，而是具备可复现、可测试、可调参的工程属性。

四、美术资产生产流程工程化

这是 Beta 阶段最具代表性的工程成果之一。Beta 阶段建立了更稳定的 UI 和地图资产生产流程。

新增 UI 派生资产生成工具，可以从源图生成运行时所需的 frame、bar、icon 和 overlay。
新增 UI 实际尺寸扫描工具，减少图片资源与控件尺寸不匹配的问题。
墙体、覆盖层、地图叠加效果等部分资源改由脚本生成或统一接入，减少手工维护成本。
原始素材、生成素材、样式资源和模板资源分层管理，使资产来源更清晰。

该流程提升了美术资源的可追溯性和可重跑能力，也降低了后续统一换肤或补充资产的成本。

五、自动化测试与调试工具

Beta 阶段新增大量 headless 测试脚本和调试工具，为复杂系统提供质量保障。

新增地图生成、Flow Field、出怪口、夜晚词缀、波次模板、遗物抽取、契约事件、商店锁定、定向升星、教程流程、UI 可见性和关键音效等测试脚本。
新增移动批量测试台，用于在大量地图上观察敌人路径稳定性和推进效果。
新增作弊面板和 CheatManager，便于快速跳转天数、修改资源、触发事件和复现战斗状态。
CombatSandbox 持续作为战斗、敌人、Boss 和 UI 操作链路的调试入口。

这些工具将质量保障从“人工完整游玩后发现问题”前移为“修改后快速回归关键链路”，显著提高了开发效率。

六、持续集成与发布流程

Beta 阶段补齐了自动构建和发布相关能力。

更新 Godot CI 配置，支持自动构建与导出。
补充 Windows 与 Web 版本发布配置，减少人工打包成本。
接入 itch.io 相关发布资源和页面素材。
增加 Beta 燃尽统计工作流，用于跟踪阶段进度。

这些改进使项目具备更稳定的交付流程，减少了临近发布时手工操作带来的不确定性。

七、文档治理与团队协作规范

Beta 阶段对项目文档进行了系统整理。

更新架构、接口、数据表、UI 系统等核心文档，使其尽量与当前实现保持一致。
清理数千行已经交付或废弃的旧开发文档，减少过时信息对后续开发的误导。
新增 Boss 特效、事件插画、地图资产、UI 资产等生成规范，支撑后续内容生产。
新增团队/协作规范文档，统一了工作流程、目录结构与验收方式，明确分支、提交、验证、资产、UI 和 Godot 脚本约束。对于复杂系统，团队还坚持“先写设计方案、再分阶段实现、最后回归测试并对齐文档」的工作节奏，使多人并行开发有清晰的边界。

文档治理让团队在多人并行开发时拥有更统一的上下文，也提高了交接和复盘效率。

八、持续偿还技术债

除新增功能外，Beta 阶段也持续进行代码整理和质量修复。

删除被新系统取代的旧预览、旧路线、旧资产和过时文档。
修复 GDScript 类型推断、枚举、未使用参数等告警问题。
将硬编码费用、常量和显示文本逐步收敛到统一数据源。
对 UI 层级、弹窗可见性、资源路径和导入文件进行多轮修复。

这些工作降低了后续维护成本，减少了隐藏缺陷继续累积的风险。

结语

Beta 阶段的核心成果，可以概括为两个方面：

在玩家体验层面，HexaVigil 补齐并打磨了战斗、养成、九天三幕流程、Boss、地图、随机事件、剧情教程、音频和界面，形成了可以完整游玩且内容更丰富的 Roguelike 塔防版本。
在工程质量层面，项目完成了关键系统重构、数据驱动改造、自动化测试建设、美术生产流程工程化、持续集成发布和文档治理，为后续迭代建立了更可靠的基础。

因此，Beta 阶段不仅提升了游戏的可玩性和完成度，也显著增强了项目的可维护性、可扩展性和交付稳定性。这是本阶段在软件质量与软件工程质量两个维度上的主要改进。

项目与团队总结

一、项目管理

1. 团队成员简介和个人博客地址

Beta 阶段团队共有 7 名成员。根据公开展示博客，团队分为“玩法”和“美工”两条主线推进：玩法统筹负责核心循环、地图、事件、数值和系统集成，美工统筹负责 UI、视觉资产、展示素材和发布包装，其他成员分别承担音频、地图协作、事件协作、美术资产协作和 QA。

成员	Beta 阶段主要定位	简介与主要参与方向
刘笑晨	玩法统筹 / 平衡与体验	参与玩法方向把关、数值平衡、路线预览修正、新手教程和后期奖励调整
肖一涵	玩法统筹 / 核心开发	负责大量核心功能和系统集成，包括地图、敌人、战斗、事件、遗物、盟约、剧情、UI、文档治理等，完成例会记录
黎嘉旋	美工统筹 / UI 与发布展示	负责 UI 打磨、美术资产接入、部署筛选、路线预览快捷键、遗物界面、品牌素材和发布配置
李延博	地图协作 / 音效处理	参与地图相关协作，并负责 Boss 音乐、语音、战斗音效和音频资产检查工具
赵栩栩	基建 / 路线 / 事件协作	参与随机事件地图化、作弊面板、新手教程流程和部分基建/路线协作，完成Beta阶段各类博客作业以及例会记录
于忠雨	美术资产协作 / QA	参与美术资产协作、截图素材整理和 Beta 阶段灰度测试
初浩然	美术资产协作 / QA	参与美术资产协作、展示材料整理和 Beta 阶段灰度测试

2. 团队如何进行项目管理，相比 Alpha 阶段有什么改进

Beta 阶段采用以 GitHub 为中心的项目管理方式：

以 dev 作为日常开发主干，main 作为稳定版本和发布版本分支。
按功能、修复、工程配置建立分支，例如 feature/<name>、fix/<issue>、chore/<name>。
提交信息采用统一规范，如 feat(scope): ...、fix(scope): ...、docs: ...、chore(CI): ...。
使用 Issue 记录任务、Bug 和里程碑，PR 描述关联对应 Issue。
合入 dev 前要求通过 Godot CI 构建，避免主干不可运行。
通过 .github/workflows/update-beta-burndown.yml 自动生成 Beta 燃尽图，辅助跟踪剩余任务。

相较 Alpha 阶段，Beta 阶段的改进主要体现在：

管理对象更清晰：Alpha 阶段更多是在搭核心原型；Beta 阶段开始按地图、夜晚、事件、UI、音频、测试、文档等模块推进。
工程流程更完整：引入 Windows/Web 自动构建、itch.io 发布流程和 Beta 燃尽图。
质量闭环更强：新增 23 个 test_*.gd headless 测试脚本，并补充 CombatSandbox、作弊面板等调试工具。
文档更主动同步：Beta 阶段有 35 个 docs 类型提交，并更新架构、接口、数据表、UI、资产生成规范等文档。

3. 团队成员如何分工协作，有什么经验教训，相比 Alpha 阶段有什么改进

Beta 阶段分工大体如下：

工作方向	主要内容	代表性成果
核心玩法	九天三幕、夜晚波次、词缀、Boss 夜、胜负判定	`night_template_resolver.gd`、`wave_templates.json`、`night_affixes.json`
地图与敌人	terrain-first 地图、五出怪口、Flow Field 寻路、路线预览	`map_generator.gd`、`flow_field.gd`、`map_layout.gd`
构筑系统	遗物、盟约、商店锁定、升星、出售、自动技能	`covenant_manager.gd`、`operator_progression.gd`、`buffs.json`
随机事件	事件地图化、事件插画、祭坛灌注、事件触发链路	`events.json`、`random_event_manager.gd`、`EventPanel.tscn`
UI 与美术	HUD、单位详情、遗物面板、事件面板、设置面板、品牌素材	`CombatHud.tscn`、`assets/ui/`、`assets/branding/`
音频	Boss BGM、语音、战斗音效、胜负结算音效	`audio_manager.gd`、`assets/audio/*`
测试与调试	headless 测试、CombatSandbox、作弊面板、音频检查工具	`scripts/debug/test_*.gd`、`cheat_manager.gd`
工程流程	CI/CD、发布配置、燃尽图、文档治理	`.github/workflows/`、`README.md`、`AGENTS.md`、`docs/`

经验教训：

复杂功能不能只靠手工试玩验证：地图生成、敌人寻路、夜晚词缀必须有脚本测试和调试场景支撑。
内容系统应尽早数据化：波次、事件、词缀、遗物和剧情都改为 JSON 后，新增内容成本明显下降。
UI 是玩法的一部分：如果词缀、出怪口、盟约、遗物来源没有清晰展示，玩家无法真正理解策略选择。
跨模块协作要有边界：项目通过 DataRepo、RunState、EventBus、各类 Manager 和 UI Controller 减少模块互相直接改状态。

相比 Alpha 阶段，Beta 阶段从“先做出功能”进化为“功能、数据、UI、测试、文档同步推进”。

4. 团队成员如何沟通和对接，有什么记录留存

一般通过微信群聊以及Github进行沟通，issue提出新的需求，pr review 审核提交代码质量及内容，docs 中对齐各个任务的需求及接口。

仓库内可验证的记录包括：

Git 提交历史：Beta 阶段共 240 个提交。
README：记录 Commit Message、分支、Issue、PR 和合并流程。
AGENTS.md：记录代码、UI、资产、Godot/GDScript 和验证规范。
docs 文档：记录架构、接口、数据表、UI 系统、资产生成提示词等。
GitHub Actions：保留 CI/CD、Windows/Web 导出、itch.io 发布和燃尽图生成流程。
scripts/debug/test_*.gd：保留测试和回归验证脚本。

5. 如何平衡时间、质量、资源，争取如期完成任务

团队的平衡策略可以概括为：

先保主循环：优先完成开局、白天运营、夜晚防守、Boss、结算和教程，使游戏从头到尾可玩。
高风险系统优先重构：地图生成和敌人寻路是风险最高部分，因此提前引入确定性种子、Flow Field 和批量测试。
内容通过数据表扩展：波次、事件、遗物、词缀、剧情都尽量用 JSON 配置，减少代码修改量。
UI 和资产批量生产：通过 UI 派生资产工具、尺寸扫描工具和美术提示词文档降低重复劳动。
持续修复体验问题：Beta 阶段有 59 个 fix 类型提交，说明团队在功能推进同时持续修复 UI、路线、教程、事件和数值显示问题。
自动化发布减少收尾风险：CI/CD 自动导出 Windows 和 Web 版本，减少临近截止时手工打包失败的风险。

6. 项目实际进展与燃尽图说明

燃尽图显示 Beta 阶段并不是一条理想下降线：

5 月 25 日至 5 月 28 日左右，实际剩余点数一度上升，说明团队在早期发现并加入了新任务，存在范围扩张。
5 月底到 6 月中旬，曲线长期高于理想线，且存在一定的上涨趋势，是因为大家提出了大量的待修改issue，但又处于计网和计网实验的考期准备中，完成速度慢于理想计划。
6 月 13 日至 6 月 16 日，考期结束后，大家集中精力完成，剩余点数快速下降，说明大量功能在后期集中集成和关闭。
曲线中间的上升和平台期没有被抹平，因此它较真实地反映了项目中期压力，而不是完全美化状态。

7. Beta 阶段成员角色、贡献分

成员	贡献分
刘笑晨	54
黎嘉旋	54
肖一涵	54
李延博	52
赵栩栩	51
于忠雨	50
初浩然	35

二、用户场景

1. 项目开发前目标、典型用户场景和预期功能

项目目标：开发一款 Roguelike 塔防游戏，让玩家在随机地图上完成探索、资源经营、阵容构筑和夜间防守。

典型目标用户：

喜欢塔防和单位部署策略的玩家。
喜欢 Roguelike 遗物、流派和随机事件的玩家。
喜欢在随机地图中规划路线、资源和防线的策略玩家。
第一次接触项目、需要教程引导的新玩家。

预期典型场景：

场景	用户目标	预期功能
新玩家入门	了解基本操作和游戏目标	主菜单、开场剧情、新手教程
白天运营	探索地图、采集资源、处理事件、购买干员	随机地图、事件点、资源点、商店
阵容构筑	形成长期成长路线	遗物、盟约、升星、出售、商店锁定
夜晚防守	根据出怪口和波次布置防线	夜晚预览、多波次、词缀、路线覆盖预览
Boss 挑战	阶段性检验防线强度	第 3/6/9 天 Boss 夜、Boss 音效和特效
复盘重开	根据结算结果优化下一局	结算界面、胜负反馈

2. 项目发布功能与发布位置

Beta 阶段发布了两个版本（Windows 下载版和 Web 可玩版）功能包括：

完整九天三幕流程。
地图生成、五出怪口、路线覆盖预览。
夜晚多波次、夜晚词缀、Boss 夜。
遗物、盟约、商店锁定、升星、出售。
随机事件地图化与事件插画。
开场剧情、新手教程、音频反馈。
主菜单、HUD、单位详情、遗物面板、事件面板、设置面板。

发布位置：

CI 配置中的 itch.io 发布目标为 cloudtide/hexavigil:web 和 cloudtide/hexavigil:windows。
项目已发布在 itch.io 平台：https://cloudtide.itch.io/hexavigil。
GitHub Actions 支持 Windows 和 Web 自动导出，main 分支推送时通过 Butler 发布。
Beta 阶段同时补充了 itch.io 页面背景、封面、banner、游戏图标等发布素材，使项目不再只是“能运行”，而是具备基本对外展示包装。

3. 发布后是否满足全部典型场景，剩下的为何没有满足

已基本满足：

新玩家可以通过教程进入游戏。
游戏具备从开局到结算的完整流程。
白天运营、夜晚防守、Boss 战和结算闭环已经形成。
随机事件、遗物、盟约、词缀和地图生成提供了重复游玩的变化。
Web 和 Windows 两种发布形式降低了试玩门槛。

尚未完全满足的原因：

平衡性还需要更多真实玩家长流程测试。
用户评论和评分数量不足，难以仅靠外部数据证明所有场景都被充分验证。

4. 发布后是否真正符合用户需求

从发布数据看，项目已经获得一定真实试玩：

截图显示 2026/06/10 至 2026/06/17 期间：

129 次 Views。
83 次 Browser Plays。
8 次 Downloads。

这说明项目确实被用户打开和试玩，Web 版本降低了试玩门槛。除此之外我们建立了用户测试群，部分玩家通过直接接收我们发送的游戏包进行游玩，并且大家在群里提出关于游戏的看法及建议。

综合整体的反馈信息，玩家给出的评价是

地图和事件变化明显，构筑路线丰富；
Boss 和音效有记忆点；
教程降低了上手门槛；
游戏玩法较Alpha阶段丰富很多，但总体难度也变大了。

三、用户日活

1. 发布时团队做了哪些努力推广项目

团队做出的推广与发布准备：

配置 Web 和 Windows 两种发布形式。
使用 itch.io 作为主要发布平台，并在页面中提供浏览器试玩和 Windows 下载。
新增游戏图标、itch 封面、页面背景、banner 和嵌入页背景。
录制游戏介绍视频，在朋友圈及微信群聊中进行推广。
打磨主菜单、结算界面和品牌展示。
使用 CI/CD 减少发布成本，使版本能够快速更新。
准备 Beta 展示文档和大量实机截图，如地图、UI、事件、Boss、教程、遗物、词缀等。
组织灰度测试，让用户先试玩版本，再根据反馈修复教程、UI、事件、路线预览等体验问题。

2. 日活跃用户量是否达到预先定义数量

根据web网页版统计，有 129 views、83 browser plays、8 downloads。同时加上测试用户群及其余方式（包括私信发送游戏包等），我们认为日活暂未达到预定义数量。

可能没有达到较高日活目标的原因：

推广范围主要集中在课程或同学圈层，触达用户有限。
Godot Web 游戏加载成本比普通网页应用更高。
Roguelike 塔防系统复杂，需要教程和说明，用户初次进入可能有学习成本。

3. 是否有用户在功能改进上反馈

发布版的游戏均已经过队内成员大量测试，保证了数值方面平衡及用户体验感等，因此无用户在功能改进方面进行反馈。

团队在发布前针对体验进行过多次改进：

增加部署卡组职业筛选。
增加路线预览快捷键。
增加设置面板中的建筑范围显示开关。
优化夜晚词缀、波次预览和 HUD 信息展示。
调整商店锁定、升星、遗物、盟约等构筑体验。
完善新手教程进入正式游戏的流程。

4. 是否有用户在 Bug 上反馈

发布版的游戏均已经过队内成员大量测试，因此无用户在 Bug 方面进行反馈。

团队在发布前针对Bug进行过多次改进：

Bug 类型	代表问题
路线与寻路	敌人左右摇摆、绕行失败、路线预览与实际移动不一致
UI 层级	弹窗、浮层、结果面板不可见，滚动条显示异常
事件流程	祭坛离开选项无响应、随机事件触发链路需要重构
教程流程	教程结束后进入正式游戏流程需要修正

四、特色功能

1. 项目的杀手级功能

HexaVigil 的杀手级功能是：随机地图探索 + Roguelike 构筑 + 多波次塔防防守。

它不是在固定地图中反复摆塔，而是让玩家在每一局中同时做以下决策：

探索随机生成的地图。
选择资源采集路线。
判断事件收益和风险。
围绕遗物与盟约构筑阵容。
根据动态出怪口和夜晚词缀调整防线。
在 Boss 夜检验构筑强度。

2. 与竞品相比最特色的功能展现

特色功能	展现方式	特色原因
地图化随机事件	事件点铺在地图上，玩家消耗行动力前往触发	将 Roguelike 事件与地图探索绑定，而非单纯弹窗
五出怪口 + 路线覆盖预览	每天启用不同出怪口，用不同颜色显示覆盖区域	提高防线规划难度，也提升信息可读性
盟约流派	干员组合触发羁绊式效果	将自走棋/构筑思路融入塔防部署
九天三幕	第 3、6、9 天形成 Boss 节点	让整局游戏有清晰阶段感和高潮
确定性程序化地图	同种子可复现，地貌自然变化	兼顾随机性和可调试性
Boss 音效与特效	奶龙、凑凑企鹅具备专属 BGM、语音、特效	强化阶段战斗记忆点

3. 竞品为什么没有囊括该特色功能，团队凭什么实现

竞品没有同时囊括这些功能，可能有以下原因：

固定关卡塔防更容易做平衡，随机地图会显著增加路线、敌人、资源和 UI 预览的复杂度。
Roguelike 构筑与塔防部署结合后，数值平衡难度更高。
地图化事件需要同时考虑地图交互、行动力、事件结算和 UI 呈现，开发成本高于弹窗事件。
多出怪口和路线覆盖预览需要稳定寻路系统支撑，否则预览和实际行为容易不一致。

团队能够实现这些特色，主要依靠：

数据驱动配置表，降低新增波次、事件、词缀和遗物成本。
Flow Field 寻路和确定性地图生成，支撑动态路线和可复现调试。
UI 资产和工具链，使大量信息能被清晰呈现。
headless 测试和 CombatSandbox，降低复杂系统联调风险。
CI/CD 和文档治理，保证多人并行后仍能发布稳定版本。

4. 团队成员自我评价

团队自评：Beta 阶段基本达到预期目标。

达成之处：

游戏已经具备完整九天三幕流程。
核心玩法从 Alpha 原型升级为可完整游玩的 Roguelike 塔防。
随机事件、遗物、盟约、词缀、地图生成和 Boss 战形成了较高变化度。
UI、音频、剧情和教程补齐了展示与上手体验。
CI/CD、测试脚本、文档和调试工具提升了工程质量。

不足之处：

外部用户反馈和日活数据有一定不足，主要是测试时间较短。
平衡性仍需更多真实用户长流程试玩。

5. 用户对特色功能的评价

"作为第一次接触 HexaVigil 的玩家，我觉得这款游戏完成度比预期高很多。它不是简单的塔防摆放，而是把探索、资源运营、随机事件、遗物构筑和夜间防守结合在一起，每一天都有新的决策点。尤其是白天规划、夜晚检验成果的循环，很容易让人产生“再玩一天”的动力。"
"最有意思的是随机地图和路线预览。每局地图都不一样，出怪口和地形变化会影响防线布置，不像普通塔防那样只是在固定路线旁边摆单位。路线覆盖预览也很直观，让我能提前判断敌人会从哪里来，防守时更有策略感。"
“遗物、盟约和商店系统让我感觉游戏有明显的 Roguelike 构筑乐趣。每晚结束后的三选一奖励很有期待感，商店锁定和定向升星也让我能围绕喜欢的干员慢慢成型。玩到中后期时，能明显感觉自己的阵容是“养出来的”，这一点很有成就感。”

五、软件工程质量

1. 项目是否有完善文档，是否约定代码规范

项目有完善文档，并且约定代码规范。

项目文档较完整：

README.md：文档入口、Git 协作规范、分支规范、Issue/PR 流程。
AGENTS.md：仓库工作原则、Git 工作流、Godot/GDScript 规范、UI 与资产规范、验证命令。
docs/ARCHITECTURE.md：项目架构、运行结构、模块划分。
docs/INTERFACE.md：公开方法、EventBus 信号、UI 请求接口。
docs/DATA_SCHEMA.md：JSON 数据表结构。
docs/UI_SYSTEM.md：UI 层级、HUD 结构、样式系统。
docs/*_ASSET_GENERATION_PROMPTS.md：UI、地图、角色、事件、特效等资产生成规范。

代码规范包括：

UI 不直接修改玩法状态，通过 Manager 或 Controller 发出请求。
跨模块通知优先使用 EventBus 或现有 Manager 接口。
JSON 只保存静态配置，不写入运行时状态。
GDScript 避免依赖 Variant 推断，必要时显式标注类型。
场景路径不散落在数据表中，使用 scene_key 由 DataRepo 映射。

2. 是否存在代码混乱、无注释、无文档问题，新同学能否接手

项目规模较大，仍然存在复杂模块，例如地图生成、敌人寻路、HUD、事件系统等。但 Beta 阶段已经通过模块拆分、文档治理和测试脚本降低了接手难度。

新同学接手路径：

阅读 README.md，了解仓库结构、分支和 PR 流程。
阅读 AGENTS.md，了解编码、UI、资产和验证规范。
阅读 docs/ARCHITECTURE.md，理解运行结构和模块职责。
阅读 docs/DATA_SCHEMA.md，理解 data/ 配置表。
阅读 docs/UI_SYSTEM.md，理解 UI 分层与资产接入。
安装 Godot 4.6.2，拉取项目和 LFS 资源，打开 project.godot。
运行主场景或 scenes/debug/CombatSandbox.tscn。
修改脚本后运行对应 headless 检查或 scripts/debug/test_*.gd。

因此，新同学不会完全无从下手：README 提供入口，AGENTS.md 规定协作和验证规范，docs/ 解释架构、接口、数据表和 UI 系统，scripts/debug 提供可运行的测试与复现场景。

仍需承认的是，Godot 项目依赖引擎版本、导入缓存和资源文件；新同学若第一次接手，仍需要按照 README 与 CI 中的 Godot 版本准备环境。

3. 是否有单元测试、测试用例数目、代码覆盖率

项目已有 23 个 test_*.gd 测试脚本，列举部分如下：

test_bonus_blessing_flow.gd
test_cheat_panel.gd
test_contract_events.gd
test_dialog_engine.gd
test_enemy_blocked_projectile_attack.gd
test_flow_field.gd
test_highland_platform.gd

测试覆盖内容：

地图生成和地形规则。
Flow Field 寻路。
出怪口与夜晚波次。
夜晚词缀。
遗物抽取。
随机事件和契约。
商店锁定。
定向升星。
教程流程。
UI 可见性。
关键音效。

代码覆盖率：测试代码主要覆盖游戏的核心机制部分，其余 UI 及普通构筑等部分并未涉及，因为游戏这方面内容主要依赖手动测试与调试。

4. 是否采用 CI/CD 等软件工程工具，并说明理由

项目采用了 CI/CD：

.github/workflows/godot-ci.yml：自动导出 Windows 和 Web 版本。
PR 和 push 到 dev / main 会触发构建。
构建产物上传为 GitHub Actions artifact。
main 分支推送时通过 Butler 发布到 itch.io。
.github/workflows/update-beta-burndown.yml：自动生成 Beta 燃尽图。

采用 CI/CD 的理由：

Godot 项目容易出现本地可运行、他人机器不可运行的问题，CI 可以提前暴露构建失败。
Windows 和 Web 双平台手工打包成本高，自动化可以降低发布风险。
itch.io 发布流程自动化后，团队可以更频繁地发布可试玩版本。
燃尽图自动生成可以减少人工维护项目进度图的成本。

5. Beta 阶段学到的经验和教训

团队在 Beta 阶段获得的经验：

软件工程不是只写功能：测试、文档、发布、反馈和协作流程同样决定项目能不能交付。
数据驱动能显著提升内容迭代效率：波次、事件、词缀、遗物和剧情配置化后，内容扩展更快更安全。
复杂系统必须可复现：地图和寻路问题必须依靠固定种子、批量测试和调试工具，否则很难定位。
UI 信息设计直接影响玩法质量：策略游戏必须让玩家看懂状态、风险和收益。
燃尽图能暴露项目风险：Beta 燃尽图中的上升和平台期说明任务范围和完成速度确实存在压力。
CI/CD 减少最后阶段不确定性：自动构建和发布可以把“能不能打包”从截止日前移到日常开发中验证。
贡献需要可量化记录：提交记录、Issue、PR、测试脚本、文档和用户反馈都应被保存，否则复盘时难以公平评估。

posted @ 2026-06-16 01:05 Fruit_Inc 阅读(9) 评论(0) 收藏举报

刷新页面返回顶部

FruitInc