ゲームのロード前の時間とゲームのロード時間の比較


9

ランダムな迷路を組み込んだゲームを開発しています。
迷路の中に潜むAIの生き物がいます。そして、迷路の形に合わせて、ある道を進んでほしい。

これを実装するための2つの可能性があります。最初の方法(私が使用した方法)は、迷路が作成されたら、必要ないくつかの潜む経路を計算することです。
2つ目は、一度計算が必要になったパスを計算することです。

私の主な関心は読み込み時間です。迷路の作成時に多くの経路を計算すると、プリロード時間が少し長くなるので、必要に応じて計算を考えました。
現時点ではゲームは「ヘビー」ではないので、ゲームの途中でパスを計算することは目立ちませんが、複雑になると心配になると思います。

どんな提案、コメント、意見も役に立ちます。

編集:

今のところ、p事前に計算されたパスの数とすると、クリーチャーは既存のパスではなく新しいパス(パスの計算を意味する)1/pをとる確率があります。 もちろん、パスが完全に計算されるまで、クリーチャーはパトロールを開始しません。そのため、その過程で彼が死亡することを心配する必要はありません。


8
この時点で、それは事前に最適化されます。問題が発生するまでそのままにしておきます。
ジョンマクドナルド

3
そして、@ JohnMcDonaldで少しチャイムするために、ゲームの途中でこれらのパスを計算でき、それが目立たない場合、ロード時にどれだけの要因が貢献できるでしょうか?
James

回答:


6

BerickCookはアイデアを正しく表現しています。現在正しく機能している場合は、計算をそのままにしておきます。

以前に計算を行うことができ、ゲームの途中でそれらを必要としないと確信している場合は、前に計算してください。それ以外の場合は、ロード後に行います。ゲーム中の計算が目立たない場合は、そこで行うことができます。ある時点で複雑さが進化し、計算が重くなりすぎたら、最適化を開始します。

ただし、1つ重要なのは、ゲームの途中で実行するように計算が実装されている場合は、ロード中に常に強制的に実行することです。

多数のソリューションがあります。

  • レベルの作成/ロード中にパスを計算/ロードする
  • 2番目のスレッドを使用してパスを計算する
  • アルゴリズムを最適化する
  • スレッディングにアクセスできない場合は、割り込み可能なシステムを使用してください。

私はマスマーケットゲームで最後のオプションを見て使用しました。計算を再開するために必要なすべてのデータを適切に保存し、計算中の残り時間/操作を定期的に確認するだけです。

あなたのケースに応じて、割り込み可能なシステムは、計算が終了する前にイベントを使用できる予備的および部分的なソリューションを提供できます。


編集:@Keeperに応答する

「割り込み可能なアルゴリズム」は、私たちが持っていた制約のためにのみ有用でした。基本的には、マルチスレッド化の欠如を緩和しました。

ある時点で、AIが複数の辞書に基づいて大量の動きを計算しなければならないゲームがありました。この計算中にすべてのアニメーションが停止します。これは、より多くのデータでディクショナリが拡張され、データを保持するデータセットが変更され、ゲームがマルチプレイヤー(AIがプレイヤーの動きに対しても相互作用する必要があった)に適応したときに効率が低下したためです。ゲームループで使用できるスレッドは1つだけでした(マルチプラットフォームコードはサポートされているすべてのプラットフォームで実行する必要があることが必須です)。この時点で、計算アルゴリズムを中断して中断できるようにすることにしました。そのため、変数を保存できなかったため、配置されていた再帰システムをそのまま使用することはできません。関数は、必要なすべての変数と親オブジェクトと子オブジェクトへのポインターを単に保持するオブジェクトに置き換えられました。私はしません

  • 現在の計算のステータスを保存する
  • ループの終了時またはループ中(子オブジェクトが中断したとき)に割り込みます
  • タイムアウトしたときに終了する
  • 正しいインデックスでループを再開するか、現在子スタックの最上位にある子オブジェクトを呼び出すのを停止したところから再開します。
  • 計算が中断された場合、すべてをクリーンアップします
  • 最良の部分的な結果を与える。

最も高価な操作のみが個別のオブジェクトに分割され、計算を停止できる適切な場所を見つけるのにしばらく時間がかかりましたが、最終的には非常にうまく機能しました。

パフォーマンスは低下しましたが、アニメーションはすべてのプラットフォームでスムーズに実行されたため、ユーザーにとってパフォーマンスははるかに優れていました。すべてのプラットフォームで、アニメーションが途切れたりフリーズしたりすることなく、より大きな辞書を使用できました。また、これにより、後で必要になったときに複数のインスタンスを並行して実行できました。

もちろん、現在iPhoneとiPadではゲームにこれは必要ありません。2番目のスレッドを使用するのが理想的です。しかし、コードはまだそこにあると思います。


ありがとう、それはとても興味深いですね。「割り込み可能なシステム」の概念について詳しく説明していただけますか(理由と方法)。(ググるのはあまり役に立ちませんでした。)。質問にいくつかの詳細を追加します。
キーパー

@キーパー私は中断可能な部分についてのあなたの質問に答えることを望みます。これは大変ですが、行う必要があり、最近のほとんどのシステムには関係ありません。
コヨーテ

今はこの方法を使用しませんが、あなたは新しいことに目を向けました。あなたの答えは受け入れられるに値する。
キーパー

8

今のところ、ゲームの途中でパスを計算することは気付かないので、それが理想的なアプローチです。計算によってゲームプレイが中断されるポイントに到達したら、レベルが読み込まれる前に、パスごとの計算に切り替えます。

初期読み込み時間が長くなることは許されますが、一般に、プレイ中のランダムなFPS変動は許されません。


2

最近ではほとんどすべてのPCに複数のCPUコアがあるため、必要に応じて計算を2番目のスレッドに移動することもできます。

基本的なプロセスは次のとおりです。

  • クリーチャーがパスを要求したら、その要求をスレッドセーフの要求キューに追加し、スレッドに信号を送ります。
  • スレッドがそのキューからエントリをポップして処理し、完了したリストに追加するのを待つ間、クリーチャーはアイドル状態です。
  • 各フレームはメインスレッドの完了リストをチェックし、完了したパスをクリーチャーに割り当てます。

いくつかの余分なエッジケースにも注意する必要があります(たとえば、リクエストが処理される前にクリーチャーが死亡した場合はどうなるか)。


2
スレッド化を導入したくない場合は、パスを段階的に計算することもできます(たとえば、フレームごとにいくつかのステップを計算します)。
bummzack 2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.