拡張性は単なるグラフィックスの設定ではなく、ターゲット プラットフォームを選んで、そのプラットフォームに合うアート、ゲームプレイ、サウンド、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 があります (例、Intel HD グラフィックス 4000 はバッテリを節約するため、NVIDIA 580m はパフォーマンスのため) 。デフォルトでより高速な GPU で実行したいでしょうが、両方でテストするのが最適です (これを変更するにはドライバの設定を使用します)。 バッテリで実行する場合、より遅いものを選ぶか、ランタイムに切り替えることさえあります。
プログラマー
プレイヤーはプレイヤーのシャドウを先に見るか、より高いフレームレートを持つことで応答時間を速めるメリットがあります。与えられた拡張性設定内に留まることは、不正ではありませんが、拡張性設定の中には不正目的で乱用されうるものがあります。コンソール変数は拡張性のために必要なものよりも幅広い範囲の値を提供することがあり、コンソール変数の設定を組み合わせたものが問題につながる場合があります。マルチプレイヤー ゲームの中には、サーバーの管理者が問題のある設定をオーバーライドし、プレイヤー全員に均等な機会を与えることで、この問題に対処しているものがあります。
例：生い茂った草むらに隠れることはゲームプレイ上優れた戦術です。しかし、草むらがより大きな視界距離ではレンダリングされない場合、これはプレイヤーが隠れようとするには非常に不適切だと感じるかもしれません。
拡張性の設定がゲームプレイに影響を与えないのが理想です。
リード、プロデューサー、マネージャ
マネージャ / リードは何を知っておくべきでしょうか? 幅広いハードウェアにスケーリングする必要があるゲームを開発するのは難しく、時間と QA の労力をより多く費やすことになります。以下のいくつかのグッドプラクティスが助けになるでしょう。
- プロジェクト開発の早い段階で低スペックと推奨スペックを定義します。
- ほとんどのプレイヤーはオプション メニューを決して使用しないため、優れた "auto" 機能が重要になります。この機能を適切に得るには、多くのイタレーションとテストが必要です。
- 拡張性の範囲が狭いほど開発は簡単になります(悪い例、ハイエンド PC からローエンドのモバイル)。
- 一番下から 2 つめに低い低スペック マシンを用意すると、あらゆる面 (コード、デザイン、アート) で役立つことがあります。タスクの均衡をとる場合、より多くの拡張性を生み出すよりも最適化する方が良い場合があります。
- パフォーマンスは拡張性の一部ですが、安定性にも影響を及ぼす場合があります。例:低スペックでメモリが不足したら、高解像度のテクスチャ オプションをグレイアウトすることが最適な場合があります。
- ローエンドの拡張性は、より多くのプレイヤーがゲームでプレイできることを意味します。ハイエンドの拡張性は、特にスクリーンショットとテストでゲームの見栄えがよくなることを意味します。