review-game

性能说明

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

游戏审查

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

说明

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

第 1 步：识别游戏

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

第 2 步：架构审查

检查是否采用以下必需模式，并报告符合情况：

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

第 3 步：性能审查

检查常见问题：

• Delta 时间上限：是否对 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 时间上限。积极发现：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。