表示とパスファインディングで同じタイル構造を共有する必要がありますか?


8

タイル付きの2Dマップを表示する方法を知っています。

A *を使用してパスファインディングアルゴリズムを作成する方法を知っています。

これら2つのことは、構造またはクラスを要求します。私の質問は、表示とパス計算に同じ構造を使用していますか?一部のデータを追加するためのパスファインディング要求のノード構造:x位置、y位置、F、G、Hと親ノード。表示用のタイル構造は、ほぼ1つの情報、つまりタイルの値にのみ最適化できます。

タイルの表示とパスファインディングの両方を処理する大きなクラスを使用していますか、それとも別のメソッドを使用していますか?アドバイスありがとうございます!


すばらしい質問です。これを学ぶ必要が本当にありましたが、何を尋ねればよいかわかりませんでした。
DFectuoso

回答:


6

私の質問は、表示とパス計算に同じ構造を使用していますか?

いいえ、ありません。タイルマップに直接A *を計算することで最適化を行うことはできますが、タイルに直接マップしないものにA *アルゴリズムを簡単に使用することはできません。また、A *アルゴリズムを複数のスレッドで同時に実行して、マップデータを共有することはできません。最後に、特定の移動方法ではtile = nodeの最適化が許可されません。方向転換にスペースが必要な車両は、異なる方向から同じタイルに到達する可能性があり、それぞれの場合に異なるオプションがあります。それらを1つのスコアにマージすることはできません。

したがって、データを分離しておくことをお勧めします。


それらを分離しておくのは興味深いことですが、パスを見つけるために明示的なグラフを使用する必要はありません。衝突/コスト情報だけを含む「タイルマップ」を作成して、レンダリングや論理モデルから完全に分離することができます。たとえば、タイルマップに格納されていないオブジェクトをワールドに追加する場合、(x、y)座標を使用するだけで、オブジェクトを衝突マップに配置して、グリッドベースのパス検索に使用できます。
トリニダード

3

ソフトウェア開発の観点からは、さまざまなものを分離しておくことは常に良いことです。

すばやく簡単な解決策として、すべてをまとめてゲームの詳細に取り掛かります。

拡張可能なソリューションの場合は、物事を分けてください。パスファインディングアルゴリズムが変更されたため、タイルクラスを変更したくありません。2つの構造を維持します。1つは可視のゲームタイルを表し、もう1つはパスファインディング構造を表します。理想的には、パスファインディングアルゴリズムは低レベルに保たれるので、アルゴリズムへの入力としてのx、yポイントの配列は、タイルクラスを提供するよりも優れています。アルゴリズム自体は、F、G、H値の配列を設定できます。

私はこの場合(そして私はあなたが優れたプログラマーになるために努力していると思います)、拡張可能なソリューションを選ぶべきだと思います。それはそれほど多くの労力を費やすことはありませんが、コードをよりクリーンに保ち、優れた実践を得ることができるからです。経験。


2

私はかつてAmiga 500で512x512タイルを使用してタイルベースのゲームを構築していましたが、プレイヤーは8タイルしか移動できなかったため、「9x9」タイルの「ウォールマップ」PRを生成しました。兵士。元のマップでこれを行った場合、最初に、各計算+タイルデータとパスファインディングデータの両方に必要なメモリの量が512x512のメモリを独占するようになるまで、「クリア」する必要がありました。

だから、いいえ、物事をできるだけ小さくして、あなたがそれらを調整できるように分離してください。必要に応じてオブジェクト/クラス。もう1つ考えなければならないのは、移動オブジェクトの一部がマップの特定の部分で異なる動きをする可能性があることです。例えば。砂が遅い、泳げない/泳げない、ドアを開けることができるなど

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.