在遊戲中應用A*算法主要是以下步驟：
1．將地圖劃分包含多個等大區域的網絡：傳統做法是將地圖劃分爲多個等大的正方形小格子，或者也有將地圖劃分爲由菱形小格子組成；另外如果將地圖劃分爲多個凸多邊形情況下，便是NAV導航網格尋路的思路了。
每個小格子就是一個導航路點(waypoint)，這種尋路算法就是常說的路點尋路算法。
疑問：地圖有多大，小格子多大一個，就會對尋路的效率（對空間、時間消耗均有影響)，以及人物行走的視覺效果有直接影響。
2．生成相應的地圖數據：主要用於標記各路點可否通過，及其他相應的一些地圖信息。
疑問： 通常不同的地形通過的代價應該是不同的，比如通過1米寬的沼澤的代碼要大於通過3米長的道路，這時候較短路徑應該是起道路而不是沼澤。所在在尋路算法中的最短路徑一般是指最小代價路徑。對於路點尋路算法來說可對waypoint加上權值來描述。
3．將地圖數據、起點、終點交給A*算法，即可得到一條由多個waypoint組成的路徑
針對A*算法本身，也有很多值得優化的地方；
A*算法本質是一個啓發式搜索算法(BFS等算法其實是A*的一個特例)，在計算過種中會主要涉及這麼兩個重點：
Ø 計算過程中的臨時空間：包括一個待搜索點表(open表)和一個已搜索點表(close表)；
Ø 路徑長度的估價等式：f(n) = g(n) + h(n)
其中f(n)是節點n的估價函數，g(n)是在狀態空間中從起點到n節點的實際代價，h(n)是從n到終點的最佳路徑的估計代價。需要特別關注h(n)，因爲g(n)一般是已知的。
？？？在該算法中，對空間是有一定消耗的，尤其在找不到一條通達的路徑時，open表是可能比較龐大的。針對open表是需要做一些添加、刪除、排序的操作。比較常見的做法是使用二叉堆來存儲這個結構（這會增加“添加或者刪除”操作的時間及一些存儲空間，但會大大減少排序時間），地圖路點越多時性能提升越明顯，這需要根據應用場景做不同的取捨。經過實際的HTML5動畫的javanoxss實現，性能提升是非常明顯的。
？？？對於路徑長度估價等式中估價函數即h(n)，一般的估值計算方式包括：對角線距離、歐幾里得距離、曼哈頓距離等等。這個計算會在算法中經常用到，需要較爲高效，計算簡單使用最精簡有效的公式。目前的實現中一般使用曼哈頓距離方式。
4．在得到由多個waypoint組成的路徑後，再按照遊戲的動畫方式讓精靈沿此路徑行走即可。對於這種算法，精靈可能走出Z字形或者鋸齒形的路線，如果遊戲有需求需要更平滑，還可以做一些額外的處理使其更平滑。
？？？目前一般弗洛伊德路徑平滑算法進行後期處理。
以上便是在遊戲中應用A*路點尋路的一些過程和思考。
其他一些算法的優化：性能上可以對地圖數據做一些提前處理和運算，記錄下結果，空間換時間；另外對於不同語言實現的算法本身細節做一些優化；針對效果：鼠標點擊到障礙點無路可走的處理等等。在具體的遊戲場景中，也有一些細節優化即可得到大效果的處理方式，或者一些變種的尋路算法。另外還有結合尋路算法的一些相關處理，如動態的運動障礙物等。
