[T.14] 团队项目：Alpha 阶段项目总结
一、 设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
Paradice（派乐代）是一款支持 2~4 人游玩的轻量化多人派对游戏。针对当前许多派对游戏规则繁琐、对设备配置要求较高或联机门槛复杂的问题，我们致力于提供一个开局足够轻量、规则简单易于上手，同时平衡策略和随机性，让玩家能够随时随地快速开整并玩得开心的解决方案。我们定义了清晰的典型用户，例如室友、关系亲近的朋友等，并围绕这些用户进行了典型场景的刻画：课后寝室闲暇时刻、周末朋友线上聚会、线下桌游代餐等。在这类场景中，玩家不追求高难度的硬核竞技，而是希望通过快速联机、随机地图行进、趣味小游戏和互相协作或拆台来获得乐趣~
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？）
我们在 Alpha 阶段达到了最初设定的可玩性目标并按时交付：支持 2~4 人创建/加入房间、房主管理成员并开局；玩家可以自由选择四类阵营能力；每轮通过五种风格各异的 mini game 争夺不同品质的骰子，并在随机地图上前进；最终到达终点共同击败 Boss。至于用户数量目标：在 Alpha 阶段我们并未盲目追求大规模的外部推广，而是将目标定在小范围、高活力的内测群，如班级同学、好友圈等。我们邀请到了 20+ 测试玩家，他们完成了多次完整的对局测试，基本达到了我们对初期核心用户群规模的预期。
-
用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
发布之后获得的用户反馈基本与我们事先的设想一致。玩家们普遍觉得游戏随机性强、互动性拉满、玩起来很有趣，尤其是小游戏的穿插和骰子的争夺，给对局带来了很多戏剧性效果。虽然我们也收到了一些关于希望动画更丝滑、游戏需要音效、获胜机制随机性太强等体验上的建议，但核心玩法的闭环总的来说还是很受玩家欢迎的，我们离「玩起来有意思」的预期目标更近了。
二、 计划
-
是否有充足的时间来做计划？
时间是相对充裕的。我们在项目早期就对玩法进行了反复讨论，并对前端 Phaser 引擎、后端 Nakama 联机框架等技术栈进行了调研和探索，所以在动手写业务代码前有充足的时间来规划架构。我们的前期开发偏向于实现稳定的后端逻辑计算与状态机转移，包含 HSM、Action、EventBus、协议、CLI 测试等内容，后期逐渐转向前端渲染、动画填充与 UI 美化等。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们主要通过每周的例会以及日常的即时沟通来探讨计划。队友们产生不同意见时，我们会进行及时地沟通与调整，一般主要听从负责人相关的意见，并最终客观地拿出一个大家都支持的最优版本。
-
原计划的工作是否最后都做完了？如果有没做完的，为什么？
原计划中的核心玩法与多端联机主流程基本都顺利完成了。但确实有少数不影响核心流程、属于体验优化范畴的工作没有在 Alpha 阶段全部收尾：- 音效系统：目前没有实现，原因是在时间排期中我们将动画表现和交互反馈的优先级排在了音效之前，导致时间被压缩。
- 美术风格未能达到完全统一的像素风：由于前端界面繁多、各类按键与交互弹窗开发量大，为了不耽误发布时间，部分地方还未完全实现视觉风格的统一。
- 高并发压力测试和真实用户验收测试：这部分在 Alpha 阶段有所欠缺，因为我们这一阶段的重心主要放在联机功能闭环和发布流程的调通上。
-
有没有发现你做了一些事后看来没必要或没多大价值的事？
在正式确立目前的《Paradice》之前，我们其实经历过一次选题的更换，比如尝试过类“北京浮生记”的交易游戏，在前端技术栈的选择上也做过一些摇摆和尝试，比如放手了 Godot 引擎，转向了网页与 Phaser 4。虽然这在事后看稍微占用了一些时间，但这些弯路让我们看清了技术瓶颈，最终坚定了使用 Phaser + Nakama 方案，避免了后续在不合适的技术栈上陷得更深。因此，这些探索虽然没能产出直接的代码，但对项目的最终落地方案是不可或缺的。
-
是否每一项任务都有清楚定义和衡量的交付件？
是的，我们的每项任务均在飞书的任务看板上有清晰的定义。例如：后端状态机的更新任务，交付件为通过配套的
go test单元测试脚本；前端某个 UI 界面的开发，交付件为通过代码合并审查（PR）并附带实际渲染截图。这种指派到人、结果可验证的机制，保证了任务能够顺利推进。 -
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
项目整体上是按照既定计划稳步推进的，没有出现灾难性的意外。 -
在计划中有没有留下缓冲区，缓冲区有作用么？
我们在计划中留下了相对充分的缓冲区。时间上，我们预留了发布周的前半周不排新功能，专门用于前后端联调、修 Bug 和功能测试。
功能上，我们设置了任务的优先级（P0/P1/P2），确保不影响主线对局的任务可以客观推后。这一缓冲区在后期联调时起到了重要作用，保证了我们能比较从容地解决各种突发的小问题。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在 Beta 阶段，我们将把缓冲区的定义更加细化。我们将建立更严格的延期预防机制，当某项 P0 级任务的截止时间临近且仍未完成时，便会通知所有成员共同协商并合力解决该任务，避免任务积压而被迫在最后阶段熬夜赶工。
三、 资源
-
我们有足够的资源来完成各项任务么？
我们拥有充足的资源来完成计划。团队的开发人员配置和分工十分合理，后端、前端、核心玩法逻辑、小游戏模块以及 UI 都有明确对应的负责人，大家在各自擅长和熟悉的领域内工作，效率较高。 -
各项任务所需的时间和其他资源是如何估计的，精度如何？
任务所需时间的估算主要是基于组员以往的开发经验和课程积累。对于后端业务逻辑、状态机以及核心算法等任务，由于规划清晰、模块解耦好，时间估算的精度较高；但对于前端 UI 排版和游戏场景的组装，由于 Phaser 引擎在布局上的某些繁琐特性，实际耗时比估算更多一些。
-
测试的时间，人力和软件 / 硬件资源是否足够？对于那些不需要编程的资源（美工设计 / 文案）是否低估难度？
软件和硬件资源非常到位。美术方面，游戏中用到的资源有 itch.io、craftpix、PixelLab、GPT image 2、Nano Banana、MXAI 的支持 ♡，资源很充裕；硬件资源方面，配置了火山引擎 ECS 云服务器，用于官网部署、联机服务测试和团队联调，并有特定的成员进行维护。此外，测试的时间和人力在 Alpha 阶段也基本能够支撑。
对于不涉及编程的资源，如游戏内文案，我们确实有些低估了难度。由于前期没有专人对所有文案进行二次校对，导致发布后的某些道具说明出现了意义含糊不清的现象，这是我们下个阶段需要填补的短板。
-
你有没有感到你做的事情可以让别人来做（更有效率）？
由于我们在开工前进行了明确的职责划分，每个人都负责自己最拿手的部分，例如技术核心成员 xxk 主攻游戏逻辑，lzq 负责服务器部署等，因此大家都各司其职。团队内基本没有出现自己负责的事情如果换别人来做会更有效率等资源错配的情况。
四、 变更管理
-
每个相关的员工都及时知道了变更的消息?
是的，我们建立了一套及时的变更通知机制。日常微调我们会通过 GitHub 的 Pull Request 备注以及飞书看板进行状态同步；一旦涉及游戏机制等的重大变更，负责人会在群里点对点艾特相关组员，并利用每周例会进行面对面的详细解释，确保没有成员因为信息差而做无用功。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们的核心判断依据是：该功能是否直接阻碍 2~4 人从创建房间到最终击败 Boss 的最小完整可玩闭环。- 必须实现的功能：Nakama 联机对战同步、基于 HSM 的回合状态转移逻辑、4 类阵营技能的基础规则计算、5 种核心小游戏的基本玩法、随机地图的前进以及 Boss 战触发。
- 推迟到 Beta 的功能：游戏音效系统、完全统一的像素风美术资产、高并发压力测试、以及详细的新手引导与图鉴等。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有的，我们为 Alpha 阶段定义了清晰的出口条件：- 玩家能顺利完成一场完整对局，即支持 2~4 人从加入房间、走格子、玩小游戏、打 Boss 到出结算界面。
- 联机部署版必须连续进行 10 局以上的完整联调测试，期间没有发生服务器进程崩溃或前端无法恢复的状态卡死。
- 核心功能在 GitHub CI 工作流中能自动化构建并测试通过。
-
对于可能的变更是否能制定应急计划?
我们暂时没有正式制定过应急计划，也未遇上棘手的紧急情况。如果后续开发中遇到紧急情况，我们也可以通过及时响应和快速协调来合力解决问题。
-
员工是否能够有效地处理意料之外的工作请求？
基本能够有效应对。因为大家都比较认真负责，对该游戏项目也有较大的热情，在面临突发任务时能够积极配合。
五、 设计与实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
项目开发初期，我们便确立了核心设计方案：- 后端架构设计：由 xxk 负责完成，包括 Nakama Match Handler 机制、HSM（分层状态机）状态流转、前后端通信协议、CLI 测试环境以及前端 Action 系统的接口定义。
- 前端架构设计：由 wty 负责完成，主要负责 PhaserBoard 的基础框架搭建与渲染管线规划。
这些设计在项目最早期由技术能力突出、执行力强、对游戏逻辑理解深刻的组员来推进是非常合适的 ദ്ദി ˉ꒳ˉ )✧，他们为项目打下了较好的地基。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计中确实遇到过一些模糊地带，最典型的是各种事件、Buff、动画等该以怎样的顺序依次渲染。遇到这些渲染和逻辑顺序问题，我们一般会把相关人员聚在一起，商讨出正确一致的逻辑，然后再及时修改相应的代码。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？
我们使用了较多单元测试和集成测试。后端有 53 个 Go 测试文件，覆盖了：RNG 与骰子；资源加载；错误处理；ID 与协议；游戏日志；Nakama 生命周期、消息、Presence、错误处理；Engine、Action、Event、Buff、Item、Boss 战、小游戏相关逻辑；HSM 状态栈、状态转移、回合场景、集成测试；Gamemap 路径与格子行为；CLI 自动化场景。测试对后端设计非常有效，尤其是 HSM 和 Action 系统。前端目前主要依赖构建检查和人工验收。
-
什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 bug？为什么我们在设计 / 开发的时候没有想到这些情况？
Bug 较多的地方是 Buff / Item / Event 规则系统。例如 Fire buff、相同 Buff 叠加、Buff tick、duration、everyNTurns、Hidden Buff、道具订阅等问题。原因是 Buff、道具、不同 phase、持续时间、触发条件、目标玩家、Action 系统相互交织，设计的时候要考虑何时触发、是否叠加、是否阻挡、是否派生 Action，实现时就容易出现一些 Bug。发布后没有发现影响核心流程的重大 Bug。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们依托 GitHub 的 Pull Request 工作流进行代码复审。任何代码不能直接推送到 dev 分支，必须先在独立分支开发，然后发起 PR。前端代码由 wty 审查，后端由 xxk 审查。我们借助 CI 工具强制检查代码规范，审查通过后方可合并，这有效避免了语法错误和风格混乱。
六、 测试与发布
-
团队是否有一个测试计划？为什么没有？
有的，我们制定了详尽的测试计划。计划中将测试范围划分为后端业务测试与 CLI 自动化回归测试，明确覆盖了基础对局流程、回合主流程、决策中断、小游戏流程、错误处理、断线重连、道具和阵营技能等主要模块。 -
是否进行了正式的验收测试？
进行了正式的验收测试。在发布前夕，我们组织了团队内部测试，并邀请了外部玩家进行多轮多人联机验收测试，模拟真实用户的对局行为。 -
团队是否有测试工具来帮助测试？
有。我们的测试工具链主要包括：本地的 Go 测试框架、自定义的 CLI 自动化测试客户端（可以模拟玩家行为发送指令）、Nakama 的开发者后台面板（用于观测实时 Session 和 Match 状态），以及 GitHub Actions CI 自动化构建与测试流水线。 -
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
虽然我们在后端实现了较高覆盖率的自动化测试，但在前端渲染和联机对战上，我们目前仍然比较依赖手动的对局测试，效率确实有待提升。在 Beta 阶段，我们计划编写一个模拟网络对战驱动脚本。该脚本可以通过 WebSocket 模拟 4 个并发的虚拟玩家自动加入游戏并进行随机策略对局，将每一步的前后端状态数据打上时间戳并记录。如果前端在某一帧的渲染状态与后端状态机断言不符，自动生成差异报告并报警，以此实现多端状态同步的自动化检测。
由于该脚本工作量与挑战较大，在实际执行中我们将尽力去探索和推进，争取予以实现。
-
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在 Alpha 阶段，我们对效能的跟踪还比较基础，主要通过跨平台（Windows/macOS/Linux）的多端真机运行来观察 CPU 与内存占用，以及通过连续完整对局测试来验证业务连续性。这些工作在发现资源加载卡顿、动画渲染、业务逻辑等相关问题上是较为有效的。不足与改进：目前我们尚未进行高并发的模拟压力测试。在 Beta 阶段，我们计划引入专门的压测工具，模拟成百上千个房间并发创建和计算，以此来评估火山引擎 ECS 服务器的带宽及 CPU 瓶颈。
-
在发布的过程中发现了哪些意外问题？
在实际部署和发布时，我们暂时没有收到玩家关于程序崩溃或意外卡死的反馈。
七、 讨论
-
对比敏捷的原则，你觉得你们小组做得最好的是什么？
做得最好的是能够围绕可运行的软件持续迭代，并根据实际问题调整优先级并依次解决。我们较早地实现了核心玩法闭环，形成了一个可玩的版本，然后在此基础上不断进行动画渲染和用户体验的优化。
-
什么是在下个阶段要改进的地方？越具体越好。
在 Beta 阶段，我们主要在以下 2 个方面进行具体改进：- 进度管理的颗粒度：明确各模块负责人，将飞书大卡片拆得更细，深度结合 GitHub Issues 和 Milestones，把任务追踪细化到每个小游戏、每个 Event 效果的具体落实。
- 代码审查的严格度：进一步收紧 PR 合并权限，确保核心分支代码不仅需要 CI 通过，还必须有至少一位非本模块作者的签准，以提高合并进来的代码质量。
浙公网安备 33010602011771号