improve-game

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Improve Game

改进游戏

Make your game better. This command deep-audits gameplay, visuals, code quality, performance, and player experience, then implements the highest-impact improvements. Run it as many times as you want — each pass finds the next most impactful thing to fix.

让你的游戏变得更好。该命令会深度审计游戏玩法、视觉效果、代码质量、性能和玩家体验，然后实施影响力最大的改进措施。你可以多次运行该命令——每次执行都会找出下一个最具影响力的待修复问题。

Instructions

操作说明

Improve the game in the current directory. If

$ARGUMENTS

specifies a focus area (e.g., "gameplay", "visuals", "performance", "polish", "game-over"), weight that area higher but still audit everything.

优化当前目录下的游戏。如果

$ARGUMENTS

指定了重点领域（例如“gameplay”“visuals”“performance”“polish”“game-over”），则会优先侧重该领域，但仍会对所有方面进行审计。

Step 1: Deep audit

步骤1：深度审计

Read the entire game codebase to build a complete picture:

```
package.json
```
— engine, dependencies, scripts
```
src/core/Constants.js
```
— all configuration values
```
src/core/EventBus.js
```
— all events and their usage
```
src/core/GameState.js
```
— state shape and reset logic
```
src/core/Game.js
```
(or
```
GameConfig.js
```
) — orchestrator and game loop
Every file in
```
src/scenes/
```
or
```
src/systems/
```
— gameplay logic
Every file in
```
src/entities/
```
— game objects
Every file in
```
src/ui/
```
— game over, overlays
Every file in
```
src/audio/
```
— music and sound effects
```
index.html
```
— markup, overlays, styles, viewport meta
```
src/systems/InputSystem.js
```
— input handling, mobile support (gyro, joystick, touch)
```
tests/
```
— test coverage and quality

Don't skim. Read every file completely so you understand the full picture before making recommendations.

通读整个游戏代码库，全面了解情况：

```
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
```
—— 标记、覆盖层、样式、视口元标签
```
src/systems/InputSystem.js
```
—— 输入处理、移动设备支持（陀螺仪、操纵杆、触摸）
```
tests/
```
—— 测试覆盖率与质量

不要略读。完整阅读每个文件，以便在提出建议前充分了解整体情况。

Step 2: Score and diagnose

步骤2：评分与诊断

Rate each area on a 1–5 scale (1 = broken/missing, 3 = functional but basic, 5 = polished and complete). Present a diagnostic table:

Area	Score	Diagnosis
Gameplay feel		Is the core loop fun? Are controls responsive? Does difficulty ramp?
Visual polish		Backgrounds, colors, particles, animations, screen effects
Game Over & UI		Game over screen, transitions, restart flow, buttons
Audio		BGM for each state, SFX for each action, volume balance, mute toggle
Code architecture		EventBus, GameState, Constants, no circular deps
Restart safety		Does GameState.reset() fully clean up? 3 restarts identical? No stale listeners/timers?
Performance		Delta capping, object pooling, disposal, no leaks
Player experience		Onboarding, feedback, difficulty curve, replayability
Mobile support		Touch input, responsive layout, gyro/joystick, 44px touch targets
Play.fun safe zone		All UI elements below `SAFE_ZONE.TOP` (~8% / 75px)? Nothing hidden behind Play.fun widget?
Gameplay invariants		Can the player score? Can the player die? Do game-over buttons show text? Does `render_game_to_text()` return valid JSON?
Entity sizing		Are characters large enough to read? Character-driven games need 12–15% of GAME.WIDTH. Proportional sizing ( `GAME.WIDTH * ratio` ), not fixed pixels?
Test coverage		Boot, gameplay, scoring, restart, visual, perf tests

Overall score: X / 65

对每个领域按1-5分评分（1=损坏/缺失，3=可用但基础，5=打磨完善）。呈现诊断表格：

领域	评分	诊断
游戏手感		核心循环是否有趣？控制是否响应灵敏？难度是否逐步提升？
视觉打磨		背景、色彩、粒子效果、动画、屏幕特效
游戏结束与UI		游戏结束界面、过渡效果、重启流程、按钮
音频		各状态下的背景音乐（BGM）、各动作对应的音效（SFX）、音量平衡、静音开关
代码架构		EventBus、GameState、Constants、无循环依赖
重启安全性		GameState.reset()是否能完全清理？连续3次重启是否一致？是否存在残留的监听器/计时器？
性能		增量限制、对象池、资源释放、无内存泄漏
玩家体验		新手引导、反馈机制、难度曲线、重玩价值
移动设备支持		触摸输入、响应式布局、陀螺仪/操纵杆、44px触摸目标
Play.fun安全区域		所有UI元素是否位于 `SAFE_ZONE.TOP` （约8%/75px）以下？没有内容被Play.fun组件遮挡？
游戏玩法不变量		玩家能否得分？玩家能否死亡？游戏结束按钮是否显示文本？ `render_game_to_text()` 是否返回有效JSON？
实体尺寸		角色是否足够清晰可读？角色驱动的游戏中，角色尺寸需占GAME.WIDTH的12-15%。是否使用比例尺寸（ `GAME.WIDTH * 比例` ）而非固定像素？
测试覆盖率		启动、游戏玩法、计分、重启、视觉、性能测试

总评分：X / 65

Step 3: Improvement plan

步骤3：改进计划

From the audit, identify the top 5–8 improvements ranked by player impact. For each one:

Title — short name (e.g., "Add difficulty progression")
Area — which category it improves
Impact — why this matters to the player
What to do — plain-English description of the change
Files touched — which files will be created or modified

Format as a numbered list. Put the highest-impact items first.

Present the plan to the user and ask which improvements to implement. Options:

"All" — implement everything
Specific numbers — implement selected items
"Top 3" — just the most impactful

Wait for the user to choose before implementing.

从审计结果中，确定5-8项最具玩家影响力的改进措施，按优先级排序。每项需包含：

标题 —— 简短名称（例如“添加难度递进系统”）
领域 —— 优化的所属类别
影响力 —— 对玩家的重要性
实施内容 —— 用通俗易懂的语言描述修改内容
涉及文件 —— 需创建或修改的文件

以编号列表形式呈现。将影响力最高的项放在最前面。

向用户展示计划并询问要实施哪些改进。选项：

“全部” —— 实施所有改进
具体编号 —— 实施选中的项
“前3项” —— 仅实施最具影响力的3项

等待用户选择后再开始实施。

Step 4: Implement

步骤4：实施改进

For each selected improvement, follow these rules:

Constants first — add all new config values to
```
Constants.js
```
. Zero hardcoded values.
Events next — add any new events to
```
EventBus.js
```
using
```
domain:action
```
naming.
State if needed — add new state fields to
```
GameState.js
```
with proper reset.
New files in proper directories — entities in
```
entities/
```
, systems in
```
systems/
```
, UI in
```
ui/
```
.
Wire through orchestrator — register new systems in
```
Game.js
```
with proper lifecycle.
EventBus for communication — modules never import each other directly.
Match existing code style — same patterns, naming, formatting as the rest of the project.
Don't break what works — existing gameplay, controls, and scoring must still function identically unless the improvement specifically targets them.

After implementing each improvement, run

npm run build

to catch errors immediately. Fix any build errors before moving to the next improvement.

对于每个选中的改进项，遵循以下规则：

先处理Constants —— 将所有新配置值添加到
```
Constants.js
```
中。禁止硬编码值。
再处理事件 —— 使用
```
domain:action
```
命名规则，将新事件添加到
```
EventBus.js
```
中。
按需修改状态 —— 向
```
GameState.js
```
添加新的状态字段，并确保正确重置。
在对应目录创建新文件 —— 实体文件放在
```
entities/
```
，系统文件放在
```
systems/
```
，UI文件放在
```
ui/
```
。
通过协调器关联 —— 在
```
Game.js
```
中注册新系统，并确保生命周期正确。
使用EventBus进行通信 —— 模块之间禁止直接导入。
匹配现有代码风格 —— 与项目其余部分的模式、命名、格式保持一致。
不破坏现有功能 —— 除非改进项专门针对现有游戏玩法、控制或计分系统，否则需保证这些功能仍能正常运行。

完成每项改进后，运行

npm run build

以立即捕获错误。修复所有构建错误后再进行下一项改进。

Step 5: Verify

步骤5：验证

After all improvements are implemented:

Run
```
npm run build
```
— confirm clean build with no errors
Run
```
npm test
```
if tests exist — confirm all tests still pass
If tests fail because of intentional changes (new scenes, changed elements), fix the tests to match the new behavior
If the game has visual regression tests, update snapshots:
```
npm run test:update-snapshots
```

完成所有改进后：

运行
```
npm run build
```
—— 确认构建无错误
若存在测试，运行
```
npm test
```
—— 确认所有测试仍能通过
若因有意修改（如新场景、元素变更）导致测试失败，需修改测试以匹配新行为
若游戏有视觉回归测试，更新快照：
```
npm run test:update-snapshots
```

Step 6: Report

步骤6：报告

Tell the user what changed:

Improvement report

Score: X/65 → Y/65 (+Z points)

Implemented:

[Title] — [one-sentence summary of what changed]

[Title] — [one-sentence summary of what changed] ...

Files created: [list new files] Files modified: [list changed files]
How to test: Run
npm run dev
and try:
[specific thing to look for]

[specific thing to look for]
Next improvements: Run
/game-creator:improve-game
again to find the next batch.

告知用户修改内容：

改进报告

评分：X/65 → Y/65（提升Z分）

已实施改进：

[标题] —— [修改内容的一句话总结]

[标题] —— [修改内容的一句话总结] ...

创建的文件： [列出新文件] 修改的文件： [列出修改的文件]
测试方法： 运行
npm run dev
并尝试：
[需检查的具体内容]

[需检查的具体内容]
下一步改进： 再次运行
/game-creator:improve-game
以找出下一批改进项。

Focus areas

重点领域

When

$ARGUMENTS

includes a focus area keyword, weight these specific checks:

"gameplay" — core loop, controls, difficulty progression, enemy variety, power-ups, risk/reward, pacing, level design

"visuals" — load the game-designer skill and apply its full design audit (backgrounds, palette, animations, particles, transitions, typography, juice)

"performance" — delta capping, object pooling, geometry/material disposal, event listener cleanup, requestAnimationFrame usage, draw call count, texture atlas usage

"polish" — screen shake, hit pause, squash/stretch, easing curves, sound timing, button feedback, score popups, death animations, transition smoothness

"game-over" — game over screen appeal, restart flow, button styling, score display, best score display, animations. Button text must be visible — verify the

createButton()

pattern uses Container + Graphics + Text (Graphics first, Text second, Container interactive). If button labels are invisible, the pattern is broken. Note: games do not have title/menu screens by default (Play.fun handles the chrome). Only add a title screen if the user explicitly requests one. Score HUD is handled by the Play.fun widget — do not add a separate in-game score display. All game-over UI must be below

SAFE_ZONE.TOP

"audio" — load the game-audio skill. Check BGM coverage (every game state should have music), SFX coverage (every player action should have feedback), volume mixing, transition smoothness between tracks

"mobile" — touch input implemented (tap zones, virtual joystick, or gyroscope), responsive canvas (

Phaser.Scale.FIT

or CSS

width:100%

), 44px minimum touch targets, virtual joystick or tap zones for movement, gyroscope support for tilt games, no hover-only interactions, tested on mobile viewport (Pixel 5 emulation). Read

InputSystem.js

, all scene/system

update()

methods,

index.html

viewport meta, and

Constants.js

for touch target sizes.

"ux" — onboarding (does the player know what to do?), feedback (does every action have a response?), difficulty curve (is it too hard/easy?), replayability (is there a reason to play again?)

当

$ARGUMENTS

包含重点领域关键词时，会侧重以下特定检查：

"gameplay" —— 核心循环、控制、难度递进、敌人种类、道具、风险/回报、节奏、关卡设计

"visuals" —— 加载game-designer技能并应用完整的设计审计（背景、调色板、动画、粒子效果、过渡、排版、细节优化）

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

"polish" —— 屏幕震动、击中暂停、挤压/拉伸、缓动曲线、音效时机、按钮反馈、分数弹窗、死亡动画、过渡流畅度

"game-over" —— 游戏结束界面吸引力、重启流程、按钮样式、分数显示、最高分显示、动画。按钮文本必须可见——验证

createButton()

模式是否使用Container + Graphics + Text（先Graphics，后Text，Container设为可交互）。若按钮标签不可见，则该模式存在问题。注意：默认情况下游戏没有标题/菜单界面（由Play.fun处理相关框架）。仅当用户明确要求时才添加标题界面。分数HUD由Play.fun组件处理——请勿添加单独的游戏内分数显示。所有游戏结束UI必须位于

SAFE_ZONE.TOP

以下。

"audio" —— 加载game-audio技能。检查BGM覆盖范围（每个游戏状态都应有背景音乐）、SFX覆盖范围（每个玩家动作都应有反馈）、音量混合、曲目间过渡流畅度

"mobile" —— 已实现触摸输入（点击区域、虚拟操纵杆或陀螺仪）、响应式画布（

Phaser.Scale.FIT

或CSS

width:100%

）、最小44px触摸目标、用于移动的虚拟操纵杆或点击区域、倾斜类游戏的陀螺仪支持、无仅悬停交互、已在移动视口（Pixel 5模拟）测试。阅读

InputSystem.js

、所有场景/系统的

update()

方法、

index.html

视口元标签和

Constants.js

中的触摸目标尺寸。

"ux" —— 新手引导（玩家是否知道该做什么？）、反馈机制（每个动作是否有响应？）、难度曲线（是否过难/过易？）、重玩价值（是否有再次游玩的理由？）

Tips

提示

This command is designed for iterative improvement. Run it multiple times:

First pass: fix the biggest gaps (missing features, broken UX)

Second pass: add polish (particles, transitions, juice)

Third pass: fine-tune (difficulty curve, timing, balance)

Each run picks up where the last left off — previously fixed areas will score higher, surfacing new priorities.
For targeted work, use the focus area:
/game-creator:improve-game gameplay
or
/game-creator:improve-game visuals

该命令专为迭代式改进设计。可多次运行：

第一次运行：修复最大的漏洞（缺失功能、损坏的UX）

第二次运行：添加细节打磨（粒子效果、过渡、细节优化）

第三次运行：精细调整（难度曲线、时机、平衡）

每次运行都会承接上一次的结果——已修复的领域评分会更高，从而呈现新的优先级。
如需针对性工作，可指定重点领域：
/game-creator:improve-game gameplay
或
/game-creator:improve-game visuals