Design advanced games for Apple platforms

ハイライト

Apple の統合ゲームプラットフォームでは同じゲームを Mac、iPad、iPhone で動かせますが、3 つの画面サイズ、3 つの操作方式、3 つの性能レベルごとに、各次元で的を絞った設計が必要です。

主要内容

プレイヤーが 50GB の大作をダウンロードし終え、アイコンをタップすると「追加コンテンツのダウンロードをお待ちください」と表示される。Apple デザイナーの Linda は率直に言います。Apple プラットフォームではそれは減点要素だと。Apple ユーザーは「インストールしたらすぐ遊べる」ことを当たり前に思っており、起動後に待たされる体験は第一印象を損ないます。

彼女の解決策は具体的です。最初の 15 分のゲーム内容を App Store の初期ダウンロードに同梱し、以降の章は On-Demand Resources（App Store ホスト）または Background Assets（開発者サーバーホスト）でバックグラウンド読み込み。プレイヤーが感じるのは「インストールして即プレイ」であり、「インストールしてから待つ」ではありません。

ただしインストール体験は第一歩に過ぎません。同じゲームを Mac、iPad、iPhone でうまく動かすには 3 つの設計次元に直面します。デフォルト設定はハードウェア能力を自動検出すべきか、プレイヤーに手動調整させるべきか。UI レイアウトは全体スケールか、アンカーで区切るか。セーフエリア内のコントロールはタップできるか。Linda と Dylan が後半でこれらを順に解説。Dylan のタッチ設計パートが特に重要です。タッチ画面では入力面がそのまま出力面でもあり、入力設計は UI 設計そのものです。

詳細

初回起動：待ち時間を隠す

Apple は初期ダウンロードに最初の 15 分のプレイ可能コンテンツを含めることを推奨しています（02:28）。バックグラウンド読み込みには 2 つのフレームワークがあります。

On-Demand Resources：App Store でホスト。更新頻度が低いコンテンツ向け
Background Assets：開発者自身のサーバーでホスト。頻繁に更新するコンテンツ向け

プレイヤーの進行が読み込み速度を上回った場合のみ、UI でダウンロード進捗を表示。できればステージ選択画面などゲームを妨げない場所に置き、ダウンロード済みステージの再プレイを許可します（03:07）。

デフォルト設定：手動選択の代わりに自動検出

デバイスモデル、画面解像度、ペアリング済み周辺機器——これらはシステムが直接取得でき、プレイヤーに入力させる必要はありません（04:17）。コントローラーについては Game Controller framework がペアリング済みゲームパッドを自動検出し profile を取得、UI に直接マッピングできます（04:57）。

性能のデフォルトもデバイス能力に応じて自動設定。Mac では画質を高め、iPhone では性能重視。モバイルでは細かいオプションを「画質 vs 性能」のマスタースイッチ 1 つにまとめられます（05:44）。

UI レイアウト：アンカー区切り、全体スケールは避ける

最も簡単な適応は UI 全体のスケールですが、Linda は明確に非推奨。スケールするとコントロール位置が不正確になり、タッチ領域が大きすぎたり小さすぎたり、見た目も揃いません（06:48）。正しい方法は UI を複数セグメントに分け、各セグメントを画面の一端にアンカーすること。デバイスが変わっても各セグメントはサイズとアンカーまでの距離を一定に保ちます（07:08）。

セーフエリアとフルスクリーン設計

Safe Area は Apple デバイスで UI を置く安全範囲です（08:00）。

iPad/iPhone：角丸、Home Indicator、Dynamic Island を避ける
Mac：上部に角丸とカメラ領域の余白

Apple Design Resources が Safe Area テンプレートを提供し、Xcode Simulator で各デバイスのベゼルと向きをプレビューできます。ただし Safe Area は UI 配置の参考に過ぎず、ゲーム画面自体は画面いっぱいに表示すべきです（09:18）。

ゲーム内容がデバイスのアスペクト比で切り取られる場合は、まずカメラの焦点距離と角度を調整。プリレンダー過場なら letterboxing を使い、黒帯は黒またはカスタムアートで埋めます（09:55）。

文字とコントロールサイズ

大画面 TV から小画面デバイスへ移すと、文字とコントロールサイズは見落としやすい問題です（10:25）。

Platform	Default text size	Minimum text size	Default touch target	Minimum touch target
iPhone/iPad	17pt	11pt	44×44pt	28pt
Mac	13pt	10pt	28×28pt	20pt

コントロールが収まらない場合は文字サイズを縮めるのではなく ScrollView を使います（12:58）。

コントローラーアイコンとキーボード/マウス適応

Apple プラットフォームは他より多くのコントローラーをサポートし、種類ごとにボタンアイコン（glyph）が異なります。アイコンをゲーム素材にハードコードせず、GameController framework で現在のコントローラーに対応する正しいアイコンを取得してください（15:02）。SF Symbols app に完全なアイコンライブラリがあります。キーボードでは Apple キーボードの修飾キー配列が PC と異なるため、ショートカットマッピングを検証・調整が必要です（15:27）。

GameController framework でコントローラーを検出しアイコンを取得するコード：

import GameController

// コントローラ接続通知を監視
NotificationCenter.default.addObserver(
    forName: .GCControllerDidConnect,
    object: nil, queue: .main
) { notification in
    guard let controller = notification.object as? GCController else { return }

    // コントローラの物理入力 profile を取得
    if let gamepad = controller.extendedGamepad {
        // コントローラ種別に応じた正しいボタンアイコンを取得
        let buttonAGlyph = gamepad.buttonA.sfSymbolName
        let buttonBGlyph = gamepad.buttonB.sfSymbolName
        let leftTriggerGlyph = gamepad.leftTrigger.sfSymbolName

        // 取得した glyph 名で UI を更新
        updateButtonIcons(a: buttonAGlyph, b: buttonBGlyph, lt: leftTriggerGlyph)
    }
}

// コントローラ検出を開始
GCController.startWirelessControllerDiscovery {}

キーポイント:

GCControllerDidConnect はコントローラーペアリング時に発火。プレイヤーの手動設定は不要
controller.extendedGamepad は全ボタンとスティックを含む完全な入力 profile を提供
sfSymbolName は現在のコントローラーに対応する SF Symbols アイコン名を返し、Xbox、PlayStation などで正しい glyph を表示
startWirelessControllerDiscovery で Bluetooth コントローラー探索を開始。通知と組み合わせて自動検出

タッチ入力設計（Dylan パート）

Dylan の核心：タッチ画面では入力面が出力面。入力設計は UI 設計です（16:22）。

移動とカメラ：左スティックは仮想スティックで代替。使わないときは非表示。右スティックは仮想スティックにせず、直接タッチドラッグでカメラ操作——速度と精度はスティックよりマウスに近い（18:06）。仮想スティックの入力領域は可能な限り大きく。物理スティックのような触覚定位はできないから（17:19）。ダッシュは仮想スティックに統合——最大まで倒すと発動、追加ボタン不要（17:58）。

コントロール配置：セーフエリア、移動/カメラ入力領域、キャラクター位置を避ける。残りスペースでは親指付近に高頻度操作、画面上部にメニューなど低頻度操作（19:37）。左右手の同時操作に注意。L2 エイム + R2 射撃はコントローラーでは自然だが、タッチでは移動とエイムを同時にできない——エイムは右側に（20:10）。

動的挙動：コントローラーボタンアイコンの代わりに説明的アイコン。現在のコンテキストで使えない操作はグレーアウトではなくコントロールを削除。クールダウンなどゲーム状態をコントロールに反映（20:46）。

フィードバック：タッチに物理フィードバックはないため、各ボタンに押下状態が必要（22:07）。忙しいシーンでは指がボタンを隠すため、視覚フィードバックはコントロール境界の外（グローなど）まで広げる。音と触覚（haptics）で応答感を強化（22:37）。

重要ポイント

何をするか：「最初の 15 分即プレイ」のインストール戦略を実装。なぜ価値があるか：Apple ユーザーは「インストールしてすぐ使える」を強く期待。起動後の待ちは離脱要因。始め方：初期ステージデータをメイン Bundle に同梱。以降の章は On-Demand Resources または Background Assets でバックグラウンド読み込み。未読み込み領域に到達したときだけ進捗表示。
何をするか：マルチスクリーン適応に全体スケールではなくアンカー区切りを使う。なぜ価値があるか：全体スケールはコントロール位置ずれ、不合理なタッチ領域、デバイス間の不揃いを招く。始め方：UI を複数セグメントに分け画面端にアンカー。サイズとアンカー距離を一定に。Xcode Simulator で各デバイス検証。
何をするか：コントローラーマッピングのコピーではなくタッチ専用入力を設計。なぜ価値があるか：タッチ画面では入力面＝出力面。コントローラー方式は画面を遮り操作しにくい。始め方：大きな非表示可能な仮想スティックで移動（端でダッシュ）、カメラは直接ドラッグ。コンテキストで表示/非表示。各タッチボタンに押下状態 + グロー + haptics。
何をするか：ハードウェア能力を自動検出しデフォルト画質を設定。なぜ価値があるか：解像度や画質をプレイヤーに選ばせる必要はない——デバイスが知っている。始め方：デバイスモデルと解像度で性能段階を設定。モバイルでは細粒度オプションを「画質 vs 性能」1 スイッチに。Game Controller framework でコントローラー自動検出とボタンマッピング。