iphone-duo-games

iPhone Duo のゲーム

ゲームは、このデバイスの UI に関するガイダンスの大半が適用されません。縦方向に移動させるツールバーも、適応させる分割ビューもありません。ただし、サイズ変更は避けられません。デバイスを開いたり、閉じたり、折りたたんだり、回転させたりするたびに、実行中のゲームの画面サイズと形状が変わります。固定ビューポートを前提にしたゲームは、レターボックス表示になったり、引き伸ばされたり、操作要素が画面の端からはみ出したりします。

画面の向きは固定できます。画面全体を埋める必要はあります。

縦向きまたは横向きに固定することは問題なく、サポートされています。ただし、その固定を画面サイズが一定であると見なす許可だと考えるのは問題です。

ここでは、それが通用しない理由が2つあります。

1. デバイスにはサイズの異なる2つのディスプレイがあり、ゲームのプレイ中にディスプレイ間を移動します。
2. 内側のディスプレイは、サポートされているインターフェイスの向きに従いません。 これまでのすべての iPhone で有効だった画面の向きの固定が、内側のディスプレイでは効かなくなります。

UIRequiresFullScreen も同様に動作します。引き続き有効ですが、デバイスを開閉するとゲームのサイズは変わります。いずれにしても、サイズ変更を想定して設計してください。

つまり、画面の向きを決めたうえで、どの状態でもゲームが画面全体を埋めるようにしてください。それが実際の要件です。

レターボックス表示よりアスペクト比の変更を優先する

ビューポートの形状が変わったとき、選択肢は3つあります。優先度の高い順に示します。

1. アスペクト比を変更する。 ゲームの世界をより広く、または狭く表示します。これが推奨される方法です。カメラの視錐台を広げ、見える範囲を広げ、与えられたスペースに合わせてシーンをゆったりと表示します。ゲームは画面全体に表示され、どの状態でも自然に見えます。

2. アートワークでレターボックス表示またはピラーボックス表示にする。 可変アスペクト比に本当に対応できないデザイン（固定されたパズルグリッドや、精密に調整されたプラットフォーマーのカメラなど）では、黒帯ではなく何かを表示すれば許容されます。背景を延長したり、シーンのアートワークを続けたり、テーマに沿ったフレームを余白に配置したりしてください。意図的なフレームとして見せることが目標です。ゲームが画面に収まらなかったように見せてはいけません。

3. 何も表示しない黒帯。 避けてください。これは「適応できていない」状態に見えます。

テキストと操作要素のサイズを維持する

ビューポートのサイズが変わるとき、シーン全体を一律に拡大・縮小したくなるかもしれませんが、それは避けてください。一律に拡大・縮小すると、ゲームの世界と一緒に HUD のテキストやタッチ対象も小さくなります。そのため、デバイスを開いてより大きいディスプレイにすると、かえってテキストが読みづらくなり、ボタンも押しづらくなります。これはまったく逆の結果です。

ゲームの世界は拡大・縮小し、UI はポイント単位のサイズで独自のレイヤーに配置してください。テキストと操作要素は、どの状態でも実際のサイズができるだけ一定になるようにします。特に画面上のタッチ操作は、アスペクト比が変わっただけで、快適に操作できるサイズより小さくならないようにしてください。

折り目はタッチ操作にとって実際に問題になります

これは iPhone Duo 固有の問題のうち、ゲームに最も大きな影響を与える可能性があります。

デバイスを途中まで折りたたむと、内側のディスプレイの中央にカーブが生じ、その部分は実際に見づらく、タップもしづらくなります。仮想ジョイスティック、射撃ボタン、ドラッグ対象がカーブ上にあると、操作の信頼性が低下します。見えなくなるわけではなく、単に使いにくくなるため、不具合報告だけでは原因を特定しづらくなります。

ゲームでは、折り目への対応を標準で備えたシステムコンポーネントを使うことはあまりないため、この問題は自分で対処する必要があります。

• 予約領域を取得し、操作要素が分割領域（折り目）に入らないようにします。API と位置調整のパターンについては、../iphone-duo-adaptive-layout/SKILL.md を参照してください。
• タッチ操作は中央ではなく、外側の端に配置します。端に固定すると、どの状態でもより安定し、デバイスを平らにしたときにも追加のコストはかかりません。
• 遮蔽領域にも注意してください。外側の前面カメラは常に存在し、内側のカメラは有効になると表示されます。

視覚的な表示だけで操作を伴わないコンテンツは、折り目をまたいでも構いません。移動が必要なのは、タッチ対象と重要な情報表示です。

設計時に考慮する価値のあるポーズ

ポーズごとに専用のレイアウトを用意する必要はありませんが、次の2つは検討する価値があります。

テーブルトップ／ノートパソコン。 デバイスを平面に立てかけ、ディスプレイの半分を上向きに、もう半分をプレイヤー側に向けます。これはまったく新しいプレイ姿勢です。下部は安定したタッチ操作面、上部は表示面になります。ボードと操作部を分けたゲームなら、自然にこの姿勢に対応できます。

テント。 端で立て、手を使わずに置ける姿勢です。放置型、観戦型、アンビエント型、ターン制のゲームに適しています。

どちらも追加要素として扱ってください。使われないかもしれないポーズに機能を結びつけないでください。

Split View

ゲームもほかのアプリと同様にSplit Viewのマルチタスクに対応します。ゲームが内側のディスプレイの半分に表示されることもあります。設計時に想定したどのサイズや形状とも異なり、表示領域は小さくなります。その場合も正しく描画され、操作部が画面の端で切れないことを確認してください。そのサイズで快適にプレイできるようにする必要はありませんが、動作が壊れないようにしてください。

入力としてのヒンジ

ヒンジの角度は、SwiftUIではonHingeChange、UIKitではUIHingeInteractionを通じて、粗い状態と角度を含む、リアルタイムで連続的な値として取得できます。ゲームエンジンでは、ほかのネイティブセンサーと同じ方法で連携させてください。

これは新しい入力方法で、エフェクト、カメラの視差、あるいはゲームメカニクスへの活用を検討する価値があります。ただし、次の2点に注意してください。折りたたみ式でないすべてのiPhoneでも同じバイナリが動作するため、ヒンジがnilの場合に備えてください。また、アクションを実行する唯一の方法にしてはいけません。詳細は../iphone-duo-hinge-and-scenes/SKILL.mdを参照してください。

エンジンに関する注意事項

ほとんどのエンジンでは、ビューポートのリサイズイベントとセーフエリアのインセット取得機能が公開されています。両方を組み込み、リサイズを起動時の値ではなく、第一級のイベントとして扱ってください。

• Unity — Screen.safeAreaを使用し、Start()で一度だけ読み取るのではなく、実行時の解像度変更に対応してください。
• Unreal — セーフゾーン／タイトルセーフの値を使用し、ビューポートのリサイズ時に再評価してください。
• Godot — セーフエリアAPIと、アスペクト比の変化に対応できるストレッチモードを使用してください。
• SpriteKit / Metal — ビューを通じてリサイズはすでに取得できます。必要なのは、初期の描画可能サイズを前提にせず、シーンが変化に対応するようにすることです。

予約領域とヒンジ角度はiOS 27.1のAPIであり、エンジンレベルで同等の機能はありません。そのため、ネイティブプラグインが必要です。連携パターンは../iphone-duo-flutter/SKILL.mdおよび../iphone-duo-react-native/SKILL.mdで説明されているものと同じです。

チェックリスト

1. ビューポートのリサイズを、起動時に読み取る値ではなく、リアルタイムのイベントとして処理してください。
2. 画面の向きが固定されているかどうかにかかわらず、すべてのポーズで画面いっぱいに表示してください。
3. アスペクト比の変更を優先してください。レターボックス表示にする場合は、余白をアートワークで埋めてください。
4. すべてのポーズでHUDのテキストとタッチ操作領域の実寸を一定に保ってください。
5. 操作可能なコントロールは端を基準に配置し、折り目にかからないようにしてください。
6. Split Viewでもゲームが正しく描画されることを確認してください。
7. Device HubのiPhone Duoシミュレーターで、開いた状態、閉じた状態、折りたたんだ状態、回転させた状態を含む、すべてのポーズをテストしてください。