すべてのゲームで起動後の読み込みを回避できませんでしたか？

巨大なオープンワールドゲームが巨大なマップを動的にロードするように、個別のマップ、メニュー、およびほぼ同じインターフェースまたは3D設定を同じ動的ロード方法でロードすることはできませんか？環境を変更せずに、ゲーム内のインターフェイスやさまざまな場所をすべて、動的にロードすることができます。これは、大規模なオープンワールドマップをロードするのと同じ方法でロードされます。

なぜこれが行われないのですか？試合/マップ/レベルの読み込み中に1分以上待たなければならない最新のゲームがたくさんあります。ピアの接続に遅延が伴うことは知っていますが、私の経験では数分しかかかりません。マップ/レベル/インターフェースデータのロードに伴うロード時間を排除するためにこの概念を使用するのを止めるために、この概念にはどのような問題がありますか

答えはイエスです。これはほとんどの場合、少なくともある程度までは可能です。

それが行われない理由はたくさんあります：

• 正しく行うには時間とお金が必要です。
• テストに合格したバグの量はより多くなります
• ロード時間はユーザーに受け入れられます。
• サーバーの負荷分散など、読み込み時間には他の理由もあります。
• すぐに購入できる一般的なソリューションは、「一括ロード」との互換性が高くなります。

メニューに大量のアセットがある場合、それらのアセットの読み込みには時間がかかります。また、人々があなたのメニューをナビゲートする順序がわかりません。オプション->戻る->クレジット、またはクレジット->戻る->連続してゲームを開始します。したがって、合理的なストリーミング戦略はありません。

オープンワールドゲームでは、プレーヤーが特定の速度より速く移動することはないことがわかっているため、遠く離れた場所の詳細なバージョンをそれらが近づくまでロードする必要がないことがわかります。

このようなソリューションの実現可能性における大きな要因は、ロードが必要なものの予測可能性です。プレイヤーがまったく新しいレベルをロードし、何を選択するかを予測する方法がない場合、完全にシームレスなソリューションは不可能です。たとえば、プレイヤーがゲーム内の任意のレベルを選択してプレイする場合、またはオープンワールドゲームの完全に異なるエリアにテレポートする自由がある場合。

一部のHaloゲームは、マルチプレイヤーゲームのセットアップ中に、選択したレベルのバックグラウンドでの読み込みを開始します。これにより、プレーヤーが開始する準備ができているときの待機時間が短縮され、プレーヤーが完全に異なる資産を持つ異なるレベルを自由に選択できる場合、おそらくこのようなソリューションに最も近いものです。

もちろん、「環境を変えずに」と言いましたが、Haloの例を取り上げたいと思いました。

継続的なキャンペーン内で、または開発者がプレイヤーの位置を十分に制御できる場合、そのようなソリューションは、あなたが言うように確かに実行可能です。Naughty Dogはロード時間をなくすことを好み、JakとDaxterはPS2でロード時間を持たないことで有名であり、Unchartedゲームは最初に1つのロード時間を持ちます。

ただし、多くの人にとって、読み込み時間は解決する必要がある問題ではありません。または、開発者の優先順位が非常に低い問題であり、現在からリリース日までの間にさらに多くのことができる場合があります。

時間。

時間を節約するには時間が必要です。または、時間の不足を補うためにお金が必要です。いずれの場合でも、「読み込み時間はありません！」余裕がある人だけが提供できる機能です。それには非常に慎重な計画が必要であり、自分が何をしているかをよく理解する必要があり、すべてのゲーム開発者がそれを使用するリソースを持っているわけではありません。

最終的に、それは限られたリソースです。

オープンワールドゲーム、特にMMOは予測可能性に向けて細心の注意を払って作成されています。事前にロードする必要があるデータを常に把握しています。これは世界のアーキテクチャで見ることができます-ロードする必要のあるリソースがたくさんあるときはいつでも、ユーザーがまだロードされていないものを見ることを防ぐ何らかの方法があります。最も一般的な方法は、積み込みに必要な数秒間、次のエリアへの視界を遮る門と入り口です。また、ほとんどのMMOは詳細度の低いモデルとテクスチャを使用するため、ロード時間が大幅に短縮されます。

慎重な設計を行っても、いくつかのことはまだ予測不可​​能です。たとえば、プレーヤーが着用するカスタムバナーがあり、関連するデータがネットワーク経由でコンピューターに送信されると表示されます。もちろん、ほとんどのゲームはこれを制限して安くします（たとえば、Diablo IIIのバナーは単純な構成で、数バイトのデータとして簡単に送信できます）。しかし、最終的には、データが届くまで待つ必要がある場合があります。また、ロードの進行中に何かを表示する必要があります。多くのゲームでは、データのロードを待機している間に灰色の詳細度の低いモデルが表示されるため、没入感が失われる可能性があります。

そして、これらすべてのことから、このような読み込みは解決された問題（TM）ですが、それは簡単にはなりません。スムーズなプレイ体験を確保するためのリソースとその利用の最適化、およびコード自体の両方で、多くのリソースと時間がかかります。非同期コードは困難です。また、すべてがうまく行ってもゲーム体験が低下することを意味する可能性があります-最も一般的な分母の帯域幅機能を超えないようにする必要があるため、モデルとテクスチャの品質を下げるか、それらを作成する必要があります変化が少なく、あなたの世界の幾何学は厳しく制限されています。そうしないと、ゲームはまったくプレイできなくなります-マップをロードするのに10分（またはそれ以上）かかったゲームをプレイした人を覚えていますが、それは単にコンピューターがタスクに完全に対応していなかったためですその後、それ自体は正常に動作します。代わりにシームレスなロードがある場合、ゲームはデータがロードされるのを待っている間、常にフリーズするか、見苦しいテクスチャとモデルを表示します。遅延読み込みはwin-winではなく、エンジニアリングのほとんどのものと同様にトレードオフです:)

動的な読み込みが、他の回答が実際に考慮していない理想的なソリューションであるとは限らない理由の1つは、ポップインやその他のグラフィックアーティファクトでもあると思います。

何をロードするか、何をロードしないかを予測することはしばしば失敗します。これの最悪の例の1つは、Rage by id Softwareにありました。少なくとも初期のバージョンでは、メガテクスチャシステムがそれを作成したため、回転するようなものでも、大量のテクスチャやジオメトリアーティファクトがゆっくりと消えていく前に現れました。

これらの問題は、すべてがプリロードされているため、問題ではありません。

考慮すべきことは、必ずしもロードするものではなく、アンロードするものです。スペースの予算が限られている場合、新しいものをロードするとき、削除する古いものは何ですか？これらのアセットが今後数秒以内に使用されないことをどの程度確信していますか？これらは解決が難しい問題です。

すべてのゲームプレイ状態が共通のシステム予算内に収まるほど小さい場合、ロードするのではなく、すべての利点が明らかになります。レベルにまっすぐ進むだけで、プレイ中に物事がフェードインします。しかし、主な答えが示唆するように、小さなゲームのロード時間は、とにかく心配するほど長くはありません。

動的ローディングシステムが最初に作成された理由について考える価値があると思います。ゲームプレイ状態のいくつかは一般的なシステムには大きすぎる可能性があり、そのサイズのゲームは完全にプリロードすることができないことを知っているからです。

一般的な理由の1つは、近い将来にリソースが必要になるかどうかを判断するのが常に同じように簡単ではないことです。

例としてテレインページングを使用したので、それを続けます。

特定のマップグリッドにいて、隣接するすべてのマップグリッドをバックグラウンドで読み込む場合は、まったく合理的です。ユーザーがせいぜいそれらの1つを入力できることを知っています。その場合、隣接していないものをアンロードして、現在のものをロードできます。これに注意しました。

今、速い旅行を想像してください。ユーザーがどこに行くかを予測する方法はまったくありません。（通常）ほぼすべてのマップから選択できます。すべての可能な高速移動場所を事前に読み込むと、メモリが非常に多くなり（最初にマップ全体をメモリに読み込むこともできます）、時間がかかりすぎます（マップ全体が事前に読み込まれていない場合）。これはいつ起こりますか？彼らは高速旅行ダイアログを開くとき？問題は数倍悪化するだけです！

これが、「ロードなし」の地形ページングを備えたほとんどのゲームでさえ、高速移動時にロード画面を保持する理由です。また、十分に速く移動すると、マップがロードされていないゲームでもロード画面をトリガーできることがあります（TES Oblivionでこれを行ったことを思い出します）。

ここで、これが一般的にゲームリソースに適用されることを想像してください。多くの場合、関係は明らかではありません。可能なすべてのオプションをロードするか、ユーザーが何をしようとしているかを推測する必要があります。推測はコストがかかり（開発とCPUの両方で）、プログラムを作成するのは複雑です。具体例：

• ファイルの保存：ユーザーが保存画面に到達する前にすべての保存ファイルをロードするか、ロードするファイルを推測する必要があります（最新5など）。
• UI：多くの戦略ゲームは、派factに応じてUIを変更します。ユーザーがゲームを開始する前に、考えられるすべてのUIデザインを読み込む必要があります。
• ゲームの世界：MinecraftやCivilizationのようなRTSゲームのような手続き的に生成されたゲームでは、さまざまな程度で見るまで世界は存在しません。そもそも存在しなかったため、これをプリロードすることは不可能です。それらの事前計算は、せいぜい事前ロードと同様に行うことができ、RTSの場合には適用できません。

これらの問題のいくつかを回避する方法があるかもしれませんが、それを理解するには現実のお金がかかります。ほとんどのゲーマーは、合理的なローディング画面を受け入れ、もしあれば、それらを軽減するためにハードウェアにより多くを費やすことをいとわない傾向があります。異常に過度であるか破壊的でない限り（レベルの途中でロードするなど）、ゲームの問題ではなくハードウェアの問題と見なされます。

バックグラウンドでの読み込みは無料ではありません。通常、バックグラウンドローディングテレインと一部のモデルファイルの現代的な使用による影響は最小限ですが、突然多くの異なるリソースについて推測している場合、特に信頼できるメトリックがなく、多くのリソースをアンロードして余分なリソースをロードする必要がある場合、システムをほこりにすることができます。

バックグラウンドローディングのアイデアは、より良い使用のためにデッドサイクルを使用することですが、使用するデッドサイクルはそれほど多くありません。メモリについても同じことが言えます。プリロードにより、ゲームのメモリ使用量が大幅に増加します。ロード画面を使用すると、既存のリソースをダンプできます。バックグラウンドでロードするような贅沢はありません。つまり、それだけでゲームのメモリ要件を2倍にすることができます。

これは、ゲームがソフトリアルタイム製品であり、コンテンツの遅延配信がオンタイム配信ほど有用ではないという事実に起因する一般的な問題です（ハードリアルタイムとは対照的に、コンピューターの車のように、配信が遅れる場合）まったく配信しないよりも良いことはできません）。何をどこに読み込むかを決める必要があります。

配送が遅れることが特に悪い場合があります。たとえば、すべての壁がロードされる前に世界を走り回ることが許可されている場合、移動する前にゲームが壁をロードした場合、決して背後に到達することはできなかった壁の後ろに行くことができます。コンテンツの「怠lazな」読み込みで逃げることができるとき、およびコンテンツが完全に読み込まれることを保証する必要があるとき、それを伝えるのは必ずしも簡単ではありません。

動的ローディングもはるかに複雑です。リソースがまだロードされていない場合の対処方法を常に検討する必要があります。これは開発リソースの浪費です。存在するリソースに依存できる場合、開発ははるかに簡単です。

レイテンシも常に許容できるとは限りません。Starcraftで、動的にロードされたすべてのモデル/イメージをキャッシュするという副作用を持つマップをロードすることにより、ゲームを「ウォームアップ」するケースを聞いたことがあります。その後、終了して、通常どおりゲームをプレイします。エリートゲーマーの場合、これにより、実際にゲームプレイに影響するGUIのst音が最小限に抑えられました。どのレイテンシがユーザーに受け入れられ、どのレイテンシが受け入れられないかを証明しようとするのは難しいことです。