タワーディフェンスゲームのA *実装でのパフォーマンスが遅い

定義済みのパスを使用せずに、タワーディフェンスゲームをFlashで作成しています。

私のグリッドは40x40（小さい？）ですが、A *は毎回再計算するときに苦労しています。そのため、再計算を簡単にするために独自の変更を加えたため、タッチされたセルの数は約900に減少しました（ルートの近くで変更した場合）。新しいタワーが設置されると、非常に短時間ですが検出可能な時間はフリーズします。

これは実装の問題ですか、それとも40x40が多すぎますか？

編集：

私のコードの構造：

• すべてのデータは、セルの2D配列に保存されます。
• 各セルには、パス方向の親（時計回りに1〜8）と、パス内の子のビットごとにエンコードされた配列（すべてのビットが子を表す）が含まれます。
• 検索は、ユークリッド距離の推定値を使用してA *によって実行されます。

コメントはできませんが、Flexの最初のプロファイルです。それ以外はすべて推測です。

TDは「タワーディフェンス」だと思います

このため、A *は少し行き過ぎていると思います。

ゲームの開始時に、ゲームポイントを出口ポイントから塗りつぶして、移動マップを作成します。

 |---------|
 |5|4|3|3|3|
 |5|4|3|2|2|
->5|4|3|2|1->
 |5|4|3|2|2|
 |5|4|3|3|3|
 |---------|

動きは常に低い値の正方形に向かっています。

プレーヤーがタワーを配置したら、8つの隣接する正方形のそれぞれを更新します。各正方形について、その移動値を最も低い隣接値よりも1だけ大きく設定します。値が変更された場合は、更新された正方形を中心にプロセスを繰り返します。次に、出口へのルートがブロックされていないことを確認するには、すべての正方形が値の小さい正方形に隣接していることを確認します。

プレイヤーがタワーを削除するとき、移動値を最も低い隣接する正方形よりも1だけ大きく設定し、上記のプロセスを繰り返します。

より簡単なアプローチは、洪水を再び行うことです。

奇妙なことに、私はこれに返信したと思いましたが、返信がなくなったようです。複数のステップで更新できるように検索アルゴリズムを作成します。これにより、タワーを配置してアニメーションを再生するときに、フレームごとに少しずつ実行でき、0.5秒から1秒の間で更新を行うことができます。 A *目立った一時停止はありません。それは待ち時間です-あなたはそれをスピードアップできないiF、それを隠す方法を見つけます。タワーを配置しながらアニメーションを再生するのはゲームにとって自然なことであり、imoを非表示にするのに適しています。

まず、配列をベクトルに変更できます。速度が向上するはずです。コードを投稿すると、さらに最適化を提案できる場合があります。

あなたのスローダウンは、すべてのキャラクターのパスを同時に計算しているためだと思います。1つのキャラクターのパスの計算は高速ですが、シーンに20ダースのキャラクターがいる場合、それは失敗する可能性があります。

代わりに、負荷を数フレームに分散する必要があります。AIの更新をずらして、異なるキャラクターが異なるフレームでパスを更新するようにします。キャラクターが1秒後まで反応しなかったとしても、1フレームだけが悪い反応を引き起こすことはないでしょう。