環境
Old Lucas Arts（ScummVM時代）のポイントアンドクリックグラフィックアドベンチャーゲームは、事前に計算された経路探索を使用していました。テクニックの大まかな概要は次のとおりです。
ステップ1
各部屋の床は「ウォークボックス」と呼ばれるものに分割され、ナビゲーションメッシュのノードとほぼ同等でしたが、台形に限定されていました。例えば：
______ _____ _________ _____
\ A | B | C | D \
\_____| | |_______\
|_____| |
|_________|ステップ2
オフラインアルゴリズム（ダイクストラやA *など）は、ノードの各ペア間の最短パスを計算し、使用される開始ノードと終了ノードによって各次元でインデックス付けされた2Dマトリックスにパスの最初のステップを格納します。たとえば、上記のウォークボックスを使用します。
___ ___ ___ ___
| A | B | C | D | <- Start Node
___|___|___|___|___|
| A | A | A | B | C | ---
|___|___|___|___|___| |
| B | B | B | B | C | |
|___|___|___|___|___| |-- Next node in shortest path
| C | B | C | C | C | | from Start to End
|___|___|___|___|___| |
| D | B | C | D | D | ---
|___|___|___|___|___|
^
|
End Nodeご想像のとおり、ノードの数が増えると（N ^ 2）メモリ要件が急速に増加します。通常、ショートはマトリックス内の各エントリを格納するのに十分な大きさであり、300ノードの複雑なマップを使用すると、余分に格納されることになります。
300^2 * sizeof(short) = 176 kilobytesステップ3
一方、2つのノード間の最短パスの計算は非常に高速で簡単であり、マトリックスへの一連のルックアップだけでした。何かのようなもの：
// Find shortest path from Start to End
Path = {Start}
Current = Start
WHILE Current != End
Current = LookUp[Current, End]
Path.Add(Current)
ENDWHILEこの単純なアルゴリズムを適用して、CからAへの最短経路を見つけます。
1) Path = { C }, Current = C
2) Path = { C, B }, Current = B
3) Path = { C, B, A }, Current = A, Exit質問
あらゆるレベルでこれを行うためのメモリ要件と相まって、今日の強力なハードウェアでは、実行時に単にA *を実行することで、この手法がかつて持っていたすべての利点を上回ると思われます。
また、最近のメモリ検索は一般的な計算よりも遅いかもしれないと聞いたことがあります。これがサインとコサインのルックアップテーブルの作成が一般的ではなくなった理由です。
しかし、これらの低レベルのハードウェア効率の問題についてはまだあまり知識がないことを認めなければならないので、この機会を利用して、このテーマに精通している人々の意見を聞いています。
私のエンジンでは、実行時にグラフにノードを動的に追加および削除する機能も必要だったので（これを参照）、事前に計算されたルートだけがより複雑になったため、それを廃棄しました（もちろん、ランタイムA *ソリューションはすでに完全に実行されていました）。それでも、私は疑問に思っていました...
結論として、この手法は現在でもどのシナリオでも関連していますか？