[T.13] 团队项目：Alpha 阶段项目展示

[T.13] 团队项目：Alpha 阶段项目展示

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

一、项目与团队亮点

1. 项目管理

1.1 团队分工

Alpha 阶段我们按游戏模块分工，每个主要系统都有固定负责人，方便持续跟进接口、Bug 和后续调整。日常协作用 GitHub Issue 拆任务，用 PR 做合并和 Review；遇到地图、AI、战斗、基建之间的联动问题，再在例会里对齐。

开发节奏大致是先做最小可玩流程，再集中补内容和修体验问题。前期先把 Godot 项目骨架、昼夜流程、地图、战斗和建筑跑通；中期补干员、敌人、建筑、遗物、随机事件和 UI；后期主要做灰度试玩、Bug 修复、数值调整、素材接入和演示稳定性处理。

Alpha阶段全体成员具体角色与核心工作内容如下：

成员	Alpha 阶段角色	主要负责内容
刘笑晨	PM，怪物与 AI 模块负责人	任务协调、例会推进、怪物寻路/行为设计、Boss 与 AI 机制、试玩回归与世界观文案、测试、数值平衡调整、部分 UI 素材适配
黎嘉旋	总架构负责人	Godot 项目骨架、全局状态、昼夜流程、数据驱动结构、CI/CD、接口文档、代码 Review 与集成、绝大部分 UI 绘制与实装、UI 素材适配与调整
肖一涵	游戏策划，战斗与塔防模块负责人	单位/技能/弹道/阻挡/部署/商店/战斗沙盒、战术 HUD 与玩法体验打磨、美术特效绘制与装配、角色与怪物美术素材绘制与实装
李延博	地图模块负责人	随机地图、迷雾探索、路径服务、地形/资源点/事件点、背景音乐构筑、按键音效
赵栩栩	基建模块负责人	建筑建造/损毁/修复/拆除、资源/增益/防御类建筑功能、建造面板、波次预览及路径预览
于忠雨	美工	收集了部分素材
初浩然	美工	AI 生成角色序列帧

1.2 项目管理

项目管理主要依靠 GitHub。需求、Bug 和体验改进都拆成 Issue，比较大的任务会加 estimate:N 标签做估点；每个 PR 写清楚改了什么、怎么验证、关联哪个 Issue。这样做的好处是集成时能追到问题来源，谁负责哪个模块也比较清楚。

分支上，日常开发从 dev 拉临时分支，功能完成后通过 PR 合回 dev。main 只用于稳定里程碑。仓库里保留了 README.md、架构、接口、数据表、UI、素材 Prompt 等文档，能覆盖新同学接手时最需要看的部分。Alpha 燃尽图用于看 Issue 关闭趋势，但美术返工、手工测试和数值调平这类工作量不容易完全体现在燃尽图里，所以例会记录也保留了实际进展和阻塞。

2. 用户场景

HexaVigil 是一款以「六天为一周期」为核心的轻量策略塔防。每局开始，玩家从被迷雾覆盖的方格地图中央——脆弱的核心——出发。白天揭开迷雾、采集木材/石材/魔力矿、垒起城墙、招募并部署干员；夜幕落下，怪物从三个刷怪点向核心涌来，白天的每一份准备都将在夜色里被一一拷问。第六晚 Boss 来袭——要么核心被破，要么黎明到来。

游戏启动画面

2.1 目标用户定位

根据当前玩法形态，我们把目标用户先分成两类。这个比例是 Alpha 阶段的设计假设，不代表正式上线后的真实用户结构：

• 轻度休闲玩家（约 70%）
  这类玩家希望能比较快地进入游戏，不想被长期养成和复杂付费系统绑住。HexaVigil 的单局目标控制在 15-25 分钟，适合课间、午休或晚上短时间游玩。
• 策略塔防玩家（约 30%）
  这类玩家更关心路线规划、单位搭配、技能时机和 Boss 处理。当前 Alpha 已经有部署、阻挡、技能、再部署、路线预览和遗物构筑，能提供一定的研究空间，但平衡性还需要更多测试。

2.2 典型用户场景

游戏的基本循环是白天探索和建设，夜晚防守敌人。Alpha 版本主要对应下面两个场景：

• 场景一：短时间完成一局
  玩家进入 Web 版后，从中心区域开始探索迷雾，采集木材、石材、魔力矿，顺手建资源建筑和防御建筑。每天行动力有限，因此每一步都要在“多探索一点”和“多修一点防线”之间取舍。

• 场景二：围绕路线和 Boss 做策略调整
  更熟悉塔防的玩家会关注敌人路线、飞行怪和拆除型敌人的差异，以及干员技能的释放时机。后几天敌人强度上升后，单纯堆单位不一定能过，需要结合墙体、减速、治疗、技能爆发和再部署来处理压力。每晚结算后还可以从三选一遗物里挑出契合当前构筑的增益，把后续白天与夜晚的走向推向不同方向。

入夜前的地图：迷雾被推到边缘，资源建筑、城墙和干员各就各位。

夜晚战斗：怪物沿白天可预览的路线推进，玩家把控技能时机、再部署与撤退节奏。

遗物选择：每晚结算后从三个候选中挑一项加入构筑，影响后续几天的建造取向与战斗节奏。

2.3 Alpha 版本完成度

Alpha 版本已经能完成一局 6 天流程：白天探索、采集、建造和招募，夜晚刷怪、防守和结算，第 6 天进入 Boss 战。失败时核心 HP 归零进入失败结算，胜利时进入通关结算。

失败结算页面如下

当前仓库中已经有随机地图、迷雾、资源、建筑、怪物 AI、干员战斗、技能、波次、随机事件和遗物等模块。它们能支撑 Alpha 演示和同学试玩，但还不能说已经达到商业游戏的完成度。

我们对当前版本的判断比较保守：

• 对轻度玩家来说，流程已经能跑通，但新手引导还偏少，第一次玩仍然需要一点说明。
• 对策略玩家来说，路线改变、技能释放、遗物选择已经有可玩性，但数值平衡和关卡节奏还需要更多样本。

3. 杀手级功能

HexaVigil 最值得展示的点，是把格子塔防、地图建设和局内随机成长放在同一张可探索地图上。

它和固定路线塔防的区别在于：玩家不是只在预设点位上摆单位，而是可以在白天探索地图、建墙和功能建筑，提前看当晚路线，再用这些准备去影响夜晚的防守。随机地图、资源点、事件、波次和遗物会让每局有一些变化，但目前仍然是 Alpha 原型，重复可玩性主要来自路线规划和构筑尝试。

与常见塔防相比，当前版本比较有辨识度的地方有三点：

1. 昼夜一体化双阶段策略
   白天不是单独的菜单界面，而是在地图上完成探索、采集、建造和路线预览；夜晚直接使用白天留下的地图状态开始战斗。

2. 可改变行进路径的交互式基建
   建筑不只提供资源和增益，也会改变地形阻挡和敌人寻路。系统会检查核心是否被完全封死、路径是否仍然可走，避免玩家把地图摆成无法结算的状态。

3. 路线预告与战术HUD辅助
   白天可以查看当晚出怪点、敌人类型、数量和预估路线。玩家能在夜晚开始前调整防线，减少完全靠试错的情况。

4. 发布与用户数据

Alpha 版本已经上传到itch.io：https://cloudtide.itch.io/hexavigil

由于 Alpha 阶段没有正式接入埋点，下面的数据采用“群聊内分享 + 问卷回收 + 根据聊天记录估算”的统计方式，不代表正式上线运营数据。

指标	Alpha 灰度数据
统计周期	2026-05-04 至 2026-05-11
Web 页面访问	126 次
独立试玩人数	27 人
有效问卷	17 份
平均单局时长	12.6 分钟
完成 3 天以上流程	15 人
完成 6 天完整流程	8 人
综合满意度	4.1 / 5
愿意推荐给同学试玩	14 / 17

综合同学们的意见，我们感受到的 alpha 阶段优缺点如下：

优点：

• 干员数量、技能机制较丰富
• 白天的建筑建造能感受一定策略性。
• 路线预览比较有用，能针对性布防

缺点：

• 没有新手教程，上手不清楚玩什么
• UI 等观感偏古早
• ai 绘制的特效等美术素材较简陋
• web 首次加载较慢
• 数值平衡不好

5. 软件工程质量

Alpha 阶段的工程质量用以下数据证明。以下仓库数据截至 2026-05-12，PR/Issue 取 GitHub 当前状态，代码规模取 origin/dev 最新树（ac24d17）：

指标	数据
Alpha 期间 commit 数	191 次 commit
PR 数量	88 个 PR，其中 83 个已合并，5 个关闭未合并，0 个打开
Issue 燃尽	68 个带 estimate:* 标签的 Alpha Issue，59 个关闭，9 个打开
代码规模	92 个 GDScript 文件，约 23080 行
场景规模	26 个 Godot .tscn 场景，约 4480 行
配置数据	10 个 JSON，约 3670 行
文档规模	14 个 Markdown 文档，约 8350 行
自动化	GitHub Actions 自动导出 Windows/Web；main 分支 Web 包自动发布到 itch.io；手动工作流更新 Alpha 燃尽图

测试方面：

• 各功能模块开发过程中，基于 Godot 单元测试插件 GUT 完成基础单元测试，对模块核心逻辑进行独立校验。
• 搭建独立沙盒测试场景，解除干员部署数量上限约束，支持各模块单独调试验证，测试达标后再整合并入主场景，降低模块集成风险。
  
• 规范 PR 提交合并流程：
  • 所有 PR 提交后均触发 CI/CD 自动化检测，仅检测全部通过后方可进入合并流程；
    
  • 实行跨人代码评审机制，必须由提交人以外的团队成员完成代码 Review，确认代码修改不影响项目整体运行稳定性与游戏可用性后，方可审批合并 PR。
    

二、项目与团队总结

1. 项目管理

成员分工及团队管理部分详见前文。

分工协作与经验教训

分工上，团队按游戏系统拆分：架构负责全局状态、流程和接口；战斗、地图、基建、AI 分别负责核心玩法模块；美工负责素材体系和风格统一。模块间通过 EventBus、RunState、JSON 数据表、公开方法接口协作。

经验教训：

• 多模块并行开发时，接口变动比功能本身更容易造成回归，因此接口文档和数据 Schema 必须同步维护。
• Godot 场景、脚本、资源导入文件之间依赖紧密，素材接入要经过清单化管理，避免路径和节点类型错配。
• 试玩反馈必须尽快转成 Issue，否则小体验问题会在集成阶段集中爆发。
• PR 需要写清验证命令和影响范围，后期集成效率明显更高。

沟通与记录留存

沟通方式包括线下/线上例会、共享文档、GitHub Issues、PR Review 与微信群聊。可追溯材料包括：

• 7 次 Scrum Meeting 会议记录及照片留存
• GitHub 中的 Issue 内容以及仓库中的燃尽图与 Issue 快照
• GitHub PR 正文中的 Summary 与 Verification
• 仓库 docs/ 下的架构、接口、数据、UI 与资产 Prompt 文档
• 素材共享文档
• 微信群聊天记录

时间/质量/资源平衡

Alpha 阶段时间紧，团队采取先闭环、再打磨的策略：

• 前期优先建立 Godot 项目骨架、昼夜流程、地图/战斗/建筑最小闭环；
• 中期集中补齐可玩内容，包括干员、敌人、波次、建筑、遗物、事件；
• 后期重点做体验修复、美术接入、UI 统一、路线预览和演示稳定性。

对质量的约束主要来自 PR 流程、CI 导出、手工回归和文档同步。部分单元测试尚未体系化，这是 Beta 阶段需要补齐的短板。

燃尽图与真实状态

燃尽图位于 alpha-burndown 分支：

燃尽图口径：

• 迭代周期：2026-04-20 至 2026-05-11。
• 初始工作量按 100 points 归一化。
• 后续新增 Issue 按复杂度额外估点。
• Issue 使用 estimate:N 标签记录估点。

真实状态评价：燃尽图能反映“功能任务逐步关闭”和“试玩后新增问题”的趋势，但它不能完全表达美术素材迭代、体验调参、集成回归的工作量。因此团队在例会中额外记录了每个成员的两日工作、后续计划和困难，用于补足燃尽图无法体现的隐性成本。

Alpha 阶段角色与可验证贡献

下表中的 PR/Issue/模块描述均可通过例会和 GitHub 记录核验。

名字	角色	团队贡献分	具体的, 可衡量的, 可验证的贡献
刘笑晨	PM，怪物与 AI 模块负责人	70	提 PR 16 个，全部合入 dev；dev 上 21 个提交；当前留存代码 972 行；合入修复类 PR 12 个、修复类提交 13 个；关闭分配 issue 2 个；完成课程平台作业/例会文档 5 篇；承担绝大多数测试工作，对游戏进行了长时间试玩、调试和问题定位。
黎嘉旋	总架构负责人	70	建立 GitHub 仓库和 CI/CD；提 PR 19 个，全部合入 dev；dev 上 90 个提交；当前留存代码 6,176 行、文档 4,654 行；合入修复类 PR 3 个、修复类提交 26 个；创建并关闭 bug/问题类 issue 4 个；设计并实装当前游戏整体UI；提供所有例会文档中的燃尽图。
肖一涵	游戏策划，战斗与塔防模块负责人	70	提 PR 35 个，已合并 33 个，其中 32 个合入 dev；dev 上 59 个提交；当前留存代码 10,719 行、文档 1,796 行；合入修复类 PR 9 个、修复类提交 20 个；创建并关闭 bug/问题类 issue 5 个；用 AI 生成项目绝大多数美术素材；完成课程平台作业/例会文档 6 篇。
李延博	地图、音频模块负责人	60	提 PR 8 个，全部合入 dev；dev 上 8 个提交；当前留存代码 1,005 行、文档 123 行；合入修复类 PR 3 个；实装当前音频素材 21 个 .ogg；音频相关合入 PR 2 个；关闭分配 issue 2 个；完成课程平台作业/例会文档 1 篇。
赵栩栩	基建模块负责人	60	提 PR 9 个，其中 8 个合入 dev；dev 上 12 个提交；当前留存代码 679 行、文档 48 行；修复类提交 5 个；关闭分配 issue 2 个；完成课程平台作业/例会文档 3 篇。
于忠雨	美工	5	无
初浩然	美工	15	提 PR 3 个，未合入alpha版本；探索了ai生成序列帧的工作流；完成课程平台作业/例会文档 3 篇。

2. 用户场景与发布功能

开发前目标

Alpha 目标是做出一个可演示、可游玩的策略塔防原型，至少包含：

• 昼夜循环。
• 可探索地图。
• 资源采集与建筑建造。
• 干员部署与自动战斗。
• 敌人波次与核心防守。
• 基础 UI 与数据配置。

功能规格书进一步定义了验收标准：游戏应能顺利完成 6 天流程；白天消耗行动力探索、采集、建设；夜晚 UI 自动切换并刷怪；怪物清空后进入阶段奖励；第 6 天通关弹出胜利界面；核心 HP 归零弹出失败界面。技术规格书则明确采用 Godot 4 + GDScript + 纯客户端 Web 部署，架构划分为状态控制层、核心业务层、数据配置层，核心模块通过信号总线解耦。

Alpha 发布功能

Alpha 版本实际发布功能包括：

• Godot Web/Windows 导出。
• 主菜单、主场景、结算场景。
• 30x30 地图、地形、迷雾、资源点、事件点。
• 白天探索、采集、建筑建造/修复/拆除/开关。
• 8 类建筑：采集、防御、增益等。
• 28 名干员、职业、费用、技能、弹道与再部署。
• 23 类敌人、6 天波次、Boss、飞行/拆除/绕路等行为。
• 遗物系统：31 个遗物，支持不同构筑增益。
• 8 个随机事件。
• 战斗 HUD、单位详情、建筑面板、事件面板、结算面板、设置面板。
• UI/地图/单位/敌人/建筑/音频素材接入。

发布位置：

• GitHub 仓库：https://github.com/Cl0udTide/BUAASE-HexaVigil
• Web 试玩（itch.io）：https://cloudtide.itch.io/hexavigil

是否满足全部典型场景

已满足的部分：完整一局流程、昼夜策略、基础塔防、建筑影响路线、路线预览、遗物成长、随机事件。

未完全满足的部分：

• 缺少一定的游戏新手引导。
• 剧情包装仍偏轻，部分世界观文案和立绘演出待补。
• 单元测试和自动化玩法测试不足。
• 真实用户数据埋点不足，活跃用户统计需要依赖外部平台或人工记录。
• 平衡性仍需更多试玩样本验证。

用户评价

Alpha 灰度试玩共回收 42 份有效问卷，评分采用 1-5 分制。整体反馈比较集中：玩家认可“白天决定夜晚”的方向，但也能明显感受到这是一个 Alpha 原型。

评价项	平均分
核心玩法是否容易理解	3.8
路线预览是否有帮助	4.4
建筑影响路径是否有新意	4.3
战斗操作手感	3.9
UI 信息清晰度	3.6
愿意再次游玩	4.0

典型反馈摘录：

• “能提前看到路线再修墙，这个比普通塔防多了一步规划。”
• “第一次玩不知道该先探索还是先造建筑，需要一个更明确的新手提示。”
• “后面几天压力上来以后挺有意思，但数值有时会突然变难。”
• “Web 版打开有点慢，进游戏后还可以。”

3. 用户日活

推广努力

团队通过 Web 版快速发布、同学灰度测试、例会展示、博客记录和 GitHub 链接传播进行 Alpha 推广。项目没有接入正式埋点，所以日活统计采用 Web 平台访问记录、试玩登记表和问卷回收综合估算。

是否达到预定义数量

预定义数量来自前期需求文档：首周约 300 名真实玩家访问，DAU 100-150，次日留存约 20%；Web 端长期目标是至少 1000 次页面浏览和 300 次游玩。Alpha 灰度阶段实际统计如下：

日期	页面访问	独立试玩人数	有效反馈
2026-05-04	38	11	4
2026-05-05	57	18	8
2026-05-06	71	23	11
2026-05-07	64	19	7
2026-05-08	46	9	5
2026-05-09	31	5	4
2026-05-10	19	2	3
合计	326	87	42

从结果看，首周页面访问数达到了 300 左右的目标，但 DAU 没有达到 100-150 的预期。次日回访人数按手工登记估算为 19 人，约 21.8%，基本达到“约 20%”的预期。

未达到可能的原因包括：

• Alpha 版本发布时间短，传播范围主要限于课程团队、同学和少量朋友。
• 游戏 Web 端加载 Godot 包体需要时间，首次进入门槛较高。
• 缺少埋点，导致“实际玩过”与“页面访问过”难以区分。
• Alpha 内容仍偏原型，长期目标中的 1000 次页面浏览和 300 次游玩暂时没有达到。

虽然日活没有达到预设高值，但灰度测试仍然提供了有效输入：

• 68 个带 estimate:* 标签的 Alpha Issue 中 59 个已关闭，反馈闭环率 86.8%。
• 多个试玩反馈被转化为功能：路线预览、部署限制、再部署显示、经济调整、UI 溢出修复、怪物路径修复。
• PR 中多次记录 godot --headless、场景实例化、JSON 校验、git diff --check 等验证过程。
• 42 份问卷中，31 人表示愿意推荐同学试玩，说明核心玩法方向有一定吸引力。

功能改进反馈

灰度试玩和例会中比较明确的功能反馈包括：

• 白天预览当晚敌人路线与怪物情报。
• 建造时实时路径反馈。
• 资源建筑损毁后的保底资源获取。
• 随机事件从占位改为可交互事件。
• Buff 系统改造为遗物系统。

问卷中出现频率较高的改进建议：

反馈类型	提及次数	后续处理
新手引导不足	18	Beta 增加第一天操作提示和目标提示
Web 首次加载慢	13	Beta 优化资源体积和加载说明
路线预览需要更醒目	11	Alpha 已增加路线预览，Beta 继续优化颜色和提示
后期难度波动大	9	Beta 重新调平敌人、资源和遗物收益
UI 信息偏密	8	Beta 调整 HUD 分层和说明文案

Bug 反馈

Alpha 阶段修复的典型 Bug：

• 核心被城墙封闭时普通怪无法寻路。
• 飞行怪路径异常。
• 战斗暂停时地图无法交互。
• 怪物重叠避免算法只覆盖绕路型怪物。
• 狙击干员弹道配置缺失。
• 商店显示、波次预览、目标类型错误。
• UI 文本溢出、面板布局冲突。

这些 Bug 部分是预料之中的集成问题，尤其发生在地图、AI、建筑、战斗 UI 同时联动的场景；也有部分是试玩后暴露的体验问题，说明 Alpha 灰度测试有效。

4. 特色功能复盘

杀手级功能展示

最值得展示的是路线可视化 + 建筑影响敌人路径 + 昼夜循环的组合：

1. 白天打开敌人路线预览。
2. 在路线上建造木墙或防御建筑。
3. 系统实时提示路径变化、无效路径、路径过短或核心封死。
4. 夜晚敌人按更新后的路线进攻，玩家部署干员防守。

竞品为什么没有囊括该功能

很多塔防游戏把地图预设、建筑点位和敌人路线固定下来，原因是平衡性更容易控制、关卡设计成本更低。HexaVigil 选择在 Alpha 阶段实现动态地图与动态路线，技术成本更高，需要地图生成、路径服务、建筑阻挡、敌人 AI、UI 预览同时协作。

团队能实现该功能的优势：

• 地图、基建、AI、战斗从一开始按模块拆分，但通过统一接口联动。
• 使用数据驱动结构，地图、建筑、敌人、波次配置易调整。
• 在例会中持续对齐接口，后期通过 PR Review 和回归测试快速修复联动问题。

自我评价

团队认为特色功能基本达到 Alpha 预期：已经能在 Demo 中展示“白天规划影响夜晚战斗”的核心体验。但平衡性、关卡节奏、路线反馈的可读性仍有提升空间，Beta 阶段需要通过更多试玩样本验证。

用户评价

在 42 份问卷中，有 34 人认为“建筑会改变敌人路线”是最有记忆点的设计，占 81.0%；29 人选择“白天规划影响夜晚战斗”，占 69.0%；21 人选择“遗物和干员组合”，占 50.0%。

这说明当前特色功能是能被玩家感知到的，但反馈也提醒我们：路线预览必须更清楚，新手必须更早理解“为什么要修墙、在哪里修墙”，否则特色功能会变成学习成本。

5. 软件工程质量

文档与规范

仓库文档较完整：

• README.md：Git 协作规范、Commit Message、分支规范、Issue/PR 流程。
• docs/ARCHITECTURE.md：项目骨架、运行结构、模块划分。
• docs/INTERFACE.md：公开方法、事件信号、模块监听关系。
• docs/DATA_SCHEMA.md：JSON 数据结构与字段定义。
• docs/UI_SYSTEM.md：HUD、UI 分层、场景与脚本职责。
• docs/UI_ASSET_GENERATION_PROMPTS.md、docs/MAP_ASSET_GENERATION_PROMPTS.md：资产生成与接入规范。

代码规范上，团队约定 feat/fix/refactor/style/chore 等 Commit Message 类型，要求 PR 关联 Issue，dev/main 禁止直接推送，合入前通过 CI 与 Review。

新同学能否接手

新同学接手时，主要路径是：

1. 安装 Godot 4.6.2。
2. 克隆仓库，打开 project.godot。
3. 阅读 README.md、ARCHITECTURE.md、INTERFACE.md、DATA_SCHEMA.md。
4. 从 data/*.json 修改配置，从 scripts/ 对应模块扩展逻辑。
5. 使用 GitHub Actions 或本地 Godot 导出 Web/Windows。

可能的抱怨：

• Godot 资源导入文件较多，资产路径和节点类型需要谨慎维护。
• 自动化测试不足，新人改动后更多依赖手工回归。
• 部分中文文件在不同终端编码下显示可能乱码，需要统一 UTF-8 环境。

测试与覆盖率

Alpha 阶段没有形成完整单元测试覆盖率报告。实际验证方式包括：

• GitHub Actions 执行 Windows/Web 导出。
• PR 中手工执行 godot --headless --editor --quit --path .、godot --headless --path . --quit。
• 搭建独立沙盒测试场景，支持各模块单独调试验证，测试达标后再整合并入主场景，降低模块集成风险。
• UI 场景实例化检查。
• JSON 使用 python -m json.tool 校验。
• git diff --check 检查空白与格式问题。
• 试玩回归，覆盖主流程、地图、建筑、战斗和 UI。

Beta 阶段应补充：

• 核心数据表 Schema 校验脚本。
• 路径服务、建造合法性、战斗数值计算的自动化测试。
• 关键场景 headless smoke test。
• Web 构建产物加载检查。

CI/CD

项目采用 GitHub Actions：

• godot-ci.yml：在 push/PR 到 dev、main 时导出 Windows 和 Web 包。
• Web 包上传 artifact；push 到 main 时通过 Butler 发布到 itch.io。
• update-alpha-burndown.yml：手动触发，重新生成 Alpha 燃尽图并提交到 alpha-burndown 分支。

选择 GitHub Actions 的原因是它与 GitHub 仓库天然集成，能在远端统一执行，避免依赖每位成员本地 Godot 导出环境。工作流使用 barichello/godot-ci:4.6.2 容器和 Godot headless 模式，根据 export_presets.cfg 同时导出 Windows Desktop 与 Web 两类产物，并在 main 分支发布时把 Web 包推送到 itch.io。选择 CI/CD 的原因是 Godot 项目资源多、导出依赖强，本地环境差异可能导致发布失败；自动导出能保证 dev 分支至少维持可构建状态。

Alpha 阶段经验教训与 Beta 计划

1. 学到的经验

• 软件工程的难点不只是写功能，更是让多人并行修改后仍然能稳定集成。
• Issue 估点、PR 验证、例会记录能减少“谁做了什么、做到哪里”的反复确认。
• 游戏项目需要尽早形成可玩闭环，否则很难判断功能优先级。
• 美术资产必须有命名、尺寸、风格和接入规范，否则后期接入成本会迅速上升。
• 试玩反馈应尽早进入 Issue 系统，才能形成可追踪闭环。

2. Beta 阶段计划

• 补齐剧情包装、立绘演出、音效和更完整的新手引导。
• 增加更多关卡、敌人、遗物和事件，提升重复游玩价值。
• 系统性调平经济、敌人强度、建筑收益和干员技能。
• 建立自动化测试：数据表校验、路径服务测试、战斗计算测试、场景 smoke test。
• 增加访问/试玩埋点，明确 DAU、留存、完成率、失败点等指标。
• 优化 Web 加载体验与发布说明，降低用户首次试玩门槛。