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

项目	内容
这个作业属于哪个课程	BUAA_SE_2026_LR
这个作业的要求在哪里	作业要求链接
课程目标	系统性的学习软件工程的知识，逐步成为一个成熟的软件开发者，与团队、结对成员一起协作完成软件开发，共同成长进步。
作业价值	完成alpha阶段项目产品展示

项目与团队亮点

团队成员与分工简介

姓名	角色	负责内容
孙琦航	PM	负责整体进度、前后端集成、构建部署与最终封板。
赵骥远	玩法设计 / 代码开发	负责搜打撤规则、黑市经济、资源刷新和职业数值设计，代码开发
吴震宏	地图美术 / 开发	负责地图美术设计、碰撞层、建筑门点和资源点配置，代码开发
徐琬莹	角色美术A	负责第一批角色基础动作、普攻特效等美术
刘舒童	角色美术B	负责第二批角色基础动作、普攻特效等美术
朱城宇	测试	负责多人联调、核心流程测试、异常测试和回归验证。

项目管理

GitHub 管理：项目代码统一托管在 GitHub 仓库中，通过分支、Pull Request、提交记录和 GitHub Actions 工作流进行团队协作、版本管理与自动化部署。

利用飞书进行进度和分工管理，定期例会同步开发进度。

项目的典型用户场景，以及最终的软件如何满足该场景

目标用户与核心需求

本项目面向的是年轻玩家和中度游戏爱好者，尤其是喜欢 PVP、搜打撤、射击或 MOBA 的校园玩家，以及希望在宿舍、班级或社群中快速组局的熟人玩家。我们在选题阶段访谈了 5 名同学，其中 4 名同学有三角洲等搜打撤游戏经验；他们普遍认可“三局流转 + 丢包撤离低保 + 链接组队”的设计，认为它能降低传统撤离游戏“一死全输”的挫败感，也更适合课堂、宿舍和课后碎片时间。

用户类型	典型特征	主要需求	项目对应功能
核心竞技玩家	熟悉 PVP、搜打撤或射击游戏，愿意学习机制	短时间内获得战斗、搜刮、撤离和翻盘体验	五职业、黑市道具、地图资源、战斗与撤离结算
熟人组局玩家	宿舍、班级、社群中的组织者和跟局者	不安装客户端，发链接即可一起玩	Web 端访问、创建房间、邀请链接、房间准备
轻度尝鲜玩家	不一定熟悉搜打撤，但愿意试玩网页游戏	规则清楚，失败代价不要过重	三局制、丢包撤离、黑市补给、结算反馈

项目发布后，Alpha 版本已经满足了最核心的典型场景：玩家可以从大厅进入黑市，再进入战场，完成搜索、战斗、撤离和最终排名。剩余不足主要是新手引导仍然不够强，第一次进入战场的玩家可能不知道优先去搜宝箱、观察撤离点还是规避交战；这部分已经列入 Beta 阶段优化。

1. 熟人组局：从一个房间开始

玩家打开网页后，先进入大厅创建或加入队伍。队长可以选择地图、复制分享码并开始游戏，队员则在这里确认职业、昵称和准备状态。注意宝石数量是游戏排名的唯一标准！会随着游戏三轮进行而增减。

这个场景主要解决“多人网页游戏如何快速开局”的问题。房主创建房间后，把邀请链接发到微信群或宿舍群，其他玩家点击链接进入同一房间；所有人确认昵称和职业后，房主推进到黑市阶段。对熟人组局玩家来说，关键不是复杂账号系统，而是少等待、少配置、尽快进入游戏。

2. 黑市补给：出发前的选择

进入战局前，玩家会来到黑市补给阶段。这里不是单纯等待开局，而是要根据职业和队伍需求购买护盾、治疗、加速等道具，并决定是否扩充背包。这都需要花费宝石！

这个场景来自功能规格中定义的“局间黑市”阶段。玩家上一局带出的宝石会转化为下一局的资源优势，可以购买治疗、护盾、加速、战斗增益、门禁卡等道具，也可以扩充背包容量。它让每一局不是孤立的战斗，而是会影响后续策略的连续博弈：领先玩家要考虑如何扩大优势，落后玩家也可以通过保守购买和低风险路线重新追赶。

3. 进入战场：搜打撤

准备完成后，游戏切换到像素地图场景。玩家可以通过小地图观察资源点和撤离点，在倒计时压力下寻找路线、靠近宝箱并规避危险区域。

典型任务是：玩家出生后先判断自己所在位置、附近建筑和资源点，再决定走外圈低风险路线，还是进入中庭和建筑内部争夺高价值资源。当前地图包含建筑、楼层、草丛、荆棘、门、传送门、宝箱和撤离点，能够支撑绕行、埋伏、抢点和撤离路线规划。核心竞技玩家会在这里得到主要的决策乐趣。

4. 搜索资源：打开宝箱并整理背包

当玩家靠近资源点时，可以打开宝箱查看战利品。系统提供宝石、道具和背包容量提示，玩家需要判断哪些资源值得带走。

宝箱场景对应搜打撤玩法中的“收益来源”。玩家可能拿到宝石、治疗包、战术道具或门禁卡，但背包容量有限，不能无限携带。此时用户要做取舍：是拿即时保命道具，还是带高价值物资撤离；是继续搜下一个箱子，还是赶紧离开危险区域。这个机制让资源不只是奖励，而是会持续改变玩家路线和风险偏好的决策点。

5. 遭遇战斗：搜索之外的风险

在搜索宝箱过程中，当然会遇到紧张刺激的与其他玩家正面遭遇战。角色可以使用普通攻击和职业技能进行对抗，战斗结果会影响后续撤离与本局收益。

项目提供刺客、射手、坦克、战士、法师五个职业。刺客适合近身爆发，射手适合远程压制，坦克适合承伤和卡点，战士适合稳定近战，法师适合中程范围压制。战斗不是单纯击杀对手，而是服务于搜打撤目标：抢宝箱、保护收益、逼退对手、拖延撤离或为队友创造空间。

6. 撤离抉择：带走收益还是止损保命

一局游戏的关键不只是拿到资源，而是能不能带出去。项目提供常规撤离和丢包撤离两类路径：常规撤离可以保留收益，但需要等待撤离点开放并承担被埋伏风险；丢包撤离更像低保机制，可以更早保命，但要放弃背包和本局收益。

典型场景是：一名玩家已经搜到较多宝石，但血量较低，常规撤离点附近可能有其他玩家埋伏。此时他需要判断是继续赌常规撤离，还是去丢包撤离点止损。这个场景直接回应了选题阶段用户对传统撤离游戏“单局全损挫败感强”的痛点。

7. 地图设计

游戏整体采用2.5D视角，整体废土地牢风设计。地图设计丰富有层次感。计划有多种作战地图供玩家选择

当前 Alpha 版本重点打磨第一张完整可玩地图。地图中心资源价值更高、冲突也更集中；外围路线相对安全，适合新手或保守玩家；建筑和楼层提供搜索深度，门禁卡、草丛和障碍物提供路线变化。地图设计的目标不是装饰，而是让玩家自然产生“抢资源、绕路、埋伏、撤离”的不同打法。

8. 三局结算：排名与复盘

每轮可以选择不同方式撤离。最终三轮结束后给出玩家排名。

一场游戏固定包含三局。单局结束后，玩家会回到黑市，根据上一局收益调整下一局策略；第三局结束后进入总榜，按照宝石、击杀、撤离等结果给出最终排名。这种三局制让轻度玩家不会因为一次失败直接退出，也让竞技玩家有连续运营和翻盘空间。

综上，Alpha 版本已经覆盖了“熟人组局 - 黑市筹备 - 地图探索 - 开箱搜刮 - 战斗对抗 - 撤离抉择 - 三局排名”的主要用户场景。玩家不需要安装客户端，只要进入网页，就能完成组队、联机、战斗和结算的完整体验。

项目的杀手级功能，与竞品相比最特色的功能展现

项目的杀手级功能

本项目最核心的杀手级功能，是把“搜打撤”的完整体验压缩到一个 Web 多人游戏中。相比常见网页小游戏只提供单人闯关或简单对战，我们在 Alpha 阶段已经完成了“组队大厅 - 局间黑市 - 多人战斗 - 资源搜刮 - 背包取舍 - 撤离结算 - 三轮排名”的完整闭环。玩家不需要安装客户端，只要进入网页，就能邀请队友、准备物资、进入战场并完成撤离。

最有特色的机制是“局间黑市 + 战场搜刮 + 撤离收益”的联动。玩家不是只看击杀数，而是要在购买道具、搜索宝箱、保留战利品和选择撤离时机之间做决策；即使战斗能力较弱，也可以通过路线选择、道具配置和及时撤离获得收益。黑市购买、背包容量、宝石结算和撤离方式共同构成了每一局的风险收益权衡。

第二个特色是地图玩法的层次感。当前地图为 120 x 120、共 14400 个格子，包含 8 个建筑区域、34 个资源点、5 个撤离点、8 个出生点和 16 个地图交互物。建筑内外、楼层切换、宝箱、撤离点、小地图和倒计时都服务于同一个目标：让玩家在有限时间内判断“继续搜、去打、还是撤”。这让一局游戏不是单纯的击杀竞赛，而是从赛前准备、路线探索到带货撤离的策略过程。

第三个特色是职业与道具带来的多人协作空间。项目支持刺客、射手、坦克、战士、法师等职业，并提供护盾、治疗、加速、门禁卡等道具。不同职业在战斗距离、技能时机、撤离保护和资源争夺中的职责不同，队伍需要在黑市阶段提前规划，而不是进入地图后临时各玩各的。

竞品为什么较少覆盖这些功能

成熟的搜打撤游戏通常依赖大型客户端、复杂 3D 场景和高成本服务器架构；而普通网页联机游戏为了控制开发难度，往往会压缩成轻量对战、回合制或单人玩法。Web 端要同时做好多人同步、地图碰撞、资源刷新、背包交易、战斗判定、撤离结算和 UI 反馈，工程复杂度会明显高于普通网页小游戏。

我们能在 Alpha 阶段实现这套闭环，主要依赖两点：一是采用 Vue 3 + Phaser 3 + Colyseus 的分层架构，用 Vue 负责大厅、黑市、宝箱和结算 UI，用 Phaser 负责局内地图和角色表现，用 Colyseus 负责多人房间和状态同步；二是通过 shared 包把地图结构、玩法常量和状态 Schema 抽成前后端共用协议，减少前后端各自理解规则造成的对接成本。

团队自我评价

团队认为 Alpha 阶段的核心目标已经基本达到：玩家可以完成房间组队、职业选择、黑市购买、地图探索、开箱搜刮、战斗、撤离和排名结算。特别是“搜打撤”的核心风险收益循环已经跑通，产品已经不只是一个 UI 原型。

不足也比较明确。当前版本仍然存在数值平衡、地图内容密度、职业表现一致性、局内引导和测试覆盖不足等问题。部分功能在 Alpha 阶段为了按期发布选择了可用优先，例如地图数量目前以一张主地图为主，UI 细节和战斗反馈还需要 Beta 阶段继续打磨。

用户反馈

Alpha 发布后，我们通过网页链接邀请同学和团队成员进行试玩。试玩反馈中，用户普遍能理解“先进黑市准备，再进地图搜刮并找机会撤离”的主流程，也认为网页登录即可联机是一个明显优势。暴露的问题主要集中在新手第一次进入战场时不清楚优先目标、部分地图交互提示不够明显、战斗手感和职业数值还需要进一步调校。Beta 阶段会优先补充新手引导、地图提示和职业平衡。

项目发布时团队做了哪些努力，实际活跃用户数据如何？

通过网页链接进行发布。团队成员社交媒体进行游戏宣传，邀请用户进行alpha版本内测，并进行重点用户游玩测试调研。

在线游玩地址：http://152.136.168.29:2567/

Alpha 发布阶段，我们主要通过三类方式推广：团队成员在熟人社群中转发试玩链接；邀请前期访谈过的搜打撤玩家回访测试；在课程展示和团队内部联调中组织多人同时进入房间，重点观察创建房间、加入房间、黑市准备、战场探索、撤离结算等核心路径是否顺畅。

当前活跃用户统计仍以人工记录和试玩反馈为主，尚未接入正式埋点系统，因此不能像商业产品一样给出严格 DAU 曲线。Alpha 阶段可确认的有效试玩来自团队成员、课程同学和前期访谈用户，重点目标不是扩大日活，而是验证“用户能否顺利完成一整场游戏”。Beta 阶段计划补充房间创建数、加入成功数、开始战斗数、撤离成功数、完整结算数等埋点，用这些数据替代人工统计。

指标	Alpha 当前情况	后续改进
发布入口	公网 Web 地址可访问	保持稳定部署，补充备用地址或录屏
推广方式	熟人社群转发、课程展示、重点用户试玩	增加集中测试周和反馈表
活跃统计	以人工试玩记录为主	Beta 接入关键事件埋点
用户反馈	已收集到新手引导、地图提示、战斗手感等反馈	按反馈拆分为 Beta issue

团队代码的软件工程质量如何？如何用数据来证明？

Alpha 版本采用 shared、server、client 三包 Monorepo，前后端共享 Schema、地图结构和玩法常量，避免核心规则重复实现。服务端 MatchRoom 定义 31 类 Colyseus 消息处理，GameState.ts 定义 10 个共享 Schema，覆盖玩家、宝箱、撤离点、区域效果、守卫、门、地图物件和排行榜等状态。

质量数据方面，本地执行 corepack pnpm test 通过 2 个测试文件、11 个共享逻辑用例；执行 corepack pnpm build 通过 shared、server、client 三个子包构建。项目配置 1 个 GitHub Actions 工作流，包含 build 和 deploy 两个 job，部署脚本包含 PM2 reload 与 /healthz 健康检查。内容规模上，当前主地图为 120 x 120、共 14400 个格子，包含 8 个建筑、34 个资源点、5 个撤离点、8 个出生点和 16 个地图交互物；前端公共资源目录共有 229 个文件。

项目与团队总结

项目管理

团队成员的简介与个人博客地址

杰出青年

团队成员介绍

孙琦航 PM / 测试 咕咕嘎嘎。	吴震宏 美术 / 副 PM 主PM太拼命了！我也要做吗？
徐琬莹 前端设计 / 美术 生活不止眼前的代码，还有明天的代码和后天的代码。	刘舒童 后端设计 / 游戏玩法设计 我是Landau ，计算机军火商
赵骥远 游戏玩法设计 / 后端设计 越努力，越幸运！	朱城宇 测试 / 前端设计 不摸鱼的一天就好比一滴蜂蜜都不剩的罐子

团队是如何进行项目管理的

团队交流日常使用微信进行即时的交流和讨论

项目管理方面，使用 github 进行代码托管，CI/CD，以及 issue 的创建和管理

团队例会方面，使用腾讯会议进行团队内部的讨论。

团队的成员如何分工协作的？有什么经验教训？

在团队的分工上，考虑 alpha 阶段需要大量的美术资源，我们进行了如下分工：

姓名	分工
孙琦航	PM，前后端
赵骥远	游戏策划，前后端
朱城宇	测试，地图编辑
徐婉莹	美术
吴震宏	美术，前后端
刘舒童	美术

团队成员如何沟通和对接的？有什么记录留存？

日常的issue管理均在微信沟通，例如发现了什么什么bug，以及需要多人测试的时候也使用微信让大家一起测试。

在例会时使用腾讯会议沟通。

微信聊天记录和腾讯会议截图或者算是记录留存？腾讯会议截图都放到例会的博客里了，聊天记录还是不发了吧（）

团队如何平衡 时间/质量/资源 争取如期完成任务的？

时间方面，我们主要平衡的方面是灵活分工，例如对于代码的开发，本身计划是两位同学进行vibe coding的，但是实践中发现，由于团队交流的延迟等一系列问题，导致这样子修复的效率很低。又很多同学都有codex，代码质量是差不多的，因此我们选择了更多的人参与代码开发这一工作，从而提高了时间效率。

质量方面，我们把工作的重心放到了一些实际影响用户体验的部分，对于一些细节，放到了beta阶段开发，这样子能够保证交付的产品有着基本的质量保证。

团队项目的实际进展如何？在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？

我们团队的燃尽图如上，反映了我们团队的一些问题，比如前期开始工作较慢、喜欢将工作累计到一起完成等，虽然最后阶段回到正轨，比较平稳地完成了alpha阶段的任务，但是也给了我们在beta阶段以及以后工作的一些启示：我们需要更平衡与合理的进度规划以及更强的执行力，尽量平稳连续地推进任务，比如可以制定一些更加严格的工作量考核与奖惩机制等。

同时，我们认为这张燃尽图确实较好地反映了团队工作当中的真实的项目状态，并没有美化项目的真实状态。

成员在 Alpha 阶段的角色和具体贡献

名字	角色	团队贡献分	具体的、可衡量的、可验证的贡献
孙琦航	PM / 前后端 / 构建部署	50	完成 116 次提交；代码变更 32084 行，其中新增 27765 行、删除 4319 行；关闭 15 个 Issue。主要负责整体进度推进、前后端集成、构建部署、核心功能开发和最终封板。
赵骥远	玩法设计 / 前后端开发	52	完成 23 次提交；代码变更 +10198 / -863 行；关闭 39 个 Issue。主要负责游戏玩法设计、职业与道具平衡调整、游戏 Bug 修复和功能开发。
吴震宏	地图美术 / 前后端开发	51	完成 42 次提交；代码变更 +3674 / -1012 行；关闭 39 个 Issue。主要负责地图与物品素材绘制，并修复人物碰撞、移动同步和地图交互等问题。
徐琬莹	角色美术 / 前端相关支持	48	完成 4 次提交；代码变更 +173 / -21 行；关闭 11 个 Issue；绘制美术素材共计 57 张。主要负责角色美术设计，以及战士、射手、法师等角色绘制。
刘舒童	角色美术 / 美术接入开发	47	完成 18 次提交；代码变更 +1039 / -215 行；关闭 9 个 Issue；绘制美术素材约 55 张。主要负责游戏人物美术设计和美术素材接入代码开发。
朱城宇	测试 / 地图设计 / Bug 修复	52	完成 8 次提交；代码变更 +105208 / -5400 行；发现并提出 66 个 Issue。主要负责地图设计与实现、游戏测试以及部分 Bug 修复工作。

用户场景

项目开发前的目标、预期典型用户场景和功能描述

项目开发前，我们将产品定位为“轻量级 2.5D 像素风多人在线生存撤离网页游戏”。预期目标不是复刻完整商业搜打撤客户端，而是在课程项目周期内做出一个可通过浏览器直接访问、能够多人组局、能够完成搜刮和撤离闭环的最小可玩版本。

预期典型用户主要有三类：核心竞技玩家希望在短时间内获得战斗、搜刮、撤离和翻盘体验；熟人组局玩家希望无需安装客户端，发链接即可一起玩；轻度尝鲜玩家希望规则容易理解，失败代价不要过高。围绕这些用户，我们预期实现创建房间、邀请链接、职业选择、黑市购买、地图探索、宝箱搜刮、战斗、常规撤离、丢包撤离和三局结算。

项目发布的功能和发布地址

Alpha 版本已经发布为 Web 产品，访问地址为：http://152.136.168.29:2567/

发布功能包括：

功能	Alpha 发布情况
创建房间、加入房间、邀请链接	已实现，玩家可通过网页进入同一房间
昵称与职业配置	已实现，支持刺客、射手、坦克、战士、法师
黑市购买、出售、扩容、准备	已实现，玩家可用宝石购买道具和扩充背包
基础战斗	已实现，支持移动、普攻、职业技能、生命和护盾变化
宝箱搜刮	已实现，支持开箱、拾取宝石和道具、背包取舍
常规撤离与丢包撤离	已实现，支持带出收益或丢包止损
三局制与总结算	已实现，第三局后进入总榜并展示排名

发布后是否满足全部典型场景

发布后的 Alpha 版本基本满足了开发前定义的核心典型场景：熟人玩家可以通过链接组队，进入黑市购买道具，在地图中搜索宝箱并进行战斗，最后通过撤离和三局结算得到排名结果。这说明最小可玩闭环已经成立。

没有完全满足的部分主要有三点：第一，新手引导还不够清晰，玩家第一次进入战场时可能不知道优先目标；第二，地图和职业数值还需要更多真实对局数据来平衡；第三，当前活跃数据采集还没有自动化，发布后的用户行为主要靠人工观察和反馈记录。上述问题不影响 Alpha 主流程演示，但会影响 Beta 阶段的留存和可持续迭代。

目标用户使用产品的过程和评价

典型试玩过程如下：用户打开网页，输入昵称并创建或加入房间；房主复制邀请链接给其他同学；所有玩家选择职业并准备；进入黑市后购买治疗、护盾、加速或扩容背包；进入战场后通过小地图观察资源点，靠近宝箱搜刮物资；遭遇其他玩家时根据职业和道具选择战斗或撤退；最后选择常规撤离或丢包撤离，三局结束后查看排名。

用户反馈中，正向评价集中在“网页打开即可联机”“三局制比单局全损更容易接受”“黑市和背包让每一局有策略延续”。负向反馈集中在“第一次进入战场不够明确”“部分地图交互提示不够显眼”“职业数值和战斗手感还需要调整”。这些反馈与我们在 Alpha 阶段对产品成熟度的判断一致。

用户日活

推广努力

Alpha 发布时，团队主要通过熟人社群和课程展示进行推广：团队成员将在线地址发给同学进行试玩；邀请前期访谈过的搜打撤玩家回访；在多人联调时组织成员同时进入房间，验证联机稳定性和核心流程。

日活是否达到预先定义数量

T5 功能规格中曾设想测试周平均日活达到 8 人以上，并希望累计真实试玩用户达到至少 30 人。Alpha 发布时，由于我们尚未接入自动埋点和访问统计，不能严谨证明 DAU 达到该目标。当前能确认的是完成了多轮团队内测和若干外部同学试玩，但统计方式偏人工，证据强度不足。

导致日活目标暂时无法严格验证的原因包括：项目发布周期紧，优先级放在功能闭环和稳定部署；没有提前设计数据采集；推广范围主要是课程和熟人社群，用户规模有限。Beta 阶段需要把“数据采集”作为正式功能补上。

其他能佐证软件有用的指标

相比单纯 DAU，当前阶段更适合关注能否完成核心闭环的指标：

指标	意义
创建房间数、加入房间成功数	判断链接组队是否顺畅
开始黑市数、开始战斗数	判断玩家是否能进入主玩法
宝箱开启次数、道具购买次数	判断搜刮和黑市是否被使用
常规撤离成功数、丢包撤离成功数	判断撤离机制是否成立
完成三局结算数	判断用户是否体验了完整闭环

这些指标目前只能通过人工测试记录估算，Beta 阶段计划在服务端记录房间和回合关键事件，使数据具备可复查性。

用户反馈和 Bug 反馈

功能改进反馈主要集中在新手引导、地图交互提示、小地图遮挡和战斗手感。部分反馈已经在 Alpha 后期转化为修复，例如小地图改为可拖拽和收起，宝箱打开时限制移动，离开结算页后清理旧房间信息。

Bug 反馈主要集中在多人联机场景下的移动卡顿、建筑墙体碰撞、门洞附近卡顿、职业朝向贴图、宝箱状态和死亡/撤离后的观战体验。这些问题是多人实时网页游戏中可以预料的高风险区域，但具体表现仍然需要真实联调才能暴露。团队已经在 devlog 中记录多次修复，并通过构建、冒烟测试和浏览器 QA 进行回归。

特色功能

杀手级功能与竞品对比

项目的杀手级功能是 Web 端多人搜打撤闭环。与传统客户端搜打撤游戏相比，我们牺牲了大型 3D 表现和复杂装备系统，换来浏览器即开即玩、熟人链接组队和更低失败成本。与普通网页对战游戏相比，我们不是只做击杀对抗，而是加入了黑市经济、背包取舍、宝箱收益、常规撤离、丢包撤离和三局结算。

竞品没有囊括该特色功能的原因与团队优势

成熟搜打撤游戏通常依赖大型客户端、高性能渲染和复杂服务器架构，难以做到浏览器轻量访问；普通网页游戏为了降低开发难度，往往选择简单对战或回合制玩法，不会同时处理多人同步、地图碰撞、资源刷新、背包交易、战斗判定和撤离结算。

团队能实现该功能，主要依靠三个优势：玩法目标收敛，只做 Alpha 所需的最小可玩闭环；技术选型贴合场景，用 Vue 负责 UI、Phaser 负责局内表现、Colyseus 负责多人状态同步；工程结构上用 shared 包统一前后端协议，降低联调成本。

团队成员自我评价

团队认为特色功能基本达到 Alpha 预期。玩家已经可以体验到“准备、搜索、遭遇、撤离、结算”的完整流程，而不是只看到静态界面。没有完全达到预期的是内容丰富度和稳定性：当前主要围绕一张地图和五个基础职业展开，数值平衡、地图提示、新手引导和视听反馈仍需 Beta 阶段继续完善。

用户评价

用户普遍认为网页端联机和三局流转是有特色的：前者降低了组局门槛，后者降低了搜打撤玩法的挫败感。用户也指出，特色机制需要更好的引导来解释，例如为什么要先买道具、什么时候撤离、丢包撤离的代价是什么。也就是说，功能本身有辨识度，但表达和教学还需要增强。

软件工程质量

文档与可运行性

项目根目录提供了 README.md，说明了项目定位、技术栈、目录结构、本地开发、单机部署、Linux 部署、健康检查和 GitHub Actions 自动部署流程。新同学在一台新机器上只要具备 Node.js 与 Corepack，就可以按文档执行 corepack pnpm install、corepack pnpm build、corepack pnpm dev 或 corepack pnpm start 来启动项目。

技术规格方面，团队在 T6 技术规格说明书中记录了系统架构、前后端职责和部署方式；项目代码中进一步通过 shared 包保存跨端协议、地图结构和玩法常量。当前不足是还没有形成独立的代码风格文档，主要依赖 TypeScript 类型检查、模块划分和代码评审过程保证一致性。Beta 阶段需要补充更明确的命名、提交、分支、PR 和注释规范。

工程结构与可维护性

项目采用 pnpm workspace 管理 shared、server、client 三个子包：

• shared：维护 Colyseus Schema、地图文档结构、坐标转换、建筑门洞、楼层空间判定等前后端共用逻辑。
• server：基于 Node.js + Colyseus 实现房间管理、玩家状态、黑市、战斗、宝箱、撤离、门、楼梯和回合结算。
• client：基于 Vue 3 + TypeScript + Pinia + Phaser 实现大厅、黑市、宝箱 UI、局内地图渲染和操作反馈。

这种拆分保证了前后端不会各写一份关键规则。比如建筑门洞、楼层、资源点、撤离点等地图概念都先进入共享模型，再由服务端进行权威状态更新，客户端负责表现和交互。后续如果继续扩展地图、职业或道具，修改范围也比较清晰。

测试与自动化校验

项目目前具备三类质量校验：

类型	当前情况	覆盖重点
TypeScript 构建	corepack pnpm build 已通过	shared、server、client 三个子包能同时完成生产构建
单元测试	corepack pnpm test 已通过，2 个测试文件、11 个用例	共享地图几何、建筑 shell、门洞、楼层空间、坐标转换、地图导出
联机冒烟测试	server/scripts/smoke-test.mjs	双客户端进房、职业同步、准备、黑市购买、地图加载、楼层切换、开箱、同层/跨层战斗、撤离和回合流转

量化工程指标

• 协作开发：GitHub 293 次提交、81 个分支，项目有持续迭代和团队协作推进。
• 工程结构：项目采用 shared、server、client 三包 Monorepo，根目录和子包共提供 17 个 npm/pnpm 脚本。
• 自动化流程：配置 1 个 GitHub Actions 工作流，包含 build 和 deploy 两个 job；部署脚本中包含依赖安装、生产构建、PM2 reload 和 /healthz 健康检查。
• 核心协议：服务端 MatchRoom 定义 31 类 Colyseus 消息处理，GameState.ts 定义 10 个共享 Schema，覆盖玩家、宝箱、撤离点、区域效果、守卫、门、地图物件和排行榜等状态。
• 内容规模：地图为 120 x 120、共 14400 个格子，当前主地图含 8 个建筑、34 个资源点、5 个撤离点、8 个出生点和 16 个地图交互物；前端公共资源目录共有 229 个文件，其中 PNG 资源 207 个、SVG 资源 21 个。

CI/CD

项目采用 GitHub Actions 做 CI/CD。每次推送到 main 分支后，工作流会先在 Ubuntu 环境中安装依赖并执行 pnpm build，构建通过后再通过 SSH 登录服务器运行 scripts/deploy-linux.sh。服务器侧脚本会拉取最新代码、安装锁文件依赖、重新构建、通过 PM2 重载服务，并检查 http://127.0.0.1:2567/healthz。

采用 CI/CD 的原因是 Alpha 阶段多人联机项目改动频繁，前端 UI、共享协议和服务端状态机互相影响。如果每次部署都手工操作，很容易漏掉构建、锁文件安装或进程重启步骤。自动化流程至少保证主分支代码能构建、能部署、服务能恢复健康检查，减少发布时的人为失误。

Alpha 阶段质量经验

Alpha 阶段最大的经验是：多人游戏的“能跑”不等于“质量稳定”。移动同步、建筑碰撞、楼层判定、宝箱交互、撤离结算和角色技能都存在连锁影响，一个局部改动很容易引入其他场景回归。因此我们后期开始把地图几何、门洞、楼层空间等高风险逻辑下沉到 shared，并补充了共享逻辑单元测试。

Beta 阶段的质量改进重点包括：补齐服务端房间逻辑测试，增加前端关键组件测试，扩展联机冒烟测试场景，形成更明确的代码规范和 PR 检查清单；同时处理 Vite 大 chunk 警告，优化首屏加载和 Phaser 场景加载方式。

beta阶段计划

继续完善美术风格等内容，完善之前放弃的一些小细节