レベルを再起動すると、ゲームがレベル全体をリロードするように見えるのはなぜですか？

プレイ中にデータは実際にそれほど変更されていますか？

レベルの再起動間の長い休止は、レベル全体の再読み込みであると想定しています。しかし、適切に実装されたシステムは、レベルの最初に「ping」できる必要があるように思えます。

コンソールではより目立ちますが、PCゲームでは目立ちません。

さて今-取り組むべきシンプルだが興味深い質問です。

レベルをリロードする場合、考慮に入れる必要のある非常に多くの要素があり、答えは多くの方法で進むことができます。

レベルの状態にアセットの大きなリストが含まれている場合、レベルをリロード時に正確な状態を維持しますが、多くの時間をかけないため、レベルを保存/ミッション状態にリロードするときにクリーンな状態から開始する方が実用的です処理の。ただし、考慮すべき数が少ない場合は、アセットのみをリセットする方が効率的です。これらの小さなレベルでアクションをすばやく再開できることを確認してください。後者は特に、シーンに何も保存する必要がない場合、またはゲームでの選択の影響を受けない場合-村を最初に走ってから死体を保存する必要がない場合はそうではありませんそのレベルに戻る途中でリロードする必要があるため、プロセッサ時間を節約し、状態へのアクセス時間を節約できます。

考える良い例は、そのプレイスルー中に永続的な状態を持っていた地形破壊/弾丸デカールを使用したファーストパーソンシューターでしょう。

レベルを破棄して再ロードするのではなく、レベルを巻き戻す場合は、変更されたすべての状態をトレースする必要があります。ロケットで壁に穴を撃った場合、壁から落ちてくる破片から地形のギブを生成し、壁のモデルが変更されて穴が生成され、きれいに見えるように生成されたパーティクルエフェクトがあります。これを「再起動可能な」状態に巻き戻すことでクリーンアップするには、次の手順を実行する必要があります。

• その壁用に動的に生成されたジブを削除します（ただし、ロードした状態からは削除しません）
• 銃弾の穴からほこりのパーティクル効果を削除する
• 壁を交換/修復して、作成した穴を取り除きます
• プレイヤーの弾薬をリセットする
• 等...

レベルを巻き戻すためにトレースするリソースが非常に多いため、単純にレベル全体を破棄し、デフォルトまたはミッション固有の状態ですべてのアセットを再ロードすることで、多くの場合プロセッサの負荷が軽減されます。特定のオブジェクトをリセットするには、シーン内のオブジェクトのリストを検索し、それらのプロパティにアクセスしてリセットします。クリーンアップによって修復される壁の弾痕の代わりに、クリーンアップアクションを計算する必要はなく、メモリからレベル全体を削除して、ゼロから再ロードするだけです。

これは、レベルのリロードが1つの状態オブジェクト（ゲームファイルの保存またはミッションスクリプト）から行われ、動的な計算を必要としないことを意味します。コンソールの場合、これはディスクの読み込み時間によって悪化します。また、ロード時間を許容できるようにする処理能力を持たないコンピューターを考慮することができるため、PCゲームにも役立ちます。

したがって、コンテンツレベルが大きい場合-状態を計算して「巻き戻す」のではなく、単一の状態をロードします。

• プロセッサー集約度が低い
• 低層マシンでより効率的
• ミッションスクリプトとセーブファイルを同じ方法で使用できるようにします（レベルの再起動時にセーブ状態またはミッションチェックポイント状態をロードするために同じローディングシステムを使用する可能性があります）
• レベルをリセットする開発者としての作業が少ないことを意味します -追跡して巻き戻すよりも、セッションデータから完全な再読み込みをプログラムする方がはるかに簡単です。これがおそらく最も影響力のあるポイントです

しかし、反例として、格闘ゲーム（Street Fighter 4の実生活での素晴らしい例）では、レベルを再起動するためにそれほど多くのアセットをリロードする必要はないかもしれません。2人のプレイヤー、レベルの環境状態、および単純なレベルタイマーはほとんどが静的であり、動的ではありません（プレイヤーのヘルスは常に各ラウンドで100％で再出現し、タイマーは90秒にリセットされ、レベルには銃弾の穴がありません[または！] ）そのため、レベルをリセットすることは、戦闘機を完全に健康にし、環境を元の位置に戻すことです（一部のレベルの見物人のように）。

したがって、再戦を行うときの戦闘ゲーム（ラウンドからラウンドへの移行ではない）の場合、次のことが必要です。

• 体力とエネルギーを最大またはデフォルトにリセットします（キャラクターごとに常に同じです）
• タイマーをリセット
• キャラクターの開始位置をリセット
• 地形をデフォルト状態にリセットします（修正またはリロードするための弾痕はありません！）

そして、それは本質的にリスト全体です-つまり、フルレベルのリロードの代わりにクイック状態リセットがより実行可能であることを意味します。これは、最初に試合を開始したときの読み込み時間によっても示されます。すべてのキャラクターとレベルのモデルをロードするのに長い時間がかかりますが、既にロードされたモデルとのマッチの間でキャラクターの開始位置をリセットするのに数プロセッサーのチックだけです。

試合は通常1分間しか続かないため、プレイヤーは非常に速くアクションに戻りたい傾向があるため、これは戦闘ゲームの需要が高い要件であることに注意することが重要です-この答えはゲームに非常に依存していることを強調しますとジャンル。FPSはより動的なアセットを要求し、ファイターは迅速で反復可能なアクションを要求します。

これがあなたの質問にいくらか光を当てることを願っています。

コンソールに関するあなたの質問に対する既存の答えを明確にするために：彼らはより大きな複雑なゲームの開始状態と現在の状態の両方を保存するのに十分なメモリを持っていません。

ゲームはレベルと初期状態を別々に保存して、状態だけをリストリームできるようにすることができます。これは多くのゲームが行うことです。ただし、ストリーミングだけでも、メモリに保存されている場合よりもかなり遅くなります。

「最適な」最新世代のコンソールには、CPUデータとグラフィックス間で共有される512MBのメモリしかありません。それは小さいです。コンソール開発の現在の頭痛の種の1つは、このような少量のメモリで今日の品質レベルを満たすゲームに適合することです。キロバイトのカウントは、特に出荷日の近くで重要になる可能性があります。レベルの初期状態のコピーを保存すると、ある程度のデータがなくても実行でき、レベルの再読み込みを高速化するだけでなく、プレイ中にゲームをより面白くするためにより多くのメモリを使用できます。

理想的には、プレイヤーはゲームをプレイして死ぬと再起動するよりも多くの時間を費やすので、プレイ中のより良い体験のために最適化する方が理にかなっています。

次世代のコンソールと8GBのメモリにより、状況は大きく変わる可能性があります。または、単純に高解像度のモデルとマテリアル、多数のアクティブなゲーム内オブジェクトを使用して、同じままにすることもできます。時が教えてくれる。通常、PCゲームは2GBのRAMと512MBのVRAMを搭載したマシンをターゲットにしているため（多くの場合、はるかに大きな値に拡張できます）、8GBの新しいコンソールは最低限のベースラインに関しては非常に豪華です。近い将来、64ビットCPU / OSと4〜8 GBのRAMと1〜2 GBのVRAMを必要とするゲームへの移行が行われる可能性があります。スナップショットを高速化するために複数の状態をメモリに保存することは、はるかに簡単です。

Blueの答えの多くには同意しません。レベルをリセットしないという技術的なケースがあるとは思いません。レベルのロードは、レベルのリセットよりもほとんど常に遅く、実際、そうでない場合を想像するのは難しいと感じています。ほとんどの場合、開発者が選択した場合、ゲームは効果的にインスタントレベルのロードを提供できます。

提案されているように、本当の答えは簡単で迅速です。とにかくレベルの繰り返し読み込みはゲームに必要なものなので、これをレベルの再起動に再利用することは比較的簡単です。リセットには、新しいバグやメモリリークの可能性が非常に高い複雑な新しい経路が必要であり、開発者の時間をまかなうことが必要です。場合によっては、メモリ制限を押し上げることもあります。ゲームが開発者の時間をかけずに開発されることはめったにないため、レベルのリセットなどの項目は、特にゲームアーキテクチャがそもそも最高に構築されていない場合、途中でドロップされる傾向があります。

リセットには「巻き戻し」が必要な状況が考えられると思いますが、実際にはほとんどのゲームは元の状態を保存するだけでよく、保持されたオブジェクトの状態に完全にリセットする効果的な手段とオブジェクトにフラグを立てる手段を提供しますリセット時に破棄します。ゲームの状態情報も保存し、復元できる必要があります。この種の情報は、通常、レベル全体の要件と比較してメモリが比較的軽いため、これによりディスクからのデータの低速で高価なロード（テクスチャやモデルなどの大きなアイテムを含む）の必要性がなくなり、 -シーンのメモリパス。

メモリが限られている場合でも、大きなレベルまたはシームレスなレベルのゲームプレイを可能にするために（メモリが常に小さすぎる場合、最初にRAMで、またはグラフィックスカードで制限に達するかどうかが問題になります）、別の戦略があります：

プレイヤーが現在必要としている、または数秒で必要になるレベルの一部のみをメモリに保持します。おそらくもう必要ないモデル、テクスチャ、サウンドサンプルなどはメモリから削除されます。

Dungeon Siegeが思い浮かびます（開発者はかつて、メモリ管理は実際のゲームプレイよりも多くの処理能力を必要とすると主張しました）、ほとんどのMMORPGSがそれを行います。レベル（または30秒前のリスポーンポイント）が（完全に）メモリ内になくなっている可能性があります。

多くの場合、新しいリロードが最も簡単な方法であり、最も安価な方法であり、おそらく最速の方法です。

編集：ダンジョンシージのロードメカニズムに関する論文です：ダンジョンシージの連続世界

物理的なプラットフォームの制限と賛否両論の決定に関するSeanとBlueの優れた回答を使用して、コメントを別のアプローチに拡張します。

レベルを完全にリロードする必要がある理由

これで、loadLevel（）呼び出しが完全に機能するようになりました。レベルファイル情報をストリーミングし、それに基づいて世界を構築し、オブジェクトを作成し、進行中にテクスチャとサウンドをロードします。次に、すべてが完了したら-または再生を開始するのに「十分」に完了したら、startPlay（）を呼び出すと、ワールドが表示され、音楽の再生が開始されます。

レベルの終了、メニューへの脱出、またはゲームの終了時に、unloadLevel（）を呼び出して保持していたすべてのリソースとメモリを解放し、スムーズなエクスペリエンスを実現します。

さて、「再起動レベル」機能を追加したい場合はどうなりますか？まあ...

unloadLevel(currentLevel);
loadLevel(currentLevel);
startPlay();

これで完了です！新しいコードはなく、わずか数個の単純な関数呼び出しだけで、すでにすべてを作成してデバッグしているので、新しい光沢のある再起動機能がリストから削除され、おそらく二度と出会うことはありません-残酷で、錆びないコード最高の種類です！コードをrestartCurrentLevel（）関数に移動すると、そのコードを折りたたんで、再び見ることはできません-もちろん、再起動するレベルがあることを確認した後、もちろん:)

しかし、これは無駄ではないのか、とにかく再びリロードしようとしているものをアンロードするのではないかと思います。レベルとリソースが小さい場合、取得する必要があるのは、遅いシステム（および古いスマートフォン）でも「再起動」が呼び出されるたびに数秒の読み込み時間です。「時期尚早の最適化」、あなたはあなたの時間とよりよい事を持っている。

ああ、しかし今、あなたのレベルは成長しており、テクスチャはより詳細になり、サウンドトラックは512kbpsですべての音声および音楽レイヤーの個別のチャンネルでリッピングされました（そのとき、それは良いアイデアのように思えましたが、理由は覚えていませんが） ..）そして、「状態起源のボクセル光線追跡多次元フーリエ変換行列」についての何かは、あなたが完全に作り上げられたものであり、実際のものではないと思います。実在の人々でテストしたこともありますが、実際には待ち時間が似たようなゲームよりも悪いという嫌悪感を示しています（100人のプレイヤーがいるMMORPGの首都が2秒未満で完全にロードされるとは思わないでしょうか？）、そしてそれは問題です。

それでは、どのように最適化しますか？さて、レベルの再ロードが問題である場合、レベルのロードは問題ではありませんか？単にリロードしていると思うのなら、なぜ最初にレベルをロードするだけでなく、なぜ人々があなたのレベルをリロードする頻度が高いのですか？コードエンジニアリングの問題ではなく、ゲームプレイの問題のように聞こえます。誰が何度も何度も繰り返しレベルをリロードし、ためにその楽しさを考えて、そしてちょうどそれがあった希望速くはなく、完全に回避？

最初に実際の問題を修正してください！

しかし、少なくとも時々再起動するようにゲームが設計されているとしましょう。ロード時間は十分に長く、一度実行すれば十分に避けられませんが、再度実行する必要はありません。とにかく、これはどんなゲームですか？ちょっと奇妙な問題のように思えます...高解像度のポータルのようなゲームで、パズルを繰り返し台無しにすることを想定しているのでしょうか？

まず、これは簡単ではないことを理解する必要があります。完全に新しい、テストされていないコードを記述する必要があります。レベルプレイ間で何が再利用されるか、または再利用されないかさえわからないように、「状態依存」です。レベルにランダムな要素、スポーン、可変テクスチャー（スケルトンは時々鎧を着るだけですか？）、または他の変化する要素がありますか？衣装やカスタマイズされたモデル、色/ドア/トラップなど、プレーヤーによって異なるものはありますか？

あなたは比較をするつもりです、そしてそれらの多く。レベル要素をループして、必要なものと現在ロードされているものを比較します（このレベルではなく最後のレベルでロードされたもので何をしますか？負荷？）。これがゲームにとって本当に大きな問題である場合は、ロード/アンロードコードを変更して、ロードする前に何かが既にロードされているかどうかを確認することをお勧めします近い将来使用されないリソースを慎重にリリースします）。はぁ。

何をするにしても、たとえあなたのゲームが単純であっても、レベルを最初にロードしたときに起こらないレベルが再起動されたとき、レベル/プレイヤーの状態に基づいた不明瞭なバグに陥ります。したがって、次のようなテキストを使用してゲームの更新を記述できます。

「爆弾のヘルメットを近くにミサイルが爆発したタイルの上に落としても、水域から200ピクセル以内にあったとしても、ゲームデータが破損したり、ゲームがクラッシュしたりすることはありません。」

ほとんどのゲームが気にしない本当の理由

ほとんどの人が既存の壁をベースレイヤーに剥がす代わりにペイントまたは乾式壁にしたり、カーペットを引き上げるのではなく堅木張りの床の上に敷いたりすることに気づいたことがありますか？

単純な事実は、最小限の報酬を得るためのすべての作業であることです。ほとんどの場合、既存の壁の塗装はうまく機能します。また、堅木張りの床を破ることの価値は、ほとんどないか、まったくないことがよくあります。

ゲームからマルチメディアパワーポイントプレゼンテーションに至るまで、ソフトウェアでも同じことが言えます。読み込み画面から数秒を削るだけで、ユーザーが見る時間の1％を費やすことができれば、信じられないほど簡単になります。投資した時間に対する非常に低いリターン。

そのため、ほとんどのゲームは気にせず、いくつかの極端な例を除いて、画面をロードすることで優れたゲームの価値が低くなる非常に多くのゲームを考えるのに苦労しています。極端な例は、より高速なレベルの読み込みのために最適化することが理にかなっている場合であり、それは一般に公開されるゲームのごく一部であり、おそらくリリースされないため誰も見ないゲームのごく一部です。

静的なゲームデータ（テクスチャ、地質情報、影響を受けていないMobなど）をメモリに保持し、動的なデータ（プレーヤーの位置、プレーヤーの統計、クエストステータス、インベントリなど）のみを再ロードするという反対の動作を開発するのは難しいため。

より多くのお金と時間を要するため、ゲーム開発者は通常それを行いません。