game-balance

ゲームバランス

バランス調整とは、定められたプレイヤー、状況、時間軸において、意図した体験を実現するために数値やルールを調整することです。すべての選択肢を同等にすることではありません。

エンジンに依存しない方針を保ってください。調整可能な入力値、数式、前提、シナリオ、チェック項目は、確認可能な成果物にまとめてください。モデルと根拠が明確になってから、実装方針を記述してください。

基本原則

• 好みの数値ではなく、測定可能な設計目標から始めます。
• バランスに関する主張にはすべて、対象集団、スキル帯、状況、時間軸を明記します。
• 意味のある違いを保ちます。選択肢の期待値が等しくても、リスク、タイミング、情報、実行負荷、状況への適合性は異なる場合があります。
• プレイヤーの選択は、その選択肢が利用可能で、理解され、実用に値する場合にのみ、根拠として扱います。
• 生の入力値、派生指標、プレイヤー向け表示値、観測された結果は分けて管理します。
• 共通パラメーターは一元管理します。同じバランス定数を複数の数式に直接入力しないでください。
• 大規模なオブジェクト群の比較には基準となる支点を用い、特異な相互作用は相互に検証します。
• 慣習ではなく、望ましい限界変化に基づいて曲線の形状を選びます。
• 経済は価格表ではなく、時間経過に伴うフローとストックとして分析します。
• ランダムな結果は、期待値だけでなく、分布とテールリスクに基づいて分析します。
• まず決定論的なチェックを行い、相互作用や確率的な挙動にはシミュレーションを、体験の評価にはプレイテストを、大規模な行動分析にはテレメトリーを使います。
• 一度に変更するのは、因果関係のある調整要素または一貫した調整要素のまとまりに限り、ロールバック手段を確保します。

事前調査

値を変更する前に、既存のルール、スプレッドシート、データエクスポート、コード／設定、テスト結果、シミュレーション、テレメトリーの定義を確認します。以下を明確にしてください。

• バランスに関する問いと、観測された症状。
• 目指すプレイヤー体験と、成功の定義。
• プレイヤーの区分、スキルレベル、モード、マップ、遭遇、進行段階。
• 関連する時間軸：アクション、遭遇、セッション、日、シーズン、ライフタイム。
• 候補となる選択肢と、それぞれが利用可能になるタイミング。
• 属性、数式、依存関係、単位、範囲、丸め処理、上限。
• 現在の信頼できる唯一の情報源とデータパイプライン。
• 利用可能な根拠と、そのサンプルや状況に関する制約。
• 制作、公平性、アクセシビリティ、ビジネス、法務上の制約。

情報が不足している場合は、前提にその旨を明記し、前提を置き換えられる最小限の計測または実験を設計してください。

ワークフロー

1. バランス調整の契約を記述する

検証可能な記述を使います。

For [player segment] in [context] over [horizon],
[primary metric] should remain within [target range],
while [guardrail metrics] remain within [ranges].
We will change [decision] if [evidence threshold] is crossed.

有効な目標の指標には、解決までの時間、スキル帯別の成功率、状況別の選択肢の多様性、立て直しの機会、進行にかかる時間、リソースの余剰、報酬が得られない期間、理解しやすさの実感などがあります。

特に理由がない限り、選択率を等しくしたり、勝率を50％にしたりすることを目標にしないでください。その目標がゲームの目的に合う理由を説明してください。

2. 比較する状況を定義する

値を比較できる条件を列挙します。

• プレイヤーのスキルと知識。
• 対戦相手またはチャレンジの特性。
• マップ、射程、チーム人数、モード。
• 開始時のリソースと恒久的な強さ。
• 入力方法、レイテンシー、実行に関する前提。
• 継続時間と終了条件。

互換性のない状況をまとめた全体平均は、バランスの結果ではありません。まず区分し、その後で集計します。

3. 属性モデルを構築する

各オブジェクトと属性について、意味、単位、有効範囲、出典、表示の有無、変更可能性、それを使用するメカニクスを定義します。属性を次のように分類します。

• 入力：直接調整する値。
• 派生：入力値から算出する値。
• コンテキスト：シナリオから与えられる値。
• 結果：プレイまたはシミュレーションから測定される値。
• 表示：プレイヤー向けに丸める、または変換する値。

バランス調整の概要、ワークブックの構成、属性ワークシート、正規化、支点、数式、曲線、元の実例については、定量モデリングを参照してください。

4. スプレッドシートまたはモデルを構成する

最低限、次の項目を分けます。

1. はじめに、前提条件、単位、変更履歴。
2. パラメーターと名前付き定数。
3. エンティティの入力値。
4. 曲線とルックアップテーブル。
5. 派生計算。
6. 代表的なシナリオ。
7. 不変条件とエラーチェック。
8. 結果、分布、グラフ。
9. シミュレーションまたはプレイテストの生データのインポート。

比較可能なオブジェクトごとに1行を割り当て、属性ごとに1列を割り当てます。入力の型と範囲を検証してください。デバッグ中は中間計算を表示したままにし、検証後にのみ非表示にするかグループ化します。

5. 範囲と基準点を設定する

単位の異なる値を正規化して比較します。

normalized = clamp((value - minimum) / (maximum - minimum), 0, 1)
value = minimum + normalized * (maximum - minimum)

代表的で、意図的に平凡なオブジェクトまたはシナリオを基準点として選びます。その周囲に一連のバリエーションを作る前に、よくある状況で検証してください。

各バリエーションは、生の属性値の合計ではなく、成果指標を使って基準点と比較します。重み付きスコアが等しいことは仮説であり、証明ではありません。極端なケース、カウンター、組み合わせ、基準点とはルールが異なる選択肢を相互にテストしてください。

6. 限界効果に応じて曲線を選ぶ

合計値と、ステップごとの変化量の両方を確認します。

• 線形：絶対増加量が一定です。
• 指数：比例増加量が一定です。複利や急激に上昇するコストに使用します。
• べき乗曲線：加速または減速の度合いを調整できます。
• 飽和曲線または対数曲線：初期の増加が大きく、その後は逓減します。
• 区分曲線：明示的な移行点を設けた複数の段階で構成されます。

最初、中間、最後、上限を超えた値を確認します。曲線、そのステップごとの差分、獲得または撃破にかかる時間をプロットしてください。内部精度と表示時の丸めを分けて扱います。

7. 相互に絡み合う属性をモデル化する

比較する前に、依存関係のある属性を成果指標に置き換えます。よくある例を次に示します。

throughput = amount_per_action * actions_per_second * success_probability * uptime
time_to_goal = required_amount / net_gain_rate
expected_damage = hit_probability * damage_on_hit
effective_durability = health / (1 - damage_reduction)

リロード、ダウンタイム、オーバーキル、対象の耐性、移動、リソース制限、プレイヤーの操作について、前提条件を明示してください。単一の複合スコアはスクリーニングに役立ちますが、瞬間火力、ばらつき、射程、制御、チームへの有用性が見えなくなることがあります。

8. 経済とランダム性をモデル化する

経済と確率を使って、流入源、流出先、蓄積、変換、購入可能性、重み付き結果、期待値、分散、連続して成果が得られない状況、依存イベントを整理します。

経済については、関連するプレイヤー時間の単位ごと、および進行度別の集団ごとに、純流量を計算します。インフレ、停滞、ため込み、必須の維持費、富の集中を確認してください。

ランダムシステムについては、結果の確率、期待報酬、ばらつき、パーセンタイル、失敗が繰り返される確率、依存関係を計算します。保証や段階的に上昇する確率は、独立した抽選ではなく、状態を持つシステムとしてモデル化してください。

9. 決定論的な極端なケースを確認する

シミュレーションや人によるテストの前に、次の点を検証します。

• 最小値、最大値、ゼロ、上限、上限を1つ超えた値。
• 空および満杯の蓄積量。
• 合法な範囲内での最速および最遅のレート。
• 同時発生イベントと同点の解決方法。
• 丸め境界。
• 不可能または無効な入力の処理。
• 最良のコンボ、最悪のコンボ、自己維持するループ。
• ゼロからの開始と赤字からの回復の挙動。

隔離されたコピーで、意図的に異常な値をテストしてください。極端なテストでは、隠れた依存関係やエンジンまたはルールの制限をすばやく見つけられます。

10. 相互作用する結果をシミュレーションする

状態、方針、依存関係、または繰り返し発生するランダム性により解析式が扱いにくくなる場合は、シミュレーションを使います。シミュレーション、テレメトリー、調整に従ってください。

エージェントの方針とスキルに関する前提を明示します。複数の決定論的シードで実行し、分布と信頼度を報告するとともに、単純なケースを解析的に検証してください。シミュレーション上のエージェントが選んだ選択肢から証明できるのは、その方針にとって何が最適かだけです。

感度スイープを使って、結果に最も大きく影響する入力と、結論を逆転させる相互作用を特定します。

11. 判断のトレードオフをプレイテストする

モデル出力が近いかどうかだけでなく、プレイヤーがトレードオフを認識し、活用できるかをテストします。

次の項目を観察します。

• 選択にかかる時間と比較の行動。
• 選択肢の提供状況とコンテキストに応じた選択割合。
• 条件の変化に伴う戦略の切り替え。
• 一貫した理由に裏付けられた意見の相違。
• 一度も検討されない、または一度使っただけで選ばれなくなる選択肢。
• 予測精度と公平だと感じられるかどうか。
• 悪い結果の後の立て直し方。

初めてプレイする人は、選択肢のわかりやすさをテストします。経験豊富なプレイヤーは、奥深さと最適化の可能性をテストします。混乱と、よく考えた末のためらいは区別してください。

12. スケールする前にテレメトリーを計測する

各指標について、それが判断にどう役立つのか、イベント、プロパティ、分母、コホート、保持期間を定義します。結果を正しいルールに帰属できるよう、ビルドとバランスデータのバージョンも含めます。

行動だけでなく、選択の機会も記録します。その選択肢が提示されていない、または購入可能でなかった場合、選択率に意味はありません。経済取引や遭遇の前後で、関連する状態を記録します。

必要なデータだけを収集し、適切な同意とプライバシー保護の慣行に従ってください。また、単一の集計指標からプレイヤーの意図を推測しないでください。

13. 実験として調整する

調整を行うたびに、次の手順に従います。

1. 診断した原因を明確にします。
2. その原因に影響を与えられる、影響度が最も低い調整項目を選びます。
3. 主指標とガードレール指標の変化を予測します。
4. 変更する調整項目を1つにするか、切り離せない調整項目のまとまりにします。
5. モデルと不変条件を再計算します。
6. 決定論的なケースと固定シードのシミュレーションを再実行します。
7. 必要に応じて、プレイテストを行うか、対象を限定したコホートにリリースします。
8. 前のバージョンやセグメントと比較します。
9. 維持、修正、ロールバック、または追加の証拠収集を決定します。
10. 判断を記録し、信頼できる情報源を更新します。

診断シグナル

• 圧倒的に強い選択肢： 表向きの数値を弱体化する前に、コンテキストを調整した結果、情報面での優位性、実行コスト、入手可能性、シナジーを確認します。
• 使われない選択肢： まず見つけやすさと利用条件を確認し、そのうえで状況に応じた見返りと認知コストを比較します。
• スノーボール： 現在の優位性が、今後の獲得、妨害、情報、または行動能力をどのように変化させるかを測定します。逓減、露出、維持費、別の価値獲得経路、または立て直しの機会を追加します。
• 失敗の連鎖： 損失によって行動に必要なリソースが失われる地点を特定します。最低限の水準を維持するか、コストはかかるものの現実的な立て直しの道筋を用意します。
• 作業の繰り返し： 目標達成までの時間と、一定期間あたりの意味のある判断の回数をグラフにします。繰り返しを減らし、獲得量やコストの曲線を調整するか、戦略的に異なる経路を追加します。
• インフレ： コホートごとの供給源と消費先の割合、保有量のパーセンタイル、価格変動、購入の関連性を比較します。
• 停滞： 希少性や恐れによって、貯蓄するほうが常に支出するより望ましくなっていないか確認します。
• RNGへの不満： 告知された確率や平均報酬だけでなく、失敗の連続回数や報酬が得られない期間のパーセンタイルを調べます。
• モデルとプレイの不一致： 抜けている制約、プレイヤーの実行、フィードバック、コンテキストの構成、実装時の丸め処理を監査します。
• 集計結果の矛盾： スキル、進行度、マップ、モード、パーティー、ビルド、露出状況ごとにセグメント化します。
• テレメトリーの急変： それをデザインに起因すると判断する前に、スキーマ、バランスのバージョン、プレイヤー構成、イベントが発生する機会、計測方法を確認します。

失敗モード

• 測定可能な基準を定めずに調整する。
• バランスが取れていることを、同一であることや人気が等しいことと同一視する。
• 意思決定や結果に影響しない生の属性を追加する。
• 正規化や文脈を考慮せず、単位の異なる値を比較する。
• 加重スコアを、性能が等しいことの証明として扱う。
• 限界変化や時間コストを無視して、見た目だけで曲線を選ぶ。
• 繰り返し使う定数をワークブック全体にハードコードする。
• 末尾部分、外れ値、混合コホートを覆い隠す平均値を使う。
• 依存関係のあるランダムイベントや確定的なランダムイベントを、独立したものとして扱う。
• 非現実的な方針をシミュレーションし、その結果をプレイヤーの行動と呼ぶ。
• 関係のない値を複数同時に変更し、原因の特定を不可能にする。
• 全体に適用する乗数で局所的な症状を修正する。
• 意思決定、分母、バージョンを定めずにテレメトリーを収集する。
• 間違った行動を測定している統計的に精密なデータを信頼する。
• ゲームの公平性に関する約束に反する、非公開の動的難易度調整を実装する。
• 早い段階で丸め、モデルと実装の間に累積的なずれを生じさせる。

必須成果物

ユーザーがより限定的な成果物を求めていない限り、次のものを作成します。

• バランス基準、プレイヤーセグメント、コンテキスト、対象期間、ガードレール。
• 単位、範囲、管理者、計算式を含む属性／データ辞書。
• 集約されたパラメーターを備えた、検証可能なモデルまたはスプレッドシートのレイアウト。
• 支点となる基準と代表的なシナリオのセット。
• 該当する場合は、曲線、経済、確率の分析。
• 決定論的なエッジケースの確認と不変条件の結果。
• 前提と出力を含むシミュレーションまたはプレイテスト計画。
• テレメトリーに関する問いとイベントの対応計画。
• 因果関係を示す証拠と不確実性を添えた、優先順位付きの診断。
• 予想される変化、ロールバック条件、変更履歴への記録を含む調整案。

検証

• 目標は測定可能であり、対象プレイヤー、コンテキスト、期間が明確です。
• 入力値、派生値、表示値、観測値が区別されています。
• 単位に互換性があり、計算式にラベルが付いており、丸めの順序が明示されています。
• 共通定数の定義場所は一元化されています。
• 正規化と逆変換は、最小値、中間値、最大値で確認されています。
• 支点となる基準は一般的なシナリオで機能し、極端なケースや固有ルールは相互にテストされています。
• 曲線は、端点、単調性または意図した反転、上限、限界変化の目標を満たしています。
• 経済の残高は、供給源、消費先、移転、開始残高と整合しています。
• 確率の重みは正規化され、期待値とテールリスクが確認されています。
• 確率的テストの前に、決定論的なエッジケースに合格しています。
• シミュレーションは再現可能で、方針が文書化されており、意思決定に十分な精度で結果が収束しています。
• テレメトリーは、不要なデータを収集せずに、機会、コンテキスト、バージョン、アクション、結果を記録しています。
• モデルの予測は、プレイテストまたは実運用の証拠と比較されています。
• 変更のたびに、ガードレールと回帰が確認されています。
• 信頼できる唯一の情報源、意思決定の記録、ロールバック値が最新です。