[T.18] 团队项目：Beta 阶段项目展示
项目管理
依然采用github进行代码管理，采用飞书进行文档管理与任务协作
任务分配与管理
-
通过例会确定总体需求、划分优先级并进行任务分配，由相应负责同学进行任务细化，并填写到飞书当中
-
实时同步任务完成情况
Bug管理
在飞书中发布bug fix，并指定同学进行维修
分支与发布规范
我们制定了严格的分支管理规范，保证代码质量与版本控制
-
所有开发人员仅能够在自己的开发分支进行提交，并向dev分支提交PR
-
由前/后端负责人审核PR后进行合并
团队沟通
团队主要通过每日例会+微信群的形式进行沟通
-
每日例会：同步各成员的任务进展、当日计划以及遇到的问题，帮助团队及时掌握整体开发状态，并快速识别可能影响进度的风险点
-
微信群：作为日常即时沟通渠道，用于需求细节确认、问题反馈、任务提醒和临时决策沟通，保证信息能够快速传达和响应。
改进
在Alpha阶段，团队最大的经验教训是不能过度追求“既要又要”，Alpha阶段虽然讨论出了较多需求，但由于功能目标较分散，导致核心功能打磨不够充分。因此在Beta阶段，我们根据开发周期更紧张的实际情况，对任务设置了优先级，优先完成必要性更强、对用户体验影响更大的核心需求
典型用户场景
好友们在闲暇时一起打开《ParaDice》开启掷骰冒险。大家在地图上前行，通过小游戏和各种道具展开轻松有趣的斗智斗勇，并在随机事件中一路竞速，最终在欢笑与博弈中携手击败 Boss，决出最后的赢家。
项目特色
1.充足的小游戏
1）打字竞速
谁是打字达人？
2）切蛋糕
看谁能切得最精准？
3）信任考验
竞争还是合作，这是个问题？
4）博弈游戏
走多还是走少，选择相同步数的不动！
5）游标卡尺
看看谁停得最准~
6）彩虹记忆
短时记忆挑战，选择特定的颜色位置！
7）数算挑战
谁能算得最快（手速最快）😉
8）心中数秒
绝对的时间感？🤔
9）投骰子
幸运之神会眷顾谁呢？
2.丰富的道具/buff/事件
道具
任意门：传送至目标玩家所在的位置
猩红之刃：损失一半血量，对目标造成等量伤害
丘比特之箭：与某人共同获得永恒Buff，共享良性行为（Action）
骰子升级卡：将当前骰子提升一级：木 → 铜 → 银 → 金
魔笛：与某人共同获得沉沦Buff，共享恶性行为（Action）
名刀司命：抵挡一次致命伤害
萍雨水盂：获得甘霖Buff
反方向的钟：给目标玩家添加「迷途」Buff，使其下次移动时朝反方向前进
贤者的庇护：原地复活
金刚法印：获得金身Buff
摩愿佛珠：获得神眷Buff
buff
腐化：接下来4回合每2回合HP-1
诅咒：接下来3回合保持LP-1状态
神眷：接下来3回合保持LP+1状态
威势：青龙阵营增益，增益效果翻倍（阵营技能）
永恒：接下来2回合与某人共享良性行为（共享良性Action）
辟邪：接下来5回合无视毒瘴类负面效果
无畏：血量立刻减至1点，3回合内血量保持不变
离火：朱雀阵营增益，每4回合LP+1（阵营技能）
金身：接下来2回合受到的伤害减半
隐匿：接下来1回合免疫任意事件与道具影响
迷途：下1回合朝反方向移动
毒瘴：接下来3回合每回合触发一次恶性随机事件影响
甘霖：接下来4回合每2回合HP+1
劫运：白虎阵营技能，抢夺目标的好运（阵营技能）
贤者的庇护：原地复活，不回到检查点
庇护：抵挡一次致命伤害（隐藏效果）
沉沦：接下来2回合与某人共享恶性行为（共享恶性Action）
鎮厄：1回合内免疫恶性事件与负面Buff（玄武阵营技能）
反刺：受到伤害后反伤一部分（示例为约30%）
嗔怒：接下来2回合造成的伤害+1
事件
| 事件名称 | 事件描述 | 事件分类 | 具体效果 / 影响 |
|---|---|---|---|
| 采集到草药 | 在路边发现了草药，恢复了体力 | 正面事件 | 恢复玩家生命值（HP） |
| 吹出幸运泡泡 | 梦幻泡泡飘到你面前，藏着好运 | 正面事件 | 获得好运相关的增益 |
| 捡到勇士的圣遗物 | 发现古老圣遗物，获得一次道具抽奖机会 | 正面事件 | 免费获得 1 次道具抽取机会 |
| 受到天使眷顾 | 天使的祝福降临，获得神眷Buff | 正面事件 | 获得【神眷】Buff（LP +1，持续 3 回合） |
| 隐匿 | 遁入异次元空间，获得隐匿Buff | 正面事件 | 获得【隐匿】Buff（免疫任意事件与道具影响，持续 1 回合） |
| 交换 | 命运之手将你与另一位玩家交换位置 | 中性事件 | 与场上另一名玩家强制互换地图位置 |
| 这是什么？尝一口 | 发现神秘物质，尝试后获得随机效果 | 随机事件 | 随机触发正面或负面的未知效果 |
| 被蚊虫叮咬 | 丛林中的“蚊虫”叮咬了你 | 负面事件 | 触发轻微负面影响 |
| 踩到了狗屎 | 运气糟糕的一天 | 负面事件 | 触发轻微负面小事件 |
| 偶遇孤魂野鬼 | 你被野鬼打了一闷棍 | 负面事件 | 触发中度负面惩罚 |
| 一阵风 | 一阵狂风卷走了你的道具 | 负面事件 | 失去当前拥有的道具 |
| 恶魔之眼 | 你注视了恶魔的眼睛，获得诅咒Buff | 负面事件 | 获得【诅咒】Buff（LP -1，持续 3 回合） |
| 迷途 | 迷失方向，获得迷途Buff | 负面事件 | 获得【迷途】Buff（下一回合反向移动） |
| 雷劫 | 天雷降临，HP归零 | 致命事件 | HP 直接归零，退回最近的【检查点】 |
3.细致的新手引导
第一次涉及游戏相关概念时会引入介绍（如：HP生命值，LP幸运值，道具使用等），便于玩家快速上手。
触发新buff时（如：诅咒），我们会先介绍其效果，并将该buff图标置于页面左上角，鼠标悬于上可随时查看其效果，方便玩家快速理解和回顾。
4.综合的计分与成就机制
成就机制
共 9 个成就，每局每人每项只能获得一次。加分值分两档：5 分（基础成就） 与 8 分（高难成就）。
| AchievementType | 名称 | 触发条件 | 加分 | 触发机制 |
|---|---|---|---|---|
| triple_one | 三连一 | 连续 3 次掷骰为 1 | 5 | EventBus（每次 Action 前） |
| triple_six | 三连六 | 连续 3 次掷骰为 6 | 5 | EventBus |
| boss_kill_shot | K 头 | 对 Boss 造成致命一击（HP 预测法） | 5 | EventBus |
| boss_damage_ten | 勇者之路 | 累积对 Boss 伤害 ≥ 10 点 | 5 | EventBus |
| item_collector | 道具收藏家 | 同时持有 3+ 道具 | 5 | EventBus |
| first_to_boss | 先行者 | 第一个到达 Boss 格 | 5 | HSM 状态机（进入 Boss 战时） |
| survivor | 生存大师 | 游戏结束从未死亡 | 8 | HSM（GameOver 结算时） |
| luck_master | 幸运之星 | 游戏结束 LP 达最大值 | 8 | HSM（GameOver 结算时） |
| mini_game_winner_three | 小游戏之王 | 累计 3 次小游戏第 1 名 | 8 | HSM（每轮小游戏结束时） |
结算积分
小游戏排名得分（公式 10 - (rank-1)×3，最低 1 分）
| 排名 | 2 人局 | 3 人局 | 4 人局 |
|---|---|---|---|
| 第 1 | 10 | 10 | 10 |
| 第 2 | 7 | 7 | 7 |
| 第 3 | — | 4 | 4 |
| 第 4 | — | — | 1 |
Boss 战斗 / 道具 / 成就得分
| 得分项 | 常量 | 值 | 类别 |
|---|---|---|---|
| Boss 每点伤害 | ScoreBossDamagePerPt | 1 pt/伤害 | boss |
| Boss 暴击 | ScoreBossCritBonus | 2 pts | boss |
| K 头（击败 Boss） | ScoreBossKillShot | 15 pts | boss |
| 获得道具 | ScoreItemAcquired | 3 pts | item |
| 使用道具 | ScoreItemUsed | 2 pts | item |
| 骰子升级 | ScoreDiceUpgrade | 5 pts | item |
| 成就加分 | AchievementDefinition.Points | 5 或 8 pts | achievement |
不同名次的专属结算画面：
最终综合的排名与数据统计
开发过程中用户反馈
团队贡献
团队每人有45分基础分与8-3分奖励分。在beta阶段每个成员都很好的完成了各自的任务，我们根据成员贡献分配奖励分数
| 成员 | 角色 | 开发中负责的内容 | beta阶段分数 |
|---|---|---|---|
| 王天一 | PM、前端负责人 | 地图模块和部分BUFF/ITEM功能开发，完成了地图格子、进度条、格子属性和界面美化等内容的推进。 | 48 |
| 熊熙恺 | 副 PM、后端负责人 | 动画效果、结算机制以及部分BUFF/ITEM功能开发，完善了游戏的视觉反馈、积分排名和道具体验。 | 54 |
| 高藩 | 前端开发 | 完成了不同阶段BGM以及投骰子、按钮、行动反馈等音效设计与接入 | 52 |
| 蔡世源 | 前端开发 | 负责新手引导与规则说明模块，完善了BUFF、ITEM交互说明以及随机事件、HP、LP、检查点和BOSS战等规则说明内容 | 50 |
| 林子淇 | 策划、部署 | 主要参与小游戏模块和移动端优化工作，推动了小游戏功能完善，并提升了项目在移动端的适配效果 | 47 |
| 刘逸夫 | 小游戏开发 | 开发更多小游戏，丰富了游戏过程中的互动内容 | 49 |
项目进展
我们的燃尽图是根据已划分的子任务个数绘制的，因此能够较直观地反映Beta阶段任务剩余量的变化趋势。
发布
发布版本功能：
以下是为您整理的两个表格的 Markdown 格式：
发布版本功能：
| 功能模块 | 描述 |
|---|---|
| 创建派对房间 | 支持 2~4 人对局，房主创建房间，其他玩家可浏览列表或输入房间 ID 加入，房主可移出玩家 |
| 选择专属阵营 | 四个阵营（青龙/朱雀/白虎/玄武），每个阵营拥有独特技能 |
| 小游戏 (mini game) | 5 种小游戏（彩虹记忆、精准计时、游标卡尺读数等），根据排名分配骰子品质 |
| 主地图行进 | 地图由普通格、事件格、Fog 块、Fragile 块、Checkpoint、Boss 格组成 |
| 事件 / 道具 / Buff | 随机事件触发、道具使用（骰子升级卡、任意门、反方向的钟）、Buff/Debuff（神眷、甘霖、诅咒、毒瘴、迷途等） |
| Boss 战 | 抵达终点后与 Boss 交战，骰子点数为伤害，高质量骰子有更高暴击率；Boss 可发动天雷、诅咒、回血、反刺技能 |
| 结算界面 | 胜负结算展示 |
Beta 阶段新增功能：
| 功能模块 | 描述 |
|---|---|
| 音效系统 | 不同阶段 BGM 与关键操作音效 |
| 地图扩展 | 60 格地图、进度条、格子颜色区分、地图 UI 美化 |
| 更多小游戏 | 新增打字速度（TypingSpeed）、信任困境（TrustDilemma）、蛋糕切割（CakeCutting）、困境竞速（DilemmaRace）、数学计算（MathCalc）等 |
| 积分结算系统 | 基于小游戏表现、Boss 战表现、道具使用、随机成就等维度计算积分并排名 |
| 新手引导 | Buff / Item 说明页面 |
发布地址：
-
Web 版在线游玩：https://bitaction.cn/game/paradice/
-
桌面端下载：https://github.com/b1tAction/paraweb/releases （支持 Windows、macOS、Linux）
用户日活
推广
-
在官方网站 https://bitaction.cn/ 上线项目介绍页
-
建立官方测试群（QR 码发布于发布说明），邀请玩家加入内测
-
通过班级同学、好友圈进行口碑推广，邀请 20+ 玩家内测
日活
根据后台数据统计，Beta 阶段的玩家总数大致300+人
软件工程质量
文档
后端文档体系相当完善，paradiced 仓库中包含：
| 文档 | 路径 | 说明 |
|---|---|---|
| 项目总览与开发指南 | CLAUDE.md | 覆盖架构、包结构、编码规范、开发流程、Git 规范 |
| 后端启动与生产部署 | README.md | 详细的本地启动流程、Docker 配置、生产环境 nginx 路由 |
| 游戏设计文档 | doc/background.md | 游戏背景、玩法规则、事件/Buff/道具/阵营/Boss 战规则 |
| EventBus 系统 | doc/internal/event_bus_system.md | 事件总线详细说明 |
| Metadata 契约文档 | doc/metadata/ | LogEntry/Player/EventContext/HSMContext/ActionContext/Buff/RoundData 等字段契约 |
| 各子包 README | pkg/*/README.md、internal/*/README.md | 覆盖 constants、gamelog、id、net、protocol、rng、hsm、action、nakama、cli 等模块 |
前端文档相对较少，主要依赖代码自解释和 PR 审查。
代码规范
-
后端：英文注释（游戏专属术语保留中文），禁止类型别名，使用
constants.Type格式引用枚举，Git Commit 信息必须英文，禁止git add .必须明确指定文件。 -
前端：使用 biome（
biome.jsonc存在）进行代码格式化与 lint 检查，TypeScript 严格模式。
单元测试
项目有完善的单元测试和集成测试体系：
-
测试文件数量：代码库中共有 465 个
_test.go测试文件（含子包） -
覆盖范围：
-
RNG 与骰子（
pkg/rng） -
资源加载（
pkg/resource） -
错误处理（
pkg/errors） -
ID 与协议（
pkg/id、pkg/net） -
游戏日志（
pkg/gamelog） -
Nakama 生命周期、消息、Presence、错误处理（
internal/nakama） -
Engine、Action、Event、Buff、Item、Boss 战、小游戏逻辑（
internal/engine） -
HSM 状态栈、状态转移、回合场景、集成测试（
internal/engine/hsm） -
Gamemap 路径与格子行为（
internal/gamemap） -
CLI 自动化场景（
internal/cli）
-
实际代码行覆盖率
| 文档 | 路径 | 说明 |
|---|---|---|
| 项目总览与开发指南 | CLAUDE.md | 覆盖架构、包结构、编码规范、开发流程、Git 规范 |
| 后端启动与生产部署 | README.md | 详细的本地启动流程、Docker 配置、生产环境 nginx 路由 |
| 游戏设计文档 | doc/background.md | 游戏背景、玩法规则、事件/Buff/道具/阵营/Boss 战规则 |
| EventBus 系统 | doc/internal/event_bus_system.md | 事件总线详细说明 |
| Metadata 契约文档 | doc/metadata/ | LogEntry/Player/EventContext/HSMContext/ActionContext/Buff/RoundData 等字段契约 |
| 各子包 README | pkg/*/README.md、internal/*/README.md | 覆盖 constants、gamelog、id、net、protocol、rng、hsm、action、nakama、cli 等模块 |
核心游戏逻辑（engine/minigame、event、gamemap、rng、action）覆盖率均在 90% 以上，整体测试质量较高。internal/nakama（Nakama 协议适配层）和 internal/cli（CLI 工具）覆盖率相对较低，是后续可重点补充的方向。
CI/CD
项目采用了完整的 CI/CD 流水线
-
CI（
ci.yml）：所有 push 和 PR 触发，包含以下 job：-
Go Test：go test ./...运行全量测试 -
Build Dev：go build验证编译（排除 Nakama 插件） -
Build CLI：go build ./cmd/pdcli验证 CLI 工具
-
-
CD（
deploy.yml）：PR 合并到 master 或手动触发时：-
验证模块文件、运行测试、构建包
-
用
git archive打包源码为 tar.gz -
SSH 上传到服务器
/opt/paradiced/incoming/ -
调用服务器受控 sudo wrapper 执行 pluginbuilder 构建和
docker compose up -d部署
-
经验教训
Beta 阶段落实的工程改进：
- 进度管理颗粒度：Beta 阶段将飞书大卡片拆得更细，结合 GitHub Issues 和 Milestones 追踪到每个小游戏、每个 Event 效果的具体落实，有效减少了"任务积压在最后阶段"的风险。Scrum Meeting 系列（Meeting 8~14）完整记录了每两日的进度与困难，信息透明度明显提高。
- 代码审查严格度：进一步收紧 PR 合并权限，要求核心分支代码除 CI 通过外，还必须有至少一位非本模块作者的签准，提升了合并代码质量。
- 回归测试意识增强：Beta 阶段新增功能（复活甲、名刀司命、积分结算等）在每轮开发后均进行了专项回归测试，Scrum Meeting 记录中多次出现"完成 XXX 测试用例整理"和"修复 XXX 后的状态恢复问题"等条目，说明团队在引入新功能时主动保护已有逻辑的意识明显提升。
Beta 阶段的实际教训：
- 在线多人小游戏的同步比预期顺利：信任困境（TrustDilemma）等在线博弈论小游戏的多人实时同步运行稳定，联调没有出现重大问题，说明基于 Nakama WebSocket 的同步架构在新玩法类型上具备良好扩展性。
- 积分结算引入的边界情况复杂：将小游戏排名、Boss 战伤害贡献、道具使用次数、随机成就等多维度汇总进结算系统，需要在 Scrum Meeting 11/12/13 中多次修复"BOSS 战重复计分"等边界问题。教训：多维度计分逻辑的边界情况需要在设计阶段就明确定义清楚，而非依赖测试驱动发现。
- 新 Buff/Item 的触发顺序验证成本高：复活甲、名刀司命等新增道具与已有 Phase 系统交织，需要针对每种组合编写独立测试用例，测试维护成本比预期高。提示设计新 Buff/Item 时应同步设计完整的测试矩阵。
- 用户引导和文案应与功能同期规划：Alpha 阶段总结指出道具说明文案意义含糊不清，Beta 阶段虽已补充 Buff/Item 说明交互，但这一教训提醒我们：文案和引导应在功能开发同期规划，而非在发布前期突击补充。
- 移动端适配工作量：超出预期，适配移动端的工作量比想象中更大。
对软件工程的整体认识：
经过 Alpha 和 Beta 两个完整迭代，团队对以下软件工程实践形成了切身体会：权威服务器架构（Nakama + HSM）在保障多人游戏一致性上效果显著，但它带来的复杂性需要充足的单元测试覆盖来保障；CI/CD 流水线是多人协作的核心基础设施，让团队能够自信地频繁合并而不担心引入回归问题；任务拆分和 P0/P1/P2 优先级管理真正帮助团队在时间压力下守住了核心交付物。
浙公网安备 33010602011771号