Game Design

必要に応じて Web 検索で情報を補完する。

Step 3: 自ゲームの現状調査

Explore agent を使って、検討対象に関連する自ゲームのシステムを調査する:

• 関連する型定義・データ構造
• 関連するコアロジック
• 既存の類似機構
• 現在のバランス値（定数・確率など）

参照すべきファイル群:

• Spec/ 配下の仕様書
• src/Lib/Types/ 配下の型定義
• src/Lib/Core/ 配下のコアロジック
• src/Lib/Data/ 配下のJSONデータ（武器、魔法、敵、レリック等）

Step 4: 構造的分析

以下のフレームワークで分析を整理する:

A. 機構のゲームデザイン的意義

• その機構が生み出す 意思決定 は何か
• プレイヤーの 感情曲線 にどう影響するか
• ゲームの リプレイ性 にどう貢献するか
• リスクとリターン のバランスはどうか

B. 自ゲームとの適合性

• 既存システムとの シナジー / コンフリクト
• 導入の 前提条件 は満たされているか
• バトルの テンポ に与える影響（コマンド選択の速度感、スマホ操作を考慮）
• 実装の 複雑度 と得られる体験の 価値 のバランス

C. 判断と代替案

• 導入推奨 / 保留（条件付き）/ 不要 のいずれか
• 保留の場合: 将来導入する際の前提条件
• 代替案: より軽量に同じ効果を得られる方法

Step 5: 結果の保存

分析結果を Spec/DesignNotes/ に Markdown で保存する。

ファイル名: 検討対象を端的に表す英語名（例: ElementSynergy.md, RelicBalance.md, NewSpellDesign.md）

テンプレート:

# [検討対象の名前]

## ステータス: [導入推奨 / 保留 / 不要]

[1-2行の概要]

---

## 参考元の分析（他ゲーム参照がある場合）

### [ゲーム名]の[機構名]

- 概要
- ゲームデザイン的意義
- 機能するための前提条件

---

## 自ゲームの現状

- 関連する既存システム
- 現在の課題

---

## 分析

### 意思決定の質

...

### テンポへの影響

...

### 適合性

...

---

## 判断

### 結論: [導入推奨 / 保留 / 不要]

理由:

1. ...
2. ...

### 導入する場合の具体案（該当する場合）

...

### 保留条件（該当する場合）

...

### 代替案（該当する場合）

...

Step 6: ユーザーへの報告

保存したファイルパスと分析の要点をユーザーに報告する。

分析の観点チェックリスト

分析時に漏れがないよう、以下を確認する:

• 意思決定: プレイヤーに意味のある選択が生まれるか
• テンポ: コマンドバトルとしてのテンポを損なわないか（コマンド選択の速度感）
• 複雑度: 理解・操作の複雑さは適切か（新規プレイヤーが混乱しないか）
• 既存との整合: 現在のシステム（コマンド体系、アイテム、敵システム、属性相性）と矛盾しないか
• 実装コスト: 得られる体験に対して実装コストが見合うか
• スケーラビリティ: アイテム数や敵種類の増減に対して柔軟か
• 支配戦略: 常に最適な選択肢が1つに収束し、他の選択肢が死に選択肢にならないか
• 分析麻痺: 選択肢や情報が多すぎてプレイヤーが判断できなくならないか（特にスマホの短時間プレイを考慮）

注意事項

• このスキルはゲームデザインの 検討・分析のみ を行う。コードの実装は行わない
• 分析は常に このゲーム固有のコンテキスト （コマンド式バトル、ローグライト要素）を考慮する
• 他ゲームの機構をそのままコピーするのではなく、本ゲームに適した形を検討する
• 判断が難しい場合は「保留」とし、条件を明示する