2Dプラットフォーマーで異なるアスペクト比をどのように処理しますか？

昔、PCで見られるアスペクト比は4：3だけでした。現在、最も一般的なのは16:10ですが、ほとんどの新しいモニター（特にラップトップ）は16：9です。

私は2Dプラットフォーマーを書いていますが、すべての異なる比率をどのように処理するかを決定できません。

ここにいくつかのアイデアがあります：

1. 4：3はより多くのコンテンツを取得し、ワイドスクリーンは上下にカットされます
2. 16：9はより多くのコンテンツを取得し、他のコンテンツは左右にカットされます
3. ゲームは16：9で、他のARの黒い水平バーがあります
4. ゲームは4：3で、他のARの黒い垂直バーがあります

ゲームを「ワイド」（この場合はアプローチ3を使用）またはナロー（この場合はアプローチ4を使用）にする説得力のある理由がない場合は、1と2の組み合わせ（または3と4画面外のものを非表示にします）。

妥協のアスペクト比を選択します（16:10が良いもの、または16:11でさえあります）。ユーザーが16：9にいる場合、より多くのコンテンツをサイドに提供し、4：3にある場合、より多くのコンテンツを上部と下部に提供します。

いずれにせよ-あなたのカメラクラスでこのようなものを実装するのが最善だと思います：

float scaleToFitWidth = viewport.Width / nominalWorldSize.Width;
float scaleToFitHeight = viewport.Height / nominalWorldSize.Height;
float scale = Math.Min(scaleToFitWidth, scaleToFitHeight); // world to client

この時点で、さまざまな名目上の世界サイズ（つまり、世界単位でのカメラのサイズ）を簡単に実験し、最適なものを選択することができます。

基本的なアドバイスとして、PCでは「ユーザーが全画面表示を実行することを想定しないでください」と言います。また、ウィンドウモードでは、理想的な比率を選択し、それを直接使用します。

私が思うに、フルスクリーンのコンテンツが表示されると、一般的に黒いバーを受け入れます。したがって、戦略3および4は、理想的でない場合でも受け入れられます。それらには、レンダリングするコンテンツの量を常に把握できるという利点があります。つまり、ワイドスクリーンで実行しているときにのみ発生する卑劣なバグがありません。

アダプティブになろうとし、画面の解像度でユーザー比率を検出し、できるだけ多くのコンテンツを表示する場合は、優先度の高いコンテンツと低いコンテンツを別々に考慮する必要があります。優先度の高いコンテンツは、ユーザーが画面上で絶対に見る必要があるものです。画面外の場合、ゲームは失敗します。ですから、これはHUDやUI要素、そしてプレイヤーのアバターやそれらがやり取りするものなどです。優先度の低いコンテンツは、画面上にある場合はそれで十分ですが、画面外にある場合は大したことではありません。例：アバターからかなり遠く離れた背景のグラフィックと物。

「物理的な」2Dワールドの上部にUI / HUDが重ねられていると仮定すると、これは簡単です。低優先度のアイテムは簡単です。4：3ビューポートが興味深いものの中心にあることを確認してから、低優先度のものをできるだけ左または右に描画してください。2Dの世界で優先度の高いもの（キャラクター、キャラクターが直接戦っている敵など）は常に4：3ビューポートに保持する必要があります。つまり、ゲームコードでカメラを拡大して余分な画面のスペースを活用しないでください。ゲームコードがワイドスクリーンとそうでない場合で異なる動作をするからです。ゲームコードは、世界が4：3でレンダリングされていると想定し、レンダリングコードに、実際に表示されている以上のものがあることだけを認識させます。

UI / HUD要素のレイアウトは、次の2つの方法のいずれかでアプローチできます。

1. 動的な配置：すべての要素を画面の端に相対的に指定します（つまり、すべてが0,0に相対するわけではありません）。アスペクト比に応じて、要素は画面の中心から近くまたは遠くになります。長所：物事をコーナーに引っ掛けて、「正常に動作させる」ことができます。短所：レイアウトを中央でうまく機能させることが難しく、要素が重複するリスクがある
2. 控えめな静的配置：すべての要素を4：3に配置し、ワイドスクリーンで実行するときにそれらを単純にオフセットします。長所：シンプルで明確なレイアウトロジック/座標。短所：UIコントロールの左右に視覚的なデッドスペースを残します。2Dワールドはバックグラウンドで表示されますが、UIは表示されません。

あなたのゲームに最適なものはどれですか？カナバルト（水平方向の速度に依存するゲーム）を作成する場合、横方向の動きを強調するには、幅の狭いアスペクト比の黒いバー（＃3）の広いアスペクト比が理想的です。一方、スーパースマッシュブラザーズのような空中ゲームをお持ちの場合は、背の高い画面（＃2または＃4）が最適です。ゲームに最適なものに基づいて決定します。

他のレスポンダーには、あるディスプレイには表示されるが別のディスプレイには表示されない可能性がある要素に注意する必要があることに同意します。

Castle Crashersは＃2と＃3を少し使用しているようです。4：3の画面に黒いバーが表示され、表示領域もわずかに小さくなっていますが、常にエッジの周りに「安全な領域」があるはずです。とにかく重要なものは何も置かない（エッジを切り取るCRT TVのような画面の場合）

別のオプションがあります。中間の比率でフレームを作成し、両方の通常解像度で切り取りと拡大（または境界線）の両方を行うことができます。

テレビの撮影はこのように構成されていると思います。ワイドスクリーンは大丈夫です（誰もがシーンの中央に混雑していない）が、4：3のトリミングはそれほど劇的ではなく、最小限のパンニングがあります。

モバイルデバイスでの複数の画面サイズの処理に関するブログ投稿と、このアプローチがlibgdxを使用してJavaでコーディングした方法の2番目の部分です。アンドリューの答えに少し似ていますが、他の誰かを助けるかもしれません。

ブログの投稿では、3つの主なアプローチについて説明しています。

1. 上部または側面に黒いバーがあります。
2. 仮想ビューポートを使用します。
3. Webページのフレックスボックスレイアウトで見られるように、フローティング要素を使用します。

1番はかなり自明です。

いいえを説明するために 2、3つの異なるアスペクト比を持つ3つの異なるデバイスをサポートするとします。画像エディターで画像を開きます。最初のデバイスについては、そのデバイスのアスペクト比で、画像内に収まる最大の長方形を描画します。2番目のデバイスと3番目のデバイスについても同じことを行います。使用可能な領域、つまり仮想ビューポートは、これら3つの長方形すべての交差点です。そのビューポートの外にあるものはすべて表示されることを保証できません。

3つ目は、フレックスボックスまたはフロートを使用してWebページに要素を配置する方法と同様に、画面にオブジェクトを配置することです。たとえば、一時停止ボタンを上から5ピクセル、右から5ピクセルに配置します。デバイスのアスペクト比に関係なく、一時停止ボタンは常に右上隅にあります。