evaluating-gameplay-balance

このスキルを使って、ゲームが熟練したプレイに報いるかを分析し、構造的な改善案を提案します。

エンジンに依存しない契約：

• 単調な方針と探索的な方針の実行結果を比較できるようにします。
• 公開入力スキーマと、方針が利用できる可視状態の特徴を定義します。
• シード、ティックレート、最大時間、方針の定義、探索予算、集計ロジックを、実行間で比較可能な状態に保ちます。
• スコア、経過時間、終了状態、死亡、スポーン、得点、入力、使用状況に関するテレメトリーを記録します。使用状況とは、実際のプレイがどのようなもので構成されているかを指します。アクションとスコアのうちコアメカニクスに由来する割合、プレイ空間のどの部分が占有されているか、各脅威が発動し命中する頻度を記録します。
• ゲームに生き残ること以外の目標がある場合は、目標を無視する方針も比較に加えます。スコアを稼ぎ続けるために足止めする方針と、目標を追わずに生き残る方針をそれぞれ用意します。足止めのほうが高得点になる場合、それは上限、コスト、実行全体への影響を調べるべき兆候ですが、それ自体が欠陥というわけではありません。
• exploratory_ratio = exploratory.best.score / monotonous.max_score を計算します。
• この比率は品質を検出する指標として扱い、最適化の目標にはしません。
• ベースライン以外のすべての方針について、可視状態の特徴とともに実行プロファイルを明記します。実行プロファイルは oracle（隠れた情報の利用を許可。上限値）、precise（可視状態を使用し、ほぼ完璧なタイミングと注意力を備える）、または human-limited（可視状態に加え、references/simulation-harness.md に記載された人間の制約を考慮）のいずれかです。oracle と明記されていない限り、探索ベースのランナーも含め、precise 方針から比率を計算します。この比率が検出するのはエクスプロイトであり、難易度ではありません。
• 難易度、タイマー、ペース配分、進行の目標値は human-limited の実行結果だけに基づいて設定し、すべての結論に、それが依拠するプロファイルを明記します。human-limited の実行結果がない場合は、難易度やペース配分について判断せず、未測定と報告します。
• 戦略が優位である、またはトレードオフのバランスが取れているという主張には、検証に使用したプロファイルを明記します。プロファイル間で順位が逆転しても、それだけでバランス上の欠陥とはなりません。スキル依存として報告しますが、各プロファイルで最善の戦略に対して、引き続き体験上のガードレールを適用します（human-limited で最適な行動が放置や待機になる場合は欠陥です）。

非決定論的なハーネス：

上記の契約は、シードを指定できるフォワードモデルを前提としています。実際のブラウザーを実時間で動かす場合、RNG を制御できないエンジンを使う場合、ライブレンダリングに対して方針を比較する場合など、一部の環境ではこれを用意できません。まずシードを指定することを優先してください。それが本当に不可能な場合は、以下の方法に切り替えます。これを省略すると、ノイズに基づく誤った確信を伴う結論が導かれます。

• 各方針を n ≥ 3 回実行し、最小値から最大値までの範囲を報告してください。単一の実行結果からは、裾の長い分布におけるどちらの方針についても何も証明できません。
• 範囲が 変化したと主張するには、n ≥ 5 とし、記録済みの以前の範囲と重複しないことを条件とします。以前の範囲と重なるサンプルは、その仕組みを説明できそうなもっともらしい理由があっても、知見とはみなしません。
• 既知の裾を含め、承認済みの範囲をプロジェクトの仕様に記録し、後続の実行で同じばらつきを再発見するのではなく、過去の結果と比較できるようにします。ある方針が、一定割合の実行で問題に見える値に達することが知られている場合（例：「アイドル実行の約 20 % は、フィールドが自然に縮小するため、意図どおりスキルプレイのスコアの 0.18 に達する」）、その裾は記録済みの既知の結果として扱い、現れるたびに再検討しません。
• 結論の撤回は正当であり、期待される対応です。 少ないサンプルから公表した結論が、より多くのサンプルで裏付けられない場合は、その場で撤回します。仕組み自体が実在したなら、それは残したうえで、その効果量はノイズと区別できなかったと明記します。実例：因果関係の筋の通った説明を添えて n=4 で公表された範囲の変化は、プロジェクトがすでに 2 回記録していたのと同じばらつきだと n=6 で判明し、撤回されました。 プレイ体験のガードレール：
• 指標が改善しても、プレイ体験を損なう変更は却下します。
• ゲーム内の因果イベントのみをスコア対象とし、生の入力情報にはポイントを付与しません。
• ゲームオーバーは、ハザードまたはワールド状態の崩壊に結び付けます。
• テストエージェントにだけ有利または不利になる隠れた挙動を追加しません。
• 数値だけの調整、分岐だけの修正、主な解決策としてのランダム性の追加は避けます。
• 人間の制約を反映したプロファイルの調整データとして、実際のプレイ（ゲームが記録する場合はリプレイ、それ以外の場合は実行サマリー）を扱います。リプレイは、プレイ時に適用されていたルールに関する読み取り専用の証拠です。ルール変更後にリプレイを再生成または移行してはいけません。また、その人がプレイしていないルールに基づいてポリシーを再調整してはいけません。レポートがシミュレーション結果と食い違う場合は、まずハーネスの不具合を確認し、次にレポートに合わせてプロファイルを調整して再実行し、その調整を記録します。ボットのデータだけを根拠にレポートを退けてはいけません。食い違いは逆方向にも起こります。プレイヤーより成績が低いポリシーには、判断の弱さや制限の厳しさが過剰な問題がある可能性があります。どちらを調整するか決める前に、レポートにある進捗や失敗原因をポリシーのものと比較してください。references/simulation-harness.md の プレイレポートに基づく調整 に従ってください。
• そのパラメーターによって挙動が定義されるポリシーを使って、そのパラメーターを調整してはいけません（例：「タイマーが 80 % を超えている間は待つ」）。調整すると測定値も変化してしまいます。

ワークフロー：

1. 既存のシミュレーションハーネスを探します。ない場合は、バランスを評価する前にハーネスの契約に従って設計します。
2. 比較プロトコルを選択します：
   • シードを利用できる場合は、同じ決定論的シードを使い、比較可能な単調なポリシーと探索的なポリシーを実行します。
   • シードを本当に利用できない場合は、上記の非決定論的なバンドプロトコルを使用し、実行回数、実時間の計測時間枠、ポリシー定義、サンプリング間隔を同等に保ちます。
3. レポートに実行設定に加えて、死亡、スポーン、スコア、入力、使用状況のテレメトリーが含まれていることを確認します。
4. テレメトリーが不完全な場合は、不足項目を報告し、スコアだけでバランスを判断するのではなく、計測の追加または再実行を依頼します。
5. ゲームを分析する前に、単純でないポリシーが妥当かを確認します（references/simulation-harness.md の シミュレーションプレイヤーの妥当性チェック を参照）。チェックに失敗した場合はハーネスの不具合です。結論を出すのではなく、ポリシーを修正して再実行し、不具合を報告します。これには上限チェックも含まれます。強力なポリシーの成績が人間の制約を反映したポリシーと変わらない場合は、まず指標の飽和と、精度を報いる設計になっていないゲームを除外し、そのうえで、ポリシーが弱いと結論付ける前に、人間なら避けられる失敗を調べます。
6. 死亡、スポーン、スコア、入力、使用状況のパターンを分析します。スコア比を確認する前に、使用状況を設計で定めた中心的な操作と照らし合わせます。スコア比が健全でも、プレイヤーが中心的なメカニクスに時間を費やしているとは限りません。
7. ルールまたは生成ロジックにおける根本原因を特定します。
8. 期待される影響、リスク、複雑さを含め、少なくとも 3 つの修正候補を提案します。
9. 実装後は、同じポリシー、予算、集計方法、比較プロトコルを使用して再テストします。決定論的な実行では同じシードを維持し、非決定論的な実行では同じ実行回数とサンプリング設定を維持します。 レポートに ratio.diagnostic が含まれる場合のプロジェクトチェッカーによるトリアージ：

• 以下のいずれかの判定を適用する前に、最終スコアの比較とは独立した証拠に基づいて、評価手段の信頼性を確認してください。探索的検索が実際にゲームをプレイしたことを明確に示す場合に限り、判定は信頼できます。具体的には、検索の反復を通じて最高スコアが向上しており、最初から横ばいではなかった場合、または単調な方策では一度も利用されなかったスコア獲得機会やゲームの仕組みを、検索実行が利用していた場合です。いずれの兆候もない場合は、結果を設計に関する証拠ではなく、評価手段の失敗（検索器が巧みなプレイを見つけられなかった）として扱い、再設計や構造的な修正には着手せず、人間または LLM によるレビューに回してください。レポートに検索履歴や行動状況のテレメトリーがなく、判断できない場合は、その不足を報告し、判定を適用するのではなく、計測機能の追加を依頼してください。
• mono_dominant：単調な方策が探索的プレイを上回っています。入力とスコア獲得のテレメトリーを調べ、トレードオフの欠如、繰り返し利用できるスコア獲得手段、安全なスコア獲得、または生の入力への報酬がないか確認してください。現在の README の不変条件で、放置、ボタンの押しっぱなし、安全な待機が優位になることを防げていない場合、これは設計上の問題です。その旨を報告し、呼び出し元が README を改訂して再実装できるようにしてください。それ以外の場合は、構造に関するコードレベルの修正（入力状態、ターゲットごとの処理、リソース、クールダウン、リスクに応じたスコア設定）を優先してください。
• tied：探索的プレイが単調なベースラインを実質的に上回れていません。テレメトリーから、単一の不公平なハザードが両方の方策を妨げていることが明確に示されている場合を除き、これは設計上の問題です。設計上の問題として報告し、呼び出し元が README を改訂して再実装できるようにしてください。根本的に欠陥のあるゲームメカニクスに対して、コードレベルの修正を試みないでください。
• marginal：探索的プレイが上回ってはいますが、差は十分ではありません。特定できるコードレベルの原因があるか（実装上の問題）、スコア設定やトレードオフの構造自体が欠けているか（設計上の問題）を判断してください。実装上の問題であれば、生のスポーン数や速度に手を加える前に、リスクに応じたスコア設定、コンボがリセットされる原因、スコアの規模、より明確なスコア獲得機会を優先してください。

断念基準：根本原因の修正にコアエクスペリエンスの変更、またはタグとの関係性の破棄が必要な場合、あるいは改善の試行をすでに 3 回使い切っている場合は、その設計はフレームワークの制約内では救済できないと報告し、無理に再設計を続けるのではなく、失敗レポートの作成を推奨してください。同じスラッグのまま新しいゲームを作り、ゲートを通過させるような修正を提案しないでください。

このスキルが選定プロセス内で実行される場合、つまり候補を多数生成して順位付けや除外を行い、修正しない場合は、失敗レポートの手順は適用されません。診断を報告し、順位付けによってその成果物を除外できるようにしてください。修正の試行回数と 3 回の上限は、選定後の採用候補にのみ適用してください。

テレメトリーが要約されている、または不足している場合は、編集前に、対象を絞った最小限のプローブを依頼するか追加してください。有用なプローブの例：死亡を引き起こしたハザードの ID／種類／経過時間と、プレイヤーの入力時間枠、スポーン位置と安全距離、スコア獲得理由／ターゲット ID／リスク状況、スコア獲得や死亡前後の入力頻度、アクティブなエンティティ数、ユニークな機会ごとのスコア、発生源ごとのアクション数とスコア、プレイ空間の各領域で費やした時間、脅威ごとの発射数と命中数、主要な脅威が存在しない最長時間などです。

必要に応じて、以下のリファレンスを参照してください：

• references/simulation-harness.md は、決定論的シミュレーター、入力方策、実行プロファイル、健全性チェック、テレメトリー出力器の設計について説明しています。
• references/log-contract.md は、エンジンに依存しないテレメトリースキーマについて説明しています。
• references/improvement-analysis.md は、分析の視点とレポートのテンプレートについて説明しています。
• references/balance-patterns.md は、構造的なバランス調整のパターンについて説明しています。
• references/godot-implementation-notes.md は、一般的なバランス調整を Godot／GDScript に反映する方法について説明しています。

関連スキル

• Godot プロジェクトでは、プロジェクトのセットアップに scaffolding-godot-mini-games を、シミュレーターの実行、テスト、ログ、エクスポートの確認に running-headless-godot を使用します。
• このスキルが担当するのは、測定、調整、人間らしいポリシーです。いつ何を尋ねるか、また、調査結果、プレイメモ、プレイヤーの提案にどう対応するかは呼び出し元の担当です。プレイセッションで得られた測定以外の項目は、変更せずに呼び出し元へ返してください。
• ルールに関わる構造的な修正は、数値の調整ではなく、デザインの変更です。デザインを見直さずに数値をひそかに再調整してはいけません。