ゲーム画面の視覚的階層

核となる考え方

プレイヤーが一瞬のうちに画面に割り当てられる注意力には限りがあります。「目立つ」表現—明るい、暗い、鮮やか、細かい、大きい、動いている—はすべて、同じ限られた予算から引き出されます。階層とは、この予算を配分することです。ゲームプレイ上、より重要で即座の反応が必要な情報ほど、より多くの、より独占的な顕著性手段を割り当て、それ以外の要素は自ら譲歩します。

重要なのは下位を制約することであり、上位を引き上げることではありません。重要なものだけを明るくしようとすると、他のアセットも同様に明るくなり、結局すべてが目立ってしまいます。効果的な方法は、最下層のキャンバスに狭い範囲を設定し、上位層が使用する方向に余白を残すことです。

この方法は、Riot Games が 2014 年に公開したブログ記事「Defining the Rift's Visual Style」から抽出されています。原文の主張、本スキルの推論、および実測データについては references/rift-case-study.md を、その他の出典については references/sources.md を参照してください。

0. まずプロジェクト固有の仕様を確認する

プロジェクト内で以下のものを探してください：

アートディレクションと配色仕様、パレットファイル、QAスクリーンショット記録、レビューページで既に指摘されている問題
デバイスや出力ツールの制限（例：LEDディスプレイのフレームレート上限、輝度の駆動方法）
意思決定記録：何を実施し、何を却下したか

見つかったら、その用語と色空間を継承し、その数値を合格基準として使用します。コードコメント内の仮定と検証済みの事実は区別して記述してください。仕様と本原則が矛盾する場合はその旨を指摘し、無断で書き換えないでください。

1. プレイヤーが下すべき判断から始める

まず問うてください：この瞬間、プレイヤーは何を読み取らなければならないか？私はどこにいるのか、どこへ行けるのか、誰が敵で誰が味方か、何が今にも自分に当たろうとしているのか、今何ができるのか、直前の結果はどうなったのか。読み取った情報は実際のゲームプレイと一致していなければなりません：歩けそうに見える場所は実際に歩ける、危険そうなものは実際にダメージを与える、範囲を示すものは実際にその範囲を持つ。

優先順位付けは二つの観点で行います。緊急度：見逃した場合のコストと反応に必要な時間。プレイヤーが回避、割り込み、位置取り替えなどの行動を取れる場合にのみコストは大きく、対応できないエフェクトは警告のように見せてはいけません。持続性：常時表示か一瞬か。通常、最優先は「瞬間的かつ致命的」なシグナルです。
注視点：プレイヤーが現在見ている場所（キャラクター、照準、カーソル）を特定します。注視点付近のシグナルは色や形状で識別でき、遠く離れた緊急シグナルは動き、面積、または画面端の全体的な変化に頼る必要があります。
フェーズ：探索と戦闘、閲覧/ターゲット選択/結果表示など、フェーズごとに優先順位を再設定します。特定のフェーズに入ったら、それに関係のないレイヤーは積極的に抑制します。
機能ごとにレイヤーを分け、アセットの種類で分けない：崖の端や拾得可能なオブジェクトはゲームプレイ情報であり、環境レイヤーの上端に配置します。装飾パーティクルは環境レイヤーに属し、技術的に「エフェクト」であっても同様です。
描画順序は顕著性の優先順位と等しくない：タワーディフェンスの弾道は敵の上に描画されますが、数が多く個々の情報量は少ないため、小さく短くなければなりません。

各種タイプのレイヤースタックの初期設定については references/layer-stacks.md を参照してください。

2. 顕著性のチャネル

チャネル	特徴
明暗コントラスト	最も強力で高速。グレースケールでも有効で、階層化の第一選択。
彩度	次に強力。小さな面積の高彩度色でも目立つ。
色相と暖冷	画面の主色群から離れると非常に強力（例：溶岩シーンでの冷色）。同一色群内では、赤対緑は信頼性が低い。意味の表現にも使用する。
詳細密度	高周波テクスチャはノイズとなり、注意を分散させる。
形状、面積、シルエット	形状言語でシグナルの種類を区別。シルエットは遠くからの認識性を決定する。
動きと出現方法	周辺視野に非常に効果的。突然の出現はグラデーションより効果的。最優先シグナルが動きに依存する場合、他のループアニメーションは停止または劣化させる。
位置とフレーミング	画面端、ベース、アウトライン、足元の円。常駐UIは主にこれに依存する。
画面全体の色調と総輝度	遠くから一目で読み取れ、グローバルな状態を表現するのに適する。

明度の定義：グレースケールで区別できるかどうかは、知覚明度（L*）に依存します。HSBのVは「明るさ」と「鮮やかさ」を混同します：純粋な青のVは100ですが、L*はわずか32です。数値を伴う明度については、どの指標であるかを明記してください。

3. 割り当てルール

キャンバスは最も狭くし、上位層が使用する方向に余白を残す。 デフォルトでは両端に余白を残します。暗いゲームやLEDディスプレイのキャンバスは暗端に寄せることができ、その場合、上位層は明るく鮮やかな方向にのみ拡張でき、アウトライン、シルエット、動きで補完します。
上位層は下位層を含み、さらに外側に拡張する。 上位層はキャンバスの中間調を使用でき、拡張部分によって視認性を得ます：より明るいハイライト、より深いシルエット、より鮮やかなアクセント。層内でも主従を付けます：はみ出した部分は、ゲーム情報を伝える小さな部位（向き、武器、弱点、予備動作の手足）に使い、残りは詳細度の低い休息領域とします。
最も強力なチャネルは、セクション1で最優先とされたシグナルに割り当て、専用スロットとする。 専用スロットは他のすべての層からそのチャネルを奪い、そのシグナルだけが使用します。一つのスロットは一つの意味に対応し、プレイヤーが学習できるようにします。他の要素が侵入すると誤報となります。これは必ずしも「最も明るい」ではなく、特定の色相、形状、動き、またはフェーズごとに割り当てることも可能です。
顕著性 × 面積 × 時間 × 数 = 予算。 予算は主シグナルと競合する要素を制約します。主シグナル自体は、まず視認距離で見えることを保証します。
- 短時間であるべきものは、ヒットフラッシュと結果フィードバックです。警告はこれとは逆に、判定よりも前に出現し、反応時間を確保し、接近に応じて段階的に強めます。
- 数は画面を圧迫します：同画面に数百の弾道や浮遊テキストがある場合は、数に応じて流量制限を行います。広範囲インジケーターは塗りつぶしを低減し、エッジのみを目立たせ、重複時は結合します。
- 常駐UIはまずゲームプレイ（キャラクター周辺、進行方向、次に操作する位置）を遮らないようにし、次に狭く、小さく、端に配置します。体力バーやダメージ数値などのワールドスペースUIは、それがマークするレイヤーの予算に計上します。
- フラッシュの安全性は階層より優先されます：「短時間」は光過敏症のリスクを低減しません。大面積のフラッシュは毎秒3回以下にし、飽和した赤のフラッシュは避けてください。
比較は局所的に行う。 要素と、それが実際に接触する最も不利な背景との比較を行います。明暗両方の背景を通過する要素には、濃淡二層のアウトラインを使用します。
問題を修正する順序：まず下げ、次にチャネルを変更し、最後に上げる。 まず、はみ出した下位層を引き下げます。次に、下位層が占めていないチャネル（色相、形状、出現方法、位置）をシグナルに割り当てることを検討します。最後に上位層を強化します。下位層を圧縮した後は再テストします：以前「背景より暗い」ことで分離されていた要素が、逆に貼り付いてしまう可能性があります。
アップグレードインフレに注意する。 最大レベルや高レアリティは、シルエット、パーツ、アニメーションで表現し、既存の範囲内に留めます。

4. 環境：後退し、道を示す

後退は、ぼかしではなく簡略化によって行います：細かくコントラストの高いテクスチャの代わりに、大きな形状と明暗を使用します。画像をぼかせば指標は下がりますが、素材が認識できなくなる可能性があります。一般的な変更は、彩度を下げる、地面のテクスチャコントラストを下げる、環境光源を減らすことであり、多くの場合、最初にキャラクターを動かす必要はありません。
道を示す：通行可能な場所はより平坦で静かにし、境界との間に安定した明度差を保ちます。境界はより暗く、より密にします。それは控えめなヒントであり、矢印ではありません。
環境内部でも階層化を行います：ゲームプレイに関連する地形は範囲の上端に、純粋な装飾は中間に配置します。環境光源は専用スロットと競合する可能性があるため、縮小、減光するか、ゲームプレイ上の意味を持たせます。

5. 統一感と技術的痕跡

すべてのアセットは同一のビジョンに立ち返り、スケールはキャラクターに見合ったものとします。キャラクターのスタイルの幅が広いほど、環境はより中間的である必要があります。新しいアセットを評価する際は、スタイルの両端にあるキャラクターの隣に配置して確認します。
スタイルの個性は、意図的な形状のコントラスト（柔らかさ対鋭さ）と、現実の参照とファンタジー要素の比率の制御から生まれます。
ハードなポリゴンエッジ、継ぎ目、タイルの繰り返し、フリッカー、過度にリアルな粗いテクスチャは、注意力を引きつけながら情報を伝えません。これらは隠すか、意図的なスタイルに変更します。グリッド、ピクセルブロック、アウトラインなど、意図的に保持された構造は対象外です。

6. プロジェクトに応じた調整

暗い/ホラーゲーム：「明るさ」は希少なチャネルです。複数のシグナルが暗闇の中の明るい点となり得るため、形状、高さ、動きで区別します。重要な情報を最も暗い階層だけに配置しないでください。
明るいカートゥーンスタイル：両端がスタイルで占有されている場合、キャンバスを中間部に戻すか、または暗いアウトラインでキャラクターを分離します。
3D/写実/動的ライティング：最終的な明度は、マテリアル、ライティング、カメラによって共同で決定されます。まずライティングを推定してから範囲を決定し、ポストエフェクト後の画像で測定します。references/3d-lighting.md を参照してください。
ピクセルアート、限定パレット、LEDドットマトリックス、小型画面：references/limited-palette.md を参照してください。
色覚の多様性：階層化は主に明暗に依存し、意味色は形状やアイコンと組み合わせます。色相の専用スロットを使用する場合は、赤色盲および緑色盲のシミュレーション画像で確認します。

7. 確認方法

まず推論し、次に測定します。まず上記のルールとこのタイプの常識を使用して判断を下します：ライティングがどのように減衰するか、デバイスにどのような制限があるか、プレイヤーがいつ判断を下すか。測定は、特定の質問に答えるためにのみ使用し、パズルや数値の集計が推論を圧迫しないようにします。

まず証拠を確認する：スクリーンショットが現行バージョンより前のものか、デバッグオーバーレイが含まれているか、撮影時にライティングやポストエフェクトが有効だったか。方法は references/evidence-and-measurement.md を参照してください。
最悪のケースを取る：最も混雑した瞬間、プレイヤーが重要な判断を下す瞬間。瞬間的なシグナルは、完全に明るくなったピークフレームではなく、開始フレームを見ます。状態変化は、同じカメラ位置の2フレームを比較します。
3つのクイックテスト：グレースケールでも階層は維持されているか？ぼかした後、目はどこに最初に留まるか？特定のレイヤーを単色で塗りつぶした場合、ポーズや向きはまだ認識できるか？
重要なシグナルをチャネルごとに確認する：最優先シグナルと、実際に隣接する競合要素を、セクション2のチャネルごとに一つずつ比較します。
測定：本スキルディレクトリ内の scripts/sv_profile.py は、レイヤーごとの面積、彩度と明度の範囲、知覚明度、詳細密度、専用スロットの割り当て、局所コントラストを報告します。プロジェクトの色空間、2フレーム比較、マルチフレームGIFをサポートします。scripts/palette_check.py は、描画前に階層化パレットをチェックします。パラメータは -h で確認でき、数値の読み方は上記のリファレンスファイルを参照してください。出力は一時ディレクトリに書き込み、プロジェクト内には書き込まないでください。
```
python <スキルディレクトリ>/scripts/sv_profile.py shot.png -o <一時ディレクトリ> -r "!environment:0,0,1,1" -r "player:0.42,0.40,0.50,0.55" -r "hud:0,0.88,1,1"
```
説明用フレームは対照実験にのみ使用する：スクリーンショットがない場合は色ブロックでフレームを構成できますが、一度に一つの変数だけを変更し、ライティングはおおむね実際の状態に合わせます。自作の画像で測定した数値は「現状」として扱えず、自分の提案の妥当性を証明するためにも使用できません。
数値は単なる証拠である：結論は最終的に「プレイヤーが読むべきものを読めるか」に立ち返ります。受け入れテストが必要な場合は、プレイヤーテストの指標を記載してください。

8. 出力

レビューはデフォルトで読み取り専用とします：素材、コード、プロジェクトドキュメントは変更せず、変更提案のみを記述します。ユーザーの質問にはまず直接回答し、同じ判断は一度だけ述べます。

スクリーンショットレビュー：最初に一言で結論を述べます。発見はゲームプレイへの影響順に並べます：まず「自分はどこにいるか、敵はどこにいるか、何が自分に当たろうとしているか」とUIの遮蔽、次に環境とキャラクターの注意競合、最後にスタイルと技術的痕跡です。各発見について、位置、現象、違反した原則、最小限の変更を記載します。
Before/After比較：「プレイヤーが読むべきもの」が改善されたか悪化したかを項目ごとに回答します。このスクリーンショット群に対する判断と、現行バージョンに何をすべきかは、別々に記述します。
テキスト記述のみの診断：最も可能性の高い原因と調査順序を示し、ユーザーが自分で実行できるチェックとエンジン内での具体的な実装方法を提供し、画面以外の可能性（時間、判定範囲、カメラ、サウンド）もリストアップします。
仕様書の作成：まずセクション1の優先順位付けを完了し、次に各レイヤーの範囲、専用スロットの割り当て、面積・時間・数の制約、適合例と非適合例の対比を記載します。仕様はそのまま実行できるものでなければなりません：
- ユーザーが指定したすべての要素カテゴリをカバーする
- 数値は実行者が使用する単位（マス、ピクセル、秒、エンジンのフィールド）で初期値を示し、「要実測」と明記する。スクリーンショットがなくても数値を出さないということはしない
- 描画順序とスケジューリングルール（誰が誰を優先するか、オーバーレイの上限、いつクリアするか）を記載する
- 最後にいくつかの禁止事項と実装の優先順位を列挙する
既存のアートはあるがスクリーンショットがない場合、同時にユーザーにスクリーンショットの提供を依頼して調整します。

共通ルール：

証拠が不十分な場合は結論を削減し、末尾に一言添えるだけにしないでください。スクリーンショットに写っていないものについて数値を外挿しないでください。
用途が不明な要素は、まずプロジェクト内で調査します。見つからない場合、2つの可能性をそれぞれ結論として記載し、ユーザーに質問します。
原因に複数の可能性がある場合、まず迅速に検証できる診断手順を示し、次に状況に応じた修正方法を示します。
修正方法を示す前に、プロジェクト内で既に何が行われ、何が却下されたかを確認します。比較基準はプロジェクトの仕様またはプロジェクト自身の準拠フレームのみを使用し、リファレンスケースの数値を標準としないでください。
プロジェクトの確立されたアートスタイルを無断で変更せず、提案にはメリットと代償を明記してください。

game-visual-hierarchy