前言：为什么要使用A*寻路算法，不直接使用unity自带的Navigation组件呢？
-
灵活性高：
- A*算法允许开发者根据具体游戏需求调整和优化算法实现，比如通过改变启发式函数来适应不同的地图和寻路条件。
- Unity的Navigation组件虽然强大，但在一些特殊场景或需要高度定制的路径计算中可能不够灵活。
-
效率高：
- A*算法结合了Dijkstra算法的最短路径搜索和贪心算法的启发式搜索，能有效减少不必要的搜索，从而提高寻路效率。
- 尽管Unity的Navigation系统也进行了优化，但在某些复杂场景下，自定义的A*算法可能会提供更好的性能表现。
-
可拓展性强：
- A*算法易于扩展和维护，开发者可以根据项目的实际需要添加新的功能或者进行调试。
- Unity的Navigation系统虽然提供了可视化工具和诸多功能，但在进行特定扩展时可能需要更多的工作。
-
支持二维与三维环境：
- Unity的Navigation组件主要针对3D环境设计，对于2D游戏的路径寻找支持不如A*算法直接和高效。
-
适应多种场景的需求：
在不同的游戏开发项目中，地图和场景的设计差异较大，A*算法因其灵活性和适应性被广泛采用
Navigation组件的局限性：
-
烘焙时间和资源消耗：对于大型或复杂场景，Navigation组件的烘焙过程可能会非常耗时且消耗大量资源。
-
动态环境的处理：尽管新版Unity Navigation系统支持动态烘焙，但在处理频繁变化的场景时仍可能面临性能挑战。
-
易用性与控制权衡：Navigation组件虽然简化了寻路设置，但同时也牺牲了某些高级功能和自定义选项，这在需要精确控制的游戏设计中可能是一个缺点
A*寻路的算法估价
在A算法中核心的寻路依据就是估量代价，在A*寻路算法中通常用F表示。
F=G+H
其中G表示当前点到起始点的估量代价，表示当前点到终点的代价。
G的计算方式：最开始，以起点为中心开始计算周边的八个格子，然后在以这算出来的八个
格子为中心，继续计算他们周边的八个格子的G值，在计算的时候区域有所覆盖，如果计算出来的值小于格子目前的G值，该格子的G值就要更新为较小的G值。以此类推，直到找到终点，遍历完所有的格子。G值的计算结果为：中心点的G值+距离值【10or14】
设定每个格子之间的距离为10，那么从中心的格子到对角线之间的距离就是两个格子中心之间的连线，也就是14，G值为左下角的数值，H值为右下角的数值，F值为左上角数值，默认起点的G值为0
H的计算方式：H值是从当前点到终点的预估代价。这个值的计算通常基于某种启发式方法，以估算剩余距离。一个简单的启发式方法是使用欧几里得距离，即在二维空间中，两点间的直线距离可以通过勾股定理来计算。
A*寻路算法的具体步骤及代码
每次计算G和H的时候建立下面这样的表格，找到F值最小的格子，然后再通过该格子找到周围的8个格子再次建立，这样的表格，找到F值最小的格子，以此递归，直到找到终点为止，每次当过中心点的格子会被记录起来来防止下次再次经过这个格子。A*寻路算法的本质就是通过终点回溯来找到最短路径。
| 序号 | G | H | F |
| 1 | 10 | 10 | 20 |
| 2 | 10 | 14 | 24 |
| 3 | 10 | 10 | 20 |
标签：格子,OpenList,寻路,算法,Unity,计算,Navigation From： https://blog.csdn.net/weixin_74960198/article/details/139198436步骤
- 设置开放列表OpenList和关闭列表CloseList；
- 将起点放到OpenList；
- 开启循环While(OpenList.count > 0)
3.1 将OpenList按照F值从小到大排序
3.2 OpenList[0]的值必是最小的，命名为center
3.2.1发现Centeri就是终点，回溯找到导航路径
3.3 以这个点为中心去计算周边的8个格子的三个值
3.4 如果这个格子没有被计算过或者原来的G值比这次计算的还要大
3.4.1 此时设置新的FGH值给该格子，并设置该格子的发现者为center
3.5 如果这个格子被计算过，且原G值比这次计算的要小
3.5.1 此时就不能替换原来的FGH值
3.6 将发现的每个格子放入OpenList
3.6.1 放入的时候要检测【该格子不在OpenList，该格子不在CloseList】
3.7 将此次的发现者Center放入CloseList中
3.8 判断OpenList为空
3.8.1 说明所有的可发现的格子都被遍历过了，始终没有找到中，说明无法到达终点