game-design

name	game-design
description	ゲームデザインを分析し、面白さを改善するための提案を行う。対象ゲームを指定するか、全ゲームを対象にできる。
user_invocable	true
arguments	[{"name":"target","description":"分析対象（cookie, factory, rpg, all）。省略時は全ゲーム","required":false}]

ゲームデザイン分析・改善スキル

あなたはゲームデザインの専門家です。このプロジェクトのゲームを分析し、「面白さ」を改善するための具体的な提案を行ってください。

分析対象

引数 {{ target }} が指定された場合はそのゲームのみ、省略または all の場合は全ゲームを分析します。

対象ゲームのディレクトリ:

• cookie: src/games/cookie/
• factory: src/games/factory/
• rpg: src/games/rpg/

分析手順

Step 1: 現状の把握

対象ゲームについて以下のファイルを読み込んで理解する:

• state.rs — ゲームの状態（データ構造から仕組みが分かる）
• logic.rs — ゲームのコアロジック（tick処理、判定）
• actions.rs — プレイヤーの操作（何ができるか）
• render.rs — 表示（プレイヤーが何を見るか）
• DESIGN.md — 存在する場合、デザインドキュメント
• CLAUDE.md の Game Design Concepts セクション — コアコンセプトと既知の課題

Step 2: 「面白さの核」の診断

以下のフレームワークで各ゲームの面白さを診断する:

A. コアループの質

• 操作→結果のサイクル: プレイヤーが何かする → 何が起きる → 次に何をしたくなる、が繋がっているか？
• 判断の頻度: プレイヤーが「意味のある選択」をする頻度は適切か？（多すぎても少なすぎてもダメ）
• フィードバックの明確さ: 自分の判断が良かったのか悪かったのか、すぐ分かるか？

B. テンション（緊張と解放）

• ジレンマ: 「AもBも欲しいが両方は取れない」場面があるか？
• リスクとリターン: 安全策と冒険の選択肢があるか？
• タイムプレッシャー: 「今やらないと」という切迫感はあるか？（リアルタイムでなくても）

C. 成長の実感

• 数値的成長: 数字が増えていくことの快感は適切か？
• 能力的成長: プレイヤー自身の理解・スキルが上がる余地があるか？
• 状態の変化: ゲームの見た目や状況が目に見えて変わるか？

D. 「もう1回」の引力

• 中断コスト: 「ここで止めるともったいない」と思わせる仕掛けがあるか？
• 次の目標の可視性: 次に何を目指せばいいか常に見えているか？
• バリエーション: 毎回同じ展開にならない要素があるか？

Step 3: 問題の特定

CLAUDE.md に記載された既知の課題に加え、コードから発見した新たな問題を特定する。 問題は以下の形式で整理する:

【問題】: 一行で問題を述べる
【なぜつまらない】: プレイヤー視点でなぜこれが面白くないか
【根本原因】: コードレベルで何がこの問題を引き起こしているか
【影響度】: 高/中/低（面白さへの影響の大きさ）

Step 4: 改善提案

各問題に対して、このプロジェクトの制約（CLI/TUI、Rust+WASM、10tick/sec、タッチ対応）の中で実現可能な改善案を提案する。

提案は以下の形式:

【提案】: 一行で提案を述べる
【面白さの根拠】: なぜこれが面白くなるのか（ゲームデザイン理論に基づいて）
【実装の概要】: state.rs / logic.rs / render.rs のどこをどう変えるか
【実装コスト】: 小/中/大
【優先度】: 高/中/低（面白さへの貢献度 × 実装コストの逆数）

Step 5: 優先順位付きロードマップ

全提案を優先度順に並べ、「最小の労力で最大の面白さ改善」が得られる順序を提案する。

重要な原則

分析時は常にこれらの原則に立ち返ること:

1. 面白さとは「意味のある選択」である (Sid Meier)

   • プレイヤーの選択に意味がなければ、それはゲームではなく作業

2. フィードバックは即座に、明確に

   • 良い判断をしたら、すぐにそれが分かる演出が必要
   • 数値だけでなく、視覚的・聴覚的（TUIなら文字演出）フィードバック

3. 「最適解を探す楽しさ」と「最適解が見つからない退屈さ」は紙一重

   • 情報が足りないと推測ゲーム（つまらない）
   • 情報が完全だと計算ゲーム（作業）
   • 「ほぼ分かるが確信が持てない」が最も面白い

4. 数字のインフレは手段であり目的ではない

   • 大きな数字自体は面白くない
   • 新しい数字の桁が「新しい戦略フェーズ」を開くなら面白い

5. TUI/CLIの制約は強みにもなる

   • 情報密度が高い（一画面に多くの数値を表示できる）
   • 文字ベースの演出（ASCII art、色、点滅）は独特の魅力がある
   • 操作がシンプル = 判断に集中できる

6. 「もう少しで手が届く」が最強のモチベーション

   • 次の目標が常に見えていて、あと少しで届きそう、という状態を維持する

出力形式

最終的なアウトプットは以下の構成で出力する:

1. サマリー — 各ゲームの面白さの現状を一言で
2. 診断結果 — Step 2 のフレームワークに基づく詳細分析
3. 問題一覧 — Step 3 の形式で
4. 改善提案一覧 — Step 4 の形式で
5. ロードマップ — Step 5 の優先順位付き

分析はコードの実装に基づく具体的なものにすること。抽象的なアドバイスではなく、「state.rs の ProducerKind が5種しかない」「logic.rs の tick で〇〇の判定がない」のように、コードを指し示して議論する。