mcpField
I
improve-game

improve-game

github.com/hungify开发016 次安装1 周前更新
代码仓库

关于 improve-game

improve-game 是面向编码 Agent 的技能,可审查游戏项目、评估问题并排列改进优先级;用户选择后再实施和验证更改,涵盖玩法、视觉、代码、性能与玩家体验。

主要功能

  1. 01审查游戏代码与测试
  2. 02评估 13 个改进领域
  3. 03按影响排列改进项
  4. 04获用户确认后再修改
  5. 05验证构建与测试

适用场景

  1. 01修改前评估游戏项目
  2. 02确定玩法和视觉修复优先级
  3. 03逐步实施选定的改进

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/hungify/playables-skills --skill improve-game

安装后在 Claude Code 中输入/improve-game确认已加载。

详细介绍

性能说明

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

改进游戏

让你的游戏变得更好。此命令会深入审查游戏玩法、视觉效果、代码质量、性能和玩家体验,然后实施影响最大的改进。你可以根据需要多次运行,每次都会找出下一个最值得修复的问题。

说明

改进当前目录中的游戏。如果 $ARGUMENTS 指定了关注领域(例如,“玩法”“视觉效果”“性能”“润色”或“游戏结束”),请优先考虑该领域,但仍需审查所有方面。

第 1 步:深入审查

阅读整个游戏代码库,全面了解项目:

  • package.json — 引擎、依赖项、脚本
  • src/core/Constants.js — 所有配置值
  • src/core/EventBus.js — 所有事件及其用法
  • src/core/GameState.js — 状态结构和重置逻辑
  • src/core/Game.js(或 GameConfig.js)— 调度器和游戏循环
  • src/scenes/ 或 src/systems/ 中的每个文件 — 游戏玩法逻辑
  • src/entities/ 中的每个文件 — 游戏对象
  • src/ui/ 中的每个文件 — 游戏结束界面、覆盖层
  • src/audio/ 中的每个文件 — 音乐和音效
  • index.html — 标记、覆盖层、样式、viewport 元标签
  • src/systems/InputSystem.js — 输入处理、移动端支持(陀螺仪、摇杆、触控)
  • tests/ — 测试覆盖率和质量

不要略读。请完整阅读每个文件,确保在提出建议之前全面理解项目。

步骤 2:评分与诊断

按 1–5 分为每个方面评分(1 = 功能故障或缺失,3 = 基本可用,5 = 完善精良)。请提供诊断表:

方面评分诊断
游戏体验核心循环是否有趣?操作响应是否灵敏?难度是否逐渐提升?
视觉精致度背景、颜色、粒子效果、动画、屏幕特效
游戏结束与 UI游戏结束画面、过渡效果、重新开始流程、按钮
音频各状态的 BGM、各操作的 SFX、音量平衡、静音开关
代码架构EventBus、GameState、Constants,是否没有循环依赖
重新开始安全性GameState.reset() 是否彻底清理?连续重新开始 3 次,结果是否一致?是否存在过期的监听器或计时器?
性能Delta 限制、对象池、资源释放、是否存在泄漏
玩家体验新手引导、反馈、难度曲线、可重玩性
移动设备支持触控输入、自适应布局、陀螺仪/摇杆、44px 触控目标
Play.fun 安全区域所有 UI 元素是否都在 SAFE_ZONE.TOP(约 8% / 75px)以下?是否有内容被 Play.fun 小组件遮挡?
玩法不变量玩家能否得分?玩家能否死亡?游戏结束按钮是否显示文字?render_game_to_text() 是否返回有效的 JSON?
实体尺寸角色是否足够大、便于辨认?以角色为核心的游戏中,角色需占 GAME.WIDTH 的 12–15%。是否采用按比例调整尺寸(GAME.WIDTH * ratio),而非固定像素?
测试覆盖启动、游戏过程、得分、重新开始、视觉效果、性能测试

总分:X / 65

步骤 3:改进计划

根据审查结果,找出对玩家影响最大的 5–8 项改进,并按影响排序。每项包括:

  1. 标题 — 简短名称(例如:“加入难度递进”)
  2. 方面 — 改进的类别
  3. 影响 — 说明这对玩家的重要性
  4. 要做的事 — 用通俗易懂的语言描述改动
  5. 涉及文件 — 将创建或修改的文件

请按编号列表的格式呈现,并将影响最大的项目排在最前面。

向用户展示计划,并询问他们想实施哪些改进。选项:

  • “全部” — 实施所有改进
  • 具体编号 — 实施指定项目
  • “前 3 项” — 仅实施影响最大的 3 项

请先等待用户选择,再开始实施。

第 4 步:实现

对于每项选定的改进,请遵循以下规则:

  1. 先定义常量 — 将所有新增配置值添加到 Constants.js。禁止硬编码值。
  2. 再定义事件 — 使用 domain:action 命名方式,将所有新增事件添加到 EventBus.js。
  3. 按需添加状态 — 在 GameState.js 中添加新的状态字段,并正确重置。
  4. 将新文件放在正确的目录中 — 实体放在 entities/,系统放在 systems/,UI 放在 ui/。
  5. 通过协调器接入 — 在 Game.js 中注册新系统,并正确设置生命周期。
  6. 使用 EventBus 进行通信 — 模块之间不得直接导入。
  7. 保持现有代码风格 — 与项目其余部分使用相同的模式、命名和格式。
  8. 不要破坏现有功能 — 除非改进明确针对现有玩法、控制和计分,否则必须保持其行为完全一致。

实现每项改进后,运行 npm run build,立即检查错误。修复所有构建错误后,再进行下一项改进。

第 5 步:验证

实现所有改进后:

  1. 运行 npm run build — 确认构建成功且没有错误
  2. 如果存在测试,运行 npm test — 确认所有测试仍然通过
  3. 如果测试因有意的改动(新场景、元素变更)而失败,请调整测试以符合新行为
  4. 如果游戏有视觉回归测试,请更新快照:npm run test:update-snapshots
第 6 步:报告

告知用户有哪些改动:

改进报告

评分:X/65 → Y/65(+Z 分)

已实现:

  1. [标题] — [用一句话概述改动内容]
  2. [标题] — [用一句话概述改动内容] ...

新建文件: [列出新文件] 修改文件: [列出已更改的文件]

测试方法: 运行 npm run dev 并检查:

  • [需要检查的具体内容]
  • [需要检查的具体内容]

后续改进: 再次运行 /game-creator:improve-game,查找下一批改进项。

重点领域

当 $ARGUMENTS 包含某个重点领域关键词时,请优先检查以下具体内容:

"gameplay" — 核心循环、操控、难度进阶、敌人多样性、强化道具、风险与回报、节奏、关卡设计

"visuals" — 加载 game-designer 技能,并执行完整的设计审查(背景、配色、动画、粒子、转场、字体、反馈效果)

"performance" — delta 限制、对象池、几何体/材质释放、事件监听器清理、requestAnimationFrame 用法、绘制调用次数、纹理图集用法

"polish" — 屏幕震动、受击停顿、挤压/拉伸、缓动曲线、音效时机、按钮反馈、得分弹出效果、死亡动画、转场流畅度

"game-over" — 游戏结束画面的吸引力、重启流程、按钮样式、得分显示、最高分显示、动画。按钮文字必须可见——确认 createButton() 模式使用 Container + Graphics + Text(Graphics 在前,Text 在后,Container 可交互)。如果按钮标签不可见,说明该模式有问题。注意:游戏默认没有标题/菜单画面(Play.fun 会处理界面框架)。只有用户明确要求时才添加标题画面。得分 HUD 由 Play.fun 小组件处理——不要另加游戏内得分显示。所有游戏结束界面都必须位于 SAFE_ZONE.TOP 以下。

"audio" — 加载 game-audio 技能。检查 BGM 覆盖情况(每种游戏状态都应有音乐)、SFX 覆盖情况(每个玩家操作都应有反馈)、音量混合、曲目间转场是否流畅

"mobile" — 已实现触控输入(点击区域、虚拟摇杆或陀螺仪)、画布可自适应(Phaser.Scale.FIT 或 CSS width:100%)、触控目标至少为 44px、通过虚拟摇杆或点击区域进行移动、倾斜类游戏支持陀螺仪、没有仅悬停可用的交互、已在移动端视口(Pixel 5 模拟)上测试。阅读 InputSystem.js、所有场景/系统的 update() 方法、index.html 中的 viewport meta,以及 Constants.js 中的触控目标尺寸。

"ux" — 引导(玩家是否知道该做什么?)、反馈(每个操作是否都有响应?)、难度曲线(是否太难/太简单?)、可重玩性(是否有再次游玩的理由?)

使用示例

常规改进
/improve-game

结果:全面审查 → 得分 38/65 → 找出 6 个优先改进项(难度进阶、屏幕震动、更好的游戏结束界面、粒子效果、移动端触控、重启安全性)→ 询问要实施哪些改进 → 实施所选改进 → 得分升至 52/65。

定向改进
/improve-game gameplay

结果:提高 gameplay 检查项的权重 → 发现敌人种类较少且难度曲线平缓 → 新增 3 种行为各异的敌人、逐步提升速度,并按得分划分难度等级。

故障排除

改进导致现有玩法出问题

原因: 修改共享系统(物理、计分)会产生连锁影响。
解决方法: 每次单独测试一项改进。每次更改后运行现有测试。如果更改破坏了核心玩法,就撤销该更改。

一次改动太多

原因: 审查发现了 10 多个问题,并且同时全部实施。
解决方法: 优先处理 3-5 项改进。分批发布。每次更改后都进行验证。

提示

此命令用于迭代改进。请多次运行:

  • 第一轮:修复最大的问题(缺少功能、UX 出错)
  • 第二轮:增加润色效果(粒子、转场、反馈效果)
  • 第三轮:微调(难度曲线、时机、平衡性)

每次运行都会接续上次的进度——之前已修复的领域得分会更高,从而显现新的优先事项。

如需定向处理,请使用重点领域:/game-creator:improve-game gameplay 或 /game-creator:improve-game visuals

评论

支持 Markdown