review-game

性能说明

• 请花时间彻底完成
• 质量比速度更重要
• 不要跳过验证步骤

游戏审查

分析现有游戏代码库并提供结构化审查。这是流水线中的最后一步——用于检查所有内容是否正确连接，并给出质量评分。

说明

分析 $ARGUMENTS 指定的游戏（如果未提供路径，则分析当前目录）。

第 1 步：识别游戏

• 检测引擎（Three.js、Phaser 或其他）
• 查看 package.json 中的依赖项和脚本
• 查看主入口文件和 index.html
• 识别游戏概念／类型

第 2 步：架构审查

检查以下必需模式并报告符合情况：

• EventBus：是否有集中式事件系统？模块之间是否解耦？
• GameState：是否有集中式状态单例？
• 常量：配置值是否集中管理，还是散落为魔法数字？
• 协调器：是否有初始化所有内容的主 Game 类？
• 目录结构：代码是否按 core/systems/gameplay/ui/level 分层组织？
• 事件常量：事件是否定义为命名常量，而非原始字符串？

第 3 步：性能审查

检查常见问题：

• Delta time 上限：是否对 getDelta() 设置上限，以防止死亡螺旋？
• 对象池：是否在热点循环中复用临时对象？
• 资源释放：是否释放 Three.js 几何体／材质／纹理？
• 事件清理：场景切换时是否清理事件监听器？
• 资源加载：是否预加载资源并提供进度反馈？

第 4 步：代码质量

• 无循环依赖：模块依赖方向是否单一？
• 单一职责：每个模块是否只有一个明确职责？
• 错误处理：事件处理程序是否使用 try/catch 包装？
• 命名一致：事件是否使用 domain:action 格式，文件是否使用 PascalCase？

第 5 步：变现准备度

• 积分系统：是否有计分／积分机制？
• 会话跟踪：是否可以识别游戏会话？
• 反作弊能力：分数是否在服务端验证，或至少采用便于服务端验证的结构？
• Play.fun 集成：是否已有 SDK 集成？

输出格式

提供包含以下内容的结构化报告：

1. 游戏概览 - 游戏内容、技术栈、游戏循环
2. 架构评分（共 6 项检查）
3. 性能评分（共 5 项检查）
4. 代码质量评分（共 4 项检查）
5. 变现准备度（共 4 项检查）
6. 首要建议 - 按优先级列出改进项，并用浅显易懂的语言解释
7. 良好之处 - 正面发现

示例用法

/review-game examples/flappy-bird

结果：架构 6/6、性能 4/5、代码质量 4/4、变现准备度 2/4 → 首要建议：添加 Play.fun SDK、为管道添加对象池、设置 Delta time 上限。良好之处：EventBus 使用规范、GameState 重置正确、目录结构组织良好。

下一步

告诉用户：

你的游戏已完成整个流水线！以下是你已完成的内容：

• 脚手架架构（/viral-game）
• 视觉润色（/design-game）
• 音乐和音效（/add-audio）
• 自动化测试（/qa-game）
• 架构审查（/review-game）

（对应 /viral-game 一次性流水线。如果你正在通过 /make-game 逐步开发，对应的阶段是“脚手架阶段完成 + 已交付首个开发里程碑”。）

接下来做什么？

• 使用 /game-creator:add-feature [description] 添加新的游戏玩法功能
• 部署到 Web——运行 npm run build && ~/.agents/skills/here-now/scripts/publish.sh dist/ 即可快速托管，或使用 GitHub Pages、Vercel、Netlify、itch.io
• 继续迭代！进行更改后，随时再次运行 /design-game、/add-audio 或 /review-game。