スケーラビリティは単なるグラフィックスの設定ではなく、ターゲット プラットフォームを選んで、そのプラットフォームに合うアート、ゲームプレイ、サウンド、AI、他のシステムがあればいくつでもそれについて決定を下します。プラットフォームが固定のコンソールの場合は、より分かりやすいです。しかし、PC の場合は、様々な機器の組み合わせがあるため、単一のハードウェア仕様に焦点をあてることは不可能です。
そこでスケーラビリティ オプションが役立ちます。微調整を必要とする前であっても、作成しているアプリケーションが、各自が選んだ最低限の仕様のハードウェアで必ず動作するようにするために各デベロッパーが行えることはたくさんあります。
全般
以下のように、マシンによってパフォーマンス、メモリ、品質特性は異なります。
- ハード ドライブのサイズ、レイテンシー、帯域幅。
- メイン メモリのサイズ、レイテンシー、帯域幅。64 ビットではなく 32 ビットを実行するとさらに制限されます。
- CPU (1 つ以上のメイン プロセッサ、ハイパースレッディング、SSE 機能、分岐予測)。
- GPU (メモリ、マルチ GPU、帯域幅、機能、共有メモリ)。
- 解像度 (最近のノートブックは高解像度表示ですが、GPU の処理速度は遅くなっています)。
グラフィックスは、ゲームプレイにあまり影響を与えずにスケーリングする一番簡単な方法です。プレイヤーは、アプリケーションのオプション メニューからスケーラビリティ設定を調整できます。以下の項目により、プレイヤーは主観的でトレードオフのある多くの決定を制御できます。
- 1 秒あたりのフレーム数
- 解像度
- 画像品質
- モーション ブラー
- テクスチャの詳細
- ちらつき (アンチエイリアシング)
- バッテリーの寿命
アーティストとデザイナー
パフォーマンスとメモリ要件は、コンテンツ数と品質に直結します。これは非常に複雑な問題で、以下のようなものがあります。
- 多くの場合、コンテンツはターゲットのハードウェアなしで作成されます。
- ハードウェア プロパティのマトリクスは複雑です (メモリ不足だが高速、GPU は高速だが CPU は低速)。
- エンジン コードがまだ開発途中であり、コンテンツ主導のニーズに応じて最適化されます。
- 新しいハードウェアやドライバによってこうした均衡が変わります。
- 開発時間に制約があることで、最適化の取り組みが制限されます。
この問題を管理できるようにするには、以下のグッドプラクティスを行うのが最良の方法です。
- バジェットを計画し、確認します (トライアングル/オブジェクト/マテリアル/ライト数、テクスチャ/メッシュ/サウンドのメモリなど)。
- ゲームプレイに関係のないコンテンツにスケーラビリティ オプションを追加し、より低い設定とより高い設定でテストします。
- たとえば、低スペックでは散乱するオブジェクトを非表示にし、より単純なマテリアル シェーディングやオブジェクトの詳細度を使用します。
- プレイヤーのアビリティに制限を加えます。
- たとえば、可視性ブロッカー、任意の複雑な構造体を作れないようにする、破壊を制限するなどです。
- パフォーマンス特性を理解します。
- たとえば、多くのポイント ライトを持つ多くの動的オブジェクト、メッシュ パーティクル vs. スプライトパーティクルです。
- さまざまなコンポーネントを同様の比率で混在させます (一部のハードウェアは一部の機能でのみ遅くなる場合があります)。
- 悪い例としては、多くのオブジェクトで単純なマテリアル、少ないオブジェクトで多くのライトがあり複雑なマテリアルがあります。
- エンジン内のプロファイリング ツールを理解します。
QA
スケーラビリティの幅が広ければ、オプションにかかる QA の時間が長くなります。役立つグッドプラクティスを紹介します。
- 低スペック、推奨スペック、高スペックを文書化します。
- 幅広いマトリックス (低/中/高 の GPU、低/高 の CPU、低/高のメモリ) でテストを行います。
- 再現可能なシーンでパフォーマンス レベルを定義します。
- 時間経過に伴う変更を文書化し、伝達します。
- 要素を無効にすることはパフォーマンス問題を切り分ける強力な方法です (例：コンソール コマンドを表示)。
- 最低品質の設定で実行し、思ったよりも見た目が良いものがある場合、スケーラビリティの設定を見落としている場合があります (これを修正すると、より多くのプレイヤーがゲームを楽しめるかもしれません)。
- スケーラビリティのユーザビリティをテストします。混乱を招いたり、誤っていると気づいた場合は何でもレポートします。
- ユーザー インターフェース (UI) は常に識別可能で、機能するようにします。低解像度および最低品質の設定をテストし、読めないフォントや画面の外部にある要素を探します。
- 特定の拡張性レベル (例：「低」のみ) でのみアーティファクトが起こる場合、実際のコンソール変数設定 (
Scalability.iniファイルを参照) に進み、さらに問題を切り分けることができます (例：シャドウは「シャドウ品質」の影響を受ける可能性が高くなっています)。 - パフォーマンスを数値化する (統計 fps、統計単位など) 方法を理解します。ミリ秒は fps よりも役立ちます (「10fps 速くなった」は意味がありませんが、「5 ms 速くなった」は意味があります)。
- 一部のノートブックには複数の GPU があります。デフォルトでは、より高速な GPU で実行したいと思うかもしれませんが、両方でテストするのが最適です (これを変更するにはドライバの設定を使用します)。バッテリーで実行する場合、より遅いものを選ぶか、ランタイムに切り替えることさえあります。
プログラマー
プレイヤーはプレイヤーのシャドウを先に見るか、より高いフレームレートを持つことで応答時間を速めるメリットがあります。与えられたスケーラビリティ設定内に留まることは、不正ではありませんが、スケーラビリティ設定の中には不正目的で乱用されうるものがあります。コンソール変数はスケーラビリティのために必要なものよりも幅広い範囲の値を提供することがあり、コンソール変数の設定を組み合わせたものが問題につながる場合があります。マルチプレイヤー ゲームの中には、サーバーの管理者が問題のある設定をオーバーライドし、プレイヤー全員に均等な機会を与えることで、この問題に対処しているものがあります。
たとえば、生い茂った草むらに隠れることはゲームプレイ上優れた戦術です。しかし、草むらがより大きな視界距離ではレンダリングされない場合、隠れようとするプレイヤーは非常に不公平だと感じるかもしれません。
スケーラビリティの設定がゲームプレイに影響を与えないのが理想です。
リード、プロデューサー、マネージャー
幅広いハードウェアにスケーリングする必要があるゲームを開発するのは難しく、時間と QA の労力をより多く費やすことになります。役に立つ最良の方法を以下に示します。
- プロジェクト開発の早い段階で低スペックと推奨スペックを定義します。
- ほとんどのプレイヤーはオプション メニューを使用しないため、優れたデフォルトを設定します。デフォルトを正しく設定するには、多くのイテレーションとテストが必要です。
- 広い範囲 (例：ハイエンド PC からローエンドのモバイル) に対し、スケーラビリティの範囲が狭いほど開発は簡単になります。
- 低スペックなセカンド マシンを用意しておくと、あらゆる面 (コード、デザイン、アート) で役立つことがあります。タスクの均衡をとる場合、一般的に、より多くのスケーラビリティを生み出すよりも最適化する方が得策です。
- パフォーマンスはスケーラビリティの一部ですが、安定性にも影響を及ぼす場合があります。たとえば、低スペックでメモリが不足したら、高解像度のテクスチャ オプションをグレイアウトすることが最適な場合があります。
- ローエンド デバイスのスケーラビリティは、より多くのプレイヤーがゲームでプレイできることを意味します。ハイエンド デバイスのスケーラビリティは、特にスクリーンショットとテストでゲームの見栄えがよくなることを意味します。