game-ui-frontend

ゲーム UI フロントエンド

概要

ゲームに視覚的なインターフェースレイヤーが必要な場合は、いつでもこのスキルを使用してください。目的は、汎用的なダッシュボード UI を作ることではありません。プレイ体験を支える、読みやすくテーマ性のあるブラウザーゲームのインターフェースを作ることです。

デフォルトの前提：ゲーム世界は canvas または WebGL で構築し、テキスト中心の UI は DOM で構築します。

フロントエンドの基準

1. コーディングの前に、ビジュアルの方向性を決めます。
   • ジャンルと世界観
   • 素材の表現
   • タイポグラフィ
   • 配色
   • モーションのトーン
2. UI テーマには CSS 変数を使用します。
3. 明確な階層を作ります。
   • 戦闘やサバイバルに欠かせない情報を最優先
   • 次に補助ツール
   • 使用頻度の低い設定はメニューやドロワーに格納
4. 特に 3D では、まずプレイフィールドを守ります。
   • 最初の画面は、数秒以内にプレイ可能な状態にします。
   • 常時表示する HUD クラスターは主要なものを 1 つ、補助的なものは小さなものを最大 1 つにします。
   • 通常のプレイ中は、プレイフィールドの中央を空けておきます。
   • 通常のプレイ中は、プレイフィールドの中央下部をできるだけ空けておきます。
   • ロア、フィールドノート、クエストの詳細、長い操作一覧は、ドロワー、切り替え式 UI、またはポーズ画面に格納します。
   • 常時表示のボックス型パネルより、状況に応じたプロンプトや一時的なヒントを優先します。
5. 動きのある画面でもオーバーレイを読みやすくします。
   • 必要に応じて、背景パネル、エッジ処理、コントラスト、控えめなぼかしを使用します。
6. デスクトップとモバイルの両方を最初から想定して設計します。
7. 3D UI はカメラ操作と入力制御の境界を考慮して設計します。
   • メニュー、ダイアログ、ポインター操作型 UI が有効な間は、カメラ操作の入力を一時停止するか、制限します。
   • ポインターロック、ドラッグによる視点操作、メニュー操作の状態を明確にします。

3D の初期設定

探索、移動、または三人称視点のスターター骨組みでは、次の UI 予算を優先します。

• 画面端にコンパクトな目標チップまたはステータスバーを 1 つ
• 一時的な操作ヒントまたはインタラクションプロンプトを 1 つ
• 日誌、マップ、クエストログなどの折りたたみ可能な補助画面を任意で 1 つ

最初の読み込み時に、すべての情報画面を開かないでください。ユーザーが詳細な UI を開く前に、シーンを把握できるようにします。

3D ブラウザーゲームの実装では、次の制約をデフォルトとします。

• 常時表示の全幅ヘッダー、複数カードの本文、全幅フッターを組み合わせたレイアウトにしない
• 通常の移動中に画面中央または中央下部を覆う大きなオーバーレイを表示しない
• ユーザーがより高密度なレイアウトを明示的に求めない限り、デスクトップで常時表示する HUD がビューポートの約 20〜25% を超えて覆わないようにする
• モバイルでは、大きなパネルでプレイフィールドを覆う前に、細い縦積みのレイアウトまたは状況に応じたチップに切り替える

プロンプト作成のルール

ゲーム UI の設計または実装をモデルに依頼する際は、次の情報を含めます。

• ゲームの世界観
• カメラまたは視点
• プレイヤーが実行できるアクション
• HUD のレイヤー
• 3D ゲームの場合は、カメラまたは操作モード
• モーションのトーン
• デスクトップとモバイルでの要件
• プレイフィールドの保護と情報の表示方針
• 避けるべきアンチパターンの明示

具体的なプロンプトの形式については、../../references/frontend-prompts.md を使用してください。

モーションのルール

• 絶え間ない細かなアニメーションより、意味のある少数のトランジションを優先します。
• 大きな動きは、状態変化、報酬、危険、オンボーディングに限って使用します。
• 必須ではないアニメーションでは、視差効果の軽減設定を尊重します。
• 3D HUD の動きがカメラの動きと競合しないようにします。

望ましい状態

• HUD 要素は、シーンの印象を損なわずに読み取れます。
• メニューは SaaS の管理パネルのようではなく、ゲーム世界に自然になじみます。
• レイアウトはブレークポイントに合わせてきれいに調整されます。
• ポインター、キーボード、ゲーム状態へのフィードバックが明確です。
• 3D ゲームでは、メニューや HUD の状態がカメラ操作やポインターロックと競合しません。
• 3D ゲームでは、最初にプレイ可能になった画面の大半を、移動、照準、空間の把握に使えます。
• 常時表示する情報の密度が抑えられており、スクリーンショットを見ても UI のモックアップではなくゲームシーンとして認識できます。

アンチパターン

• 汎用的なアプリのダッシュボードレイアウト
• テーマ性のない平坦なプレースホルダースタイル
• 意図のないデフォルトのフォントスタック
• プレイフィールドを覆い隠す密集したオーバーレイ
• プレイ中のシーンに重ねて表示する大きなタイトルカードや複数段落のメモ
• ビューポートの周囲すべてに均等な比重で配置された、枠付きパネル
• 初回読み込み時に、操作方法、目標、メモ、伝承をすべて展開して表示する
• 3Dプレイ中に、画面上部と下部を横幅いっぱいに占めるUIと、常時表示される大きな中央または本文パネルを併用する
• すべての要素に過剰なモーションを付ける
• DOMのほうが明確で軽量な場合に、CanvasのみでUIを実装する
• 標準的なDOMのほうが明確な場合に、HUD操作を3Dシーン内に無理に配置する
• モーダルやインベントリパネルの表示中も、カメラ操作を有効なままにする

参考資料

• 共通アーキテクチャ：../web-game-foundations/SKILL.md
• プロンプトのレシピ：../../references/frontend-prompts.md
• UI要素を抑えた3Dレイアウトパターン：../../references/three-hud-layout-patterns.md
• Reactでホストする3D UIのコンテキスト：../react-three-fiber-game/SKILL.md
• プレイテストレビュー：../../references/playtest-checklist.md