Review Game

Performance Notes

• Take your time to do this thoroughly
• Quality is more important than speed
• Do not skip validation steps

Review Game

Analyze an existing game codebase and provide a structured review. This is the final step in the pipeline — it checks everything is wired up correctly and gives you a quality score.

Instructions

Analyze the game at $ARGUMENTS (or the current directory if no path given).

Step 1: Identify the game

• Detect the engine (Three.js, Phaser, or other)
• Read package.json for dependencies and scripts
• Read the main entry point and index.html
• Identify the game concept/genre

Step 2: Architecture Review

Check for these required patterns and report compliance:

• EventBus: Is there a centralized event system? Are modules decoupled?
• GameState: Is there a centralized state singleton?
• Constants: Are config values centralized or scattered as magic numbers?
• Orchestrator: Is there a main Game class that initializes everything?
• Directory Structure: Is code organized into core/systems/gameplay/ui/level layers?
• Event Constants: Are events defined as named constants or raw strings?

Step 3: Performance Review

Check for common issues:

• Delta time capping: Is getDelta() capped to prevent death spirals?
• Object pooling: Are temp objects reused in hot loops?
• Resource disposal: Are Three.js geometries/materials/textures disposed?
• Event cleanup: Are event listeners cleaned up on scene transitions?
• Asset loading: Are assets preloaded with progress feedback?

Step 4: Code Quality

• No circular dependencies: Modules flow one direction
• Single responsibility: Each module has one clear job
• Error handling: Event handlers wrapped in try/catch
• Consistent naming: Events use domain:action, files use PascalCase

Step 5: Monetization Readiness

• Points system: Is there a scoring/points mechanism?
• Session tracking: Can game sessions be identified?
• Anti-cheat potential: Is score validation server-side or at least structured for it?
• Play.fun integration: Any existing SDK integration?

Output Format

Provide a structured report with:

1. Game Overview - What the game is, tech stack, game loop
2. Architecture Score (out of 6 checks)
3. Performance Score (out of 5 checks)
4. Code Quality Score (out of 4 checks)
5. Monetization Readiness (out of 4 checks)
6. Top Recommendations - Prioritized list of improvements with plain-English explanations
7. What's Working Well - Positive findings

Example Usage

/review-game examples/flappy-bird

Result: Architecture 6/6, Performance 4/5, Code Quality 4/4, Monetization 2/4 → Top recommendations: add Play.fun SDK, add object pooling for pipes, add delta time capping. Positive findings: clean EventBus usage, proper GameState reset, well-organized directory structure.

Next Step

Tell the user:

Your game has been through the full pipeline! Here's what you have:

• Scaffolded architecture (/viral-game)
• Visual polish (/design-game)
• Music and sound effects (/add-audio)
• Automated tests (/qa-game)
• Architecture review (/review-game)

(Reflects the /viral-game one-shot pipeline. If you're working through /make-game, the equivalent state is "post-scaffold-phase + first development milestone shipped".)

What's next?

• Add new gameplay features with /game-creator:add-feature [description]
• Deploy to the web — run npm run build && ~/.agents/skills/here-now/scripts/publish.sh dist/ for instant hosting, or use GitHub Pages, Vercel, Netlify, itch.io
• Keep iterating! Run /design-game, /add-audio, or /review-game again anytime after making changes.