ゲーム UI スクリーン
すべての画面を、同じゲームの一部であるかのように感じさせます。汎用的なWebスタイルではなく、ゲーム内の最も完成度の高い画面を基準に作業し、ナビゲーションをゲームらしく保ち、プレイヤーが実際に使用するサイズで各画面をチェックします。UI技術（キャンバス上のDOM、エンジンUI、またはインシーンUI）に適応します。利用可能であれば game-foundation を画面フロー自体に使用します。このスキルは画面の見た目とふるまいをカバーします。
1. 棚卸し
すべての画面とオーバーレイをリストアップします。忘れがちなものも含めます：タイトル、メインメニュー、各モードメニュー、ガレージまたはロードアウト、設定、ロビーまたはルーム画面、参加と招待フロー、ローディング、ポーズ、結果、エラー、空状態、HUD、そして開発者専用画面。各画面について、ファイル、その画面に到達する方法、そこから離脱する方法、表示にサーバーまたは保存データが必要かどうかを記録します。ゲームサーバーが必要な画面は、サーバーと共に実行するか、未確認として報告する必要があります。
2. スタイル契約を抽出する
アンカーとなる画面を選びます：既に最もゲームらしく見える画面（通常はタイトルまたはメインメニュー）です。他の画面に触れる前に、そのルールを書き出します：タイプフェイスとタイトルの扱い、カラートークン、背景（ライブ3Dシーン、ぼかし背景、アート）、パネルの形状、ボタンの状態（アイドル、ホバー、フォーカス、押下、無効）、スペーシングスケール、モーション、サウンドキュー。共有部分をトークンまたは共有クラスにまとめ、画面間でずれが生じないようにします。style-contract.md を読み、テンプレートとゲーム内の慣習を確認してください。
3. 適用する
- フルスクリーンのゲームレイアウト。Webカードではない。 デスクトップではドキュメントスクロールは禁止。モーダルはビューポートに収まる。長いリストは自身のパネル内でスクロールする。
- ゲームナビゲーション。 Esc または戻る操作で各画面から離脱。キーボードとゲームパッドのフォーカスは予測可能な順序で移動し、可視のフォーカス状態を持つ。主要なアクションは明確である。
- オンボーディングのゲートはフローとして実装する。 一部のモードの前に名前やプロフィールが必要な場合、ロックされたボタンだらけのメニューを表示する代わりに、短いスタートステップ（名前入力 + プレイ）で入力を促す。設定でも同じバリデーションを維持し、後での編集で破綻しないようにする。
- 一つで十分なところは一つにまとめる。 同じ場所に到達する複数の選択肢（例：1つのマップに3つの出現ポイント）をプレイヤーに選ばせない。主要なアクションを1つ提示し、バリエーションはゲーム内で提供する。
- HUD階層。 hud-and-loading.md を読む。すべての数値にラベルが付き、デバッグ出力のように読めるものはなく、コンテキスト要素は関連する場合のみ表示する。
- ローディング画面 はゲームに合ったモーションを持ち、利用可能な場合は実際の進捗を表示し、短い読み込みではフラッシュしない。
- スペーシングはビューポート高さに連動する（
clamp()またはビューポート単位）。縦長のメニューが大きな画面で密集したり広がりすぎたりしないようにする。
4. プレイヤー向け名称の変更
ゲーム、モード、場所、アイテムの名称を変更する場合：UI文字列、HTMLタイトル、マニフェスト、ドキュメント、パッケージ名、ストレージキーにわたって、すべての表記揺れ（大文字小文字、スペース、ハイフン、タイプミス）を検索します。ストレージキーを変更する場合、保存データを移行して既存プレイヤーのプロファイルを維持します。タスクで変更が要求されない限り、内部IDは安定したままに保ちます。
5. 検証する
変更した各画面を、1440×900、1280×720、1024×600、電話サイズ（375×812）、およびプロジェクト固有のターゲットで確認します。スクリーンショットを使用し、playtest の __pt.layout()（または同等のバウンディングボックスチェック）を使用して、ページスクロール、画面外のコントロール、重なりをチェックします。各画面の入退出をウォークスルーします。開けなかった画面とその理由を報告します。