a星演算法優化
『壹』 游戲中為什麼用啟發式a星演算法
首先，A* 是啟發式演算法，在尋路過程中搜索的范圍相比 Dijsktra 一般要小得多（當然，有時也可能一樣）
其次，A* 演算法的搜索速度和效率可控，可以通過控制代價函數來權衡搜索的速度和精度之間的關系
『貳』 計算機求百錢買百雞問題採用的演算法是
演算法如下：
int main()
{
int x, y, z;
for (int k = 1; k <= 3; k++)
{
x = 4 * k;
y = 25 - 7 * k;
z = 75 + 3 * k;
printf("公雞:%d只，母雞:%d只,小雞:%d只 ", x, y, z);
(2)a星演算法優化擴展閱讀：
A*搜尋演算法
俗稱A星演算法。這是一種在圖形平面上，有多個節點的路徑，求出最低通過成本的演算法。常用於游戲中的NPC的移動計算，或線上游戲的BOT的移動計算上。該演算法像Dijkstra演算法一樣，可以找到一條最短路徑；也像BFS一樣，進行啟發式的搜索。
Beam Search
束搜索(beam search)方法是解決優化問題的一種啟發式方法，它是在分枝定界方法基礎上發展起來的，它使用啟發式方法估計k個最好的路徑，僅從這k個路徑出發向下搜索，即每一層只有滿意的結點會被保留，其它的結點則被永久拋棄，從而比分枝定界法能大大節省運行時間。
束搜索於20 世紀70年代中期首先被應用於人工智慧領域,1976 年Lowerre在其稱為HARPY的語音識別系統中第一次使用了束搜索方法。他的目標是並行地搜索幾個潛在的最優決策路徑以減少回溯，並快速地獲得一個解。
二分取中查找演算法
一種在有序數組中查找某一特定元素的搜索演算法。搜索過程從數組的中間元素開始，如果中間元素正好是要查找的元素，則搜索過程結束；
如果某一特定元素大於或者小於中間元素，則在數組大於或小於中間元素的那一半中查找，而且跟開始一樣從中間元素開始比較。這種搜索演算法每一次比較都使搜索范圍縮小一半。
『叄』 深度優先搜索和廣度優先搜索、A星演算法三種演算法的區別和聯系
在說它之前先提提狀態空間搜索。狀態空間搜索，如果按專業點的說法就是將問題求解過程表現為從初始狀態到目標狀態尋找這個路徑的過程。通俗點說，就是 在解一個問題時，找到一條解題的過程可以從求解的開始到問題的結果（好象並不通俗哦）。由於求解問題的過程中分枝有很多，主要是求解過程中求解條件的不確 定性，不完備性造成的，使得求解的路徑很多這就構成了一個圖，我們說這個圖就是狀態空間。問題的求解實際上就是在這個圖中找到一條路徑可以從開始到結果。 這個尋找的過程就是狀態空間搜索。 常用的狀態空間搜索有深度優先和廣度優先。廣度優先是從初始狀態一層一層向下找，直到找到目標為止。深度優先是按照一定的順序前查找完一個分支，再查找另一個分支，以至找到目標為止。這兩種演算法在數據結構書中都有描述，可以參看這些書得到更詳細的解釋。 前面說的廣度和深度優先搜索有一個很大的缺陷就是他們都是在一個給定的狀態空間中窮舉。這在狀態空間不大的情況下是很合適的演算法，可是當狀態空間十分大，且不預測的情況下就不可取了。他的效率實在太低，甚至不可完成。在這里就要用到啟發式搜索了。 啟發中的估價是用估價函數表示的，如： f(n) = g(n) + h(n) 其中f(n) 是節點n的估價函數，g(n)實在狀態空間中從初始節點到n節點的實際代價，h(n)是從n到目標節點最佳路徑的估計代價。在這里主要是h(n)體現了搜 索的啟發信息，因為g(n)是已知的。如果說詳細點，g(n)代表了搜索的廣度的優先趨勢。但是當h(n) >> g(n)時，可以省略g(n)，而提高效率。這些就深了，不懂也不影響啦！我們繼續看看何謂A*演算法。 2、初識A*演算法 啟發式搜索其實有很多的演算法，比如：局部擇優搜索法、最好優先搜索法等等。當然A*也是。這些演算法都使用了啟發函數，但在具體的選取最佳搜索節點時的 策略不同。象局部擇優搜索法，就是在搜索的過程中選取「最佳節點」後舍棄其他的兄弟節點，父親節點，而一直得搜索下去。這種搜索的結果很明顯，由於舍棄了 其他的節點，可能也把最好的節點都舍棄了，因為求解的最佳節點只是在該階段的最佳並不一定是全局的最佳。最好優先就聰明多了，他在搜索時，便沒有舍棄節點 （除非該節點是死節點），在每一步的估價中都把當前的節點和以前的節點的估價值比較得到一個「最佳的節點」。這樣可以有效的防止「最佳節點」的丟失。那麼 A*演算法又是一種什麼樣的演算法呢？其實A*演算法也是一種最好優先的演算法。只不過要加上一些約束條件罷了。由於在一些問題求解時，我們希望能夠求解出狀態空 間搜索的最短路徑，也就是用最快的方法求解問題，A*就是干這種事情的！我們先下個定義，如果一個估價函數可以找出最短的路徑，我們稱之為可採納性。A* 演算法是一個可採納的最好優先演算法。A*演算法的估價函數可表示為： f'(n) = g'(n) + h'(n) 這里，f'(n)是估價函數，g'(n)是起點到終點的最短路徑值，h'(n)是n到目標的最斷路經的啟發值。由於這個f'(n)其實是無法預先知道 的，所以我們用前面的估價函數f(n)做近似。g(n)代替g'(n)，但 g(n)>=g'(n)才可（大多數情況下都是滿足的，可以不用考慮），h(n)代替h'(n)，但h(n)<=h'(n)才可（這一點特別 的重要）。可以證明應用這樣的估價函數是可以找到最短路徑的，也就是可採納的。我們說應用這種估價函數的最好優先演算法就是A*演算法。哈。你懂了嗎？肯定沒 懂。接著看。 舉一個例子，其實廣度優先演算法就是A*演算法的特例。其中g(n)是節點所在的層數，h(n)=0，這種h(n)肯定小於h'(n)，所以由前述可知廣度優先演算法是一種可採納的。實際也是。當然它是一種最臭的A*演算法。 再說一個問題，就是有關h(n)啟發函數的信息性。h(n)的信息性通俗點說其實就是在估計一個節點的值時的約束條件，如果信息越多或約束條件越多則排除 的節點就越多，估價函數越好或說這個演算法越好。這就是為什麼廣度優先演算法的那麼臭的原因了，誰叫它的h(n)=0，一點啟發信息都沒有。但在游戲開發中由 於實時性的問題，h(n)的信息越多，它的計算量就越大，耗費的時間就越多。就應該適當的減小h(n)的信息，即減小約束條件。但演算法的准確性就差了，這 里就有一個平衡的問題。可難了，這就看你的了！ 好了我的話也說得差不多了，我想你肯定是一頭的霧水了，其實這是寫給懂A*演算法的同志看的。哈哈。你還是找一本人工智慧的書仔細看看吧！我這幾百字是不足以將A*演算法講清楚的。只是起到拋磚引玉的作用希望大家熱情參與嗎。
『肆』 lua語言a星尋路演算法路徑怎麼平滑
在項目中遇到了自動尋路的需求，於是決定開始學習一下A星，對於A星我也沒有深究，只能說是勉強搞定了需求，在這和大家分享一下，相互進步，
A星有個公式 f(x) = g(x) + h(x)
,搞清楚這個公式就好辦了，f(x)就是當前位置到下一個位置的總價值，g(x)表示實際價，這是說這一部分代價是確定的，h(x)表示估價值，就是說我
從下一個位置到到終點的代價是未知的，所以叫估價值，如圖中所示，黑色格子表示當前位置，綠色格子表示下一步可能到達的位置，即上、下、左、右這幾個方
向，紅色格子表示終點，褐色表示障礙物，現在要從黑色格子到達紅色格子，那麼黑色格子的下一步肯定是綠色格子當中的一個，黑色格子到綠色格子之間是相挨著
的，所以我們可以很明確的知道它的實際代價為1（移動一步的代價）即g(x)，綠色格子到紅色格子之間隔著很長的距離，中間還有障礙物，所以這個代價是未
知的，即h(x)，所以總的代價就為f(x) = g(x) +
h(x)，我們看到周圍有4個綠色的格子，到底走那一步比較好呢，所以我們要把這4個格子的f(x)值都求出來，然後進行排序，選擇f(x)值最小的，即
總代價最少的那個格子，以此方法繼續下去，直到到達終點 或者 地圖上沒有綠色格子了
下面來看一下這個工具類，g(x)和h(x)要選的比較合適，一般就是採用的曼哈頓演算法，即兩點在x方向和y方向的距離之和，
-- Filename: PathUtil.lua
-- Author: bzx
-- Date: 2014-07-01
-- Purpose: 尋路
mole("PathUtil", package.seeall)
local _map_data -- 地圖數據
local _open_list -- 開放節點
local _open_map -- 開放節點，為了提高性能而加
local _close_map -- 關閉節點
local _deleget -- 代理
local _dest_point -- 目標點
local _start_point -- 起點
local _path -- 路徑
-- 尋找路徑
--[[
deleget = {
g = function(point1, point2)
-- add your code
-- 返回點point1到點point2的實際代價
end
h = function(point1, point2)
-- add your code
-- 返回點point1到點point2的估算代價
end
getValue = function(j, i)
-- 返回地圖中第i行，第j列的數據 1為障礙物，0為非障礙物
end
width -- 地圖寬度
height -- 地圖高度
}
--]]
function findPath(deleget, start_point, dest_point)
_deleget = deleget
_dest_point = dest_point
_start_point = start_point
init()
while not table.isEmpty(_open_list) do
local cur_point = _open_list[1]
table.remove(_open_list, 1)
_open_map[cur_point.key] = nil
if isEqual(cur_point, dest_point) then
return makePath(cur_point)
else
_close_map[cur_point.key] = cur_point
local next_points = getNextPoints(cur_point)
for i = 1, #next_points do
local next_point = next_points[i]
if _open_map[next_point.key] == nil and _close_map[next_point.key] == nil and isObstacle(next_point) == false then
_open_map[next_point.key] = next_point
table.insert(_open_list, next_point)
end
end
table.sort(_open_list, compareF)
end
end
return nil
end
function init()
_open_list = {}
_open_map = {}
_close_map = {}
_path = {}
_map_data = {}
for i = 1, _deleget.height do
_map_data[i] = {}
for j = 1, _deleget.width do
local value = _deleget.getValue(j, i)
_map_data[i][j] = value
end
end
_open_map[getKey(_start_point)] = _start_point
table.insert(_open_list, _start_point)
end
function createPoint(x, y)
local point = {
["x"] = x,
["y"] = y,
["last"] = nil,
["g_value"] = 0,
["h_value"] = 0,
["f_value"] = 0
}
point["key"] = getKey(point)
return point
end
-- 得到下一個可以移動的點
-- @param point 當前所在點
function getNextPoints(point)
local next_points = {}
for i = 1, #_deleget.directions do
local offset = _deleget.directions[i]
local next_point = createPoint(point.x + offset[1], point.y + offset[2])
next_point["last"] = point
if next_point.x >= 1 and next_point.x <= _deleget.width and next_point.y >= 1 and next_point.y <= _deleget.height then
next_point["g_value"] = _deleget.g(point, next_point)
next_point["h_value"] = _deleget.h(point, _dest_point)--math.abs(next_points.x - _dest_point.x) + math.abs(next_points.y - _dest_point.y)
next_point["f_value"] = next_point.g_value + next_point.h_value
table.insert(next_points, next_point)
end
end
return next_points
end
-- 得到路徑
-- @param end_point 目標點
function makePath(end_point)
_path = {}
local point = end_point
while point.last ~= nil do
table.insert(_path, createPoint(point.x, point.y))
point = point.last
end
local start_point = point
table.insert(_path, start_point)
return _path
end
-- 兩個點的代價比較器
function compareF(point1, point2)
return point1.f_value < point2.f_value
end
-- 是否是障礙物
function isObstacle(point)
local value = _map_data[point.y][point.x]
if value == 1 then
return true
end
return false
end
-- 兩個點是否是同一個點
function isEqual(point1, point2)
return point1.key == point2.key
end
-- 根據點得到點的key
function getKey(point)
local key = string.format("%d,%d", point.x, point.y)
return key
end
下面是工具類PathUtil的用法
local deleget = {}
deleget.g = function(point1, point2)
return math.abs(point1.x - point2.x) + math.abs(point1.y - point2.y)
end
deleget.h = deleget.g
deleget.getValue = function(j, i)
local index = FindTreasureUtil.getIndex(j, i)
local map_info = _map_info.map[index]
if map_info.display == 0 and map_info.eid ~= 1 then
return 0
end
return 1
end
deleget.directions = {{-1, 0}, {0, -1}, {0, 1}, {1, 0}} -- 左，上，下，右
deleget.width = _cols
deleget.height = _rows
local dest_row, dest_col = FindTreasureUtil.getMapPosition(tag)
local dest_point = PathUtil.createPoint(dest_col, dest_row)
local start_row, start_col = FindTreasureUtil.getMapPosition(_player_index)
local start_point = PathUtil.createPoint(start_col, start_row)
_path = PathUtil.findPath(deleget, start_point, dest_point)
_path就是我們找到的路徑，起點為最後一個元素，終點為第一個元素
『伍』 如何利用矩陣對a*演算法進行優化
如果A確實能完全存入一級緩存,那麼把B按列分塊,一塊一塊乘就行了.
一般來講矩陣乘法並不是像你說的那樣做的,而要把A,B,C都分塊,對於每一級存貯器而言,應該至少分成5個部分來管理.比如說,A的某一塊常駐於這一級存貯,然後餘下的部分分為四塊：
(1)上一步已經運算完成的C塊——寫入低一級存貯
(2)下一步將參與運算的B塊——從低一級存貯讀入
(3),正在參與運算的B和C塊
(4)然後對於這一級存貯器上的小矩陣塊運算C=AB仍然按照同樣的管理方式遞交給上一級存貯來計算.一般來講A塊選得略小一點,具體的分配方式取決於運算和I/O的速度,盡量保持計算單元忙碌.
『陸』 cocos2dx 什麼是a星演算法
您好，我來為您解答：
A*搜尋演算法俗稱A星演算法。這是一種在圖形平面上，有多個節點的路徑，求出最低通過成本的演算法。常用於游戲中的NPC的移動計算，或線上游戲的BOT的移動計算上。
如果我的回答沒能幫助您，請繼續追問。
『柒』 游戲中的A星演算法怎麼寫
首先A星演算法佔內存和CPU簡直要命，之前用AS3寫的代碼90*90格僅6個敵人每次同時尋路都得卡上幾秒，還經常找不到路，反正我目前還沒想到好的優化方法。
『捌』 A星尋路演算法和Unity自帶的尋路相比有什麼優勢
在理解Navigation的時候，首先要明確兩個知識點：
AStar：AStar是路點尋路演算法中的一種，同時AStar不屬於貪婪演算法，貪婪演算法適合動態規劃，尋找局部最優解，不保證最優解。AStar是靜態網格中求解最短路最有效的方法。也是耗時的演算法，不宜尋路頻繁的場合。一般來說適合需求精確的場合。
性能和內存佔用率都還行，和啟發式的搜索一樣，能夠根據改變網格密度、網格耗散來進行調整精確度。
A Star一般使用場景：
策略游戲的策略搜索
方塊格子游戲中的格子尋路
Navigation：網格尋路演算法，嚴格意義上它屬於」拐角點演算法」，效率是比較高的，但是不保證最優解演算法。Navigation相對來說消耗內存更大，性能的話還不錯。
Navigation一般使用場景：
游戲場景的怪物尋路
動態規避障礙
它們二者事件的實現方式和原理都不同。
AStar的話，
『玖』 演算法過程是什麼
『拾』 A*搜尋演算法的演算法描述
f(x) = g(x) + h(x)
function A*(start,goal)
var closed := the empty set
var q := make_queue(path(start))
while q is not empty
var p := remove_first(q)
var x := the last node of p
if x in closed
continue
if x = goal
return p
add x to closed
foreach y in successors(x)
enqueue(q, p, y)
return failure A*改變它自己行為的能力基於啟發式代價函數，啟發式函數在游戲中非常有用。在速度和精確度之間取得折衷將會讓你的游戲運行得更快。在很多游戲中，你並不真正需要得到最好的路徑，僅需要近似的就足夠了。而你需要什麼則取決於游戲中發生著什麼，或者運行游戲的機器有多快。假設你的游戲有兩種地形，平原和山地，在平原中的移動代價是1而在山地的是3，那麼A星演算法就會認為在平地上可以進行三倍於山地的距離進行等價搜尋。 這是因為有可能有一條沿著平原到山地的路徑。把兩個鄰接點之間的評估距離設為1.5可以加速A*的搜索過程。然後A*會將3和1.5比較，這並不比把3和1比較差。然而，在山地上行動有時可能會優於繞過山腳下進行行動。所以花費更多時間尋找一個繞過山的演算法並不經常是可靠的。 同樣的，想要達成這樣的目標，你可以通過減少在山腳下的搜索行為來打到提高A星演算法的運行速率。弱項如此可以將A星演算法的山地行動耗費從3調整為2即可。這兩種方法都會給出可靠地行動策略 。