路径排序Path Scoring

The key to determining which squares to use when figuring out the path is the following equation:
找到形成路径的方块的关键是下面的等式：

F = G + H

where
这里

• G = the movement cost to move from the starting point A to a given square on the grid, following the path generated to get there.
• G = 从开始 点A到格子中给定方块的移动代价，沿着到达该方块而生成的那个路径。
• H = the estimated movement cost to move from that given square on the grid to the final destination, point B. This is often referred to as the heuristic, which can be a bit confusing. The reason why it is called that is because it is a guess. We really don't know the actual distance until we find the path, because all kinds of stuff can be in the way (walls, water, etc.). You are given one way to calculate H in this tutorial, but there are many others that you can find in other articles on the web.
• H = 从格子中给定 的方块到最终目标 B点的评估移动代价。这种方式通常称作试探法，有点让人混乱。因为这是一个猜测，所以得到这个称谓。在找到路径之前，我们真的不知道实际的距离，因为途中有各种东西（墙，水，等等）。在本教程里给出了一种计算H的方法，但在网上你能找到很多其他的文章。

Our path is generated by repeatedly going through our open list and choosing the square with the lowest F score. This process will be described in more detail a bit further in the article. First let's look more closely at how we calculate the equation.
我们需要的路径是这样生成的：反复的遍历开放列表，选择具有最小F值的方块。这个过程在本文稍后会详细描述。先让我们看看如何计算前面提到的等式。

As described above, G is the movement cost to move from the starting point to the given square using the path generated to get there. In this example, we will assign a cost of 10 to each horizontal or vertical square moved, and a cost of 14 for a diagonal move. We use these numbers because the actual distance to move diagonally is the square root of 2 (don't be scared), or roughly 1.414 times the cost of moving horizontally or vertically. We use 10 and 14 for simplicity's sake. The ratio is about right, and we avoid having to calculate square roots and we avoid decimals. This isn't just because we are dumb and don't like math. Using whole numbers like these is a lot faster for the computer, too. As you will soon find out, pathfinding can be very slow if you don't use short cuts like these.
如上所述，G是经由到达它的路径，从开始点到给定方块的移动代价。在本例中，我们为每个水平/垂直的移动指定代价为10，而斜角的移动代价为14。我们使用这些值，因为斜角移动的实际距离是2的平方根（别害怕），或者大概1.414倍的水平/垂直的移动代价。出于简化的目的使用了10和14。比例大致是正确的，而我们却避免了方根和小数的计算。倒不是我们没有能力做或者不喜欢数学。使用这些数字也能让计算更快一些。以后你就会发现，如果不使用这些技巧，寻路的计算非常慢。

Since we are calculating the G cost along a specific path to a given square, the way to figure out the G cost of that square is to take the G cost of its parent, and then add 10 or 14 depending on whether it is diagonal or orthogonal (non-diagonal) from that parent square. The need for this method will become apparent a little further on in this example, as we get more than one square away from the starting square.
既然我们沿着到达给定方块的路径来计算G的值，找出那个方块的G值的方法就是找到其父亲的G值，再加上10或者14而得，这依赖于他处于其父亲的斜角或者直角（非斜角）而定。这在本例后面会更加清晰，随着我们从开始点离开而得到更多的方块。

H can be estimated in a variety of ways. The method we use here is called the Manhattan method, where you calculate the total number of squares moved horizontally and vertically to reach the target square from the current square, ignoring diagonal movement. We then multiply the total by 10. This is called the Manhattan method because it's like calculating the number of city blocks from one place to another, where you can't cut across the block diagonally. Importantly, when calculating H, we ignore any intervening obstacles. This is an estimate of the remaining distance, not the actual distance, which is why it's called the heuristic. Want to know more? You can find equations and additional notes on heuristics here.
H能通过多种方法估算。我们这里用到的方法叫做Manhattan方法，计算从当前方块经过水平/垂直移动而到达目标方块的方块总数。然后将总数乘以 10。这种方法之所以叫做Manhattan方法，因为他很象计算从一个地点到达另一个地点的城市街区数量计算，此时你不能斜向的穿越街区。重要的是，当计算H的时候，要忽略任何路径中的障碍。这是一个对剩余距离的 估算值，而不是实际值，这就是试探法的称谓由来。想知道更多？关于试探法的更多说明在这里。

F is calculated by adding G and H. The results of the first step in our search can be seen in the illustration below. The F, G, and H scores are written in each square. As is indicated in the square to the immediate right of the starting square, F is printed in the top left, G is printed in the bottom left, and H is printed in the bottom right.
G和H相加就算出了F。第一步搜索的结果见下图的描述。F，G，和H值都写入了每个方块。如开始方块相邻右边的方块，F显示在左上方，G显示在左下方，而 H显示在右下方。

[图 3][Figure 3]

So let's look at some of these squares. In the square with the letters in it, G = 10. This is because it is just one square from the starting square in a horizontal direction. The squares immediately above, below, and to the left of the starting square all have the same G score of 10. The diagonal squares have G scores of 14.
好，让我们来观察某些方块。在有字母的方块中，G = 10。这是由于在水平方向上从开始点（到那里）只有一个方块（的距离）。开始点相邻上方，下方和左边的方块都具有同样的G值：10。斜角的方块G值为 14。

The H scores are calculated by estimating the Manhattan distance to the red target square, moving only horizontally and vertically and ignoring the wall that is in the way. Using this method, the square to the immediate right of the start is 3 squares from the red square, for a H score of 30. The square just above this square is 4 squares away (remember, only move horizontally and vertically) for an H score of 40. You can probably see how the H scores are calculated for the other squares.
H的计算通过估算Manhattan距离而得，即：水平/垂直移动，忽略途中的障碍，到达红色的目标方块的距离。用这种方法，开始点相邻右边的方块和红色方块相距3个方块，那么H值就是30。其上的方块距离为4（记住，只能水平或者垂直移动），H就是40。你也许可以看看其他方块的H值是如何算出的。

The F score for each square, again, is simply calculated by adding G and H together.
每个方块的F值，再说一下，不过就是G和H相加。

持续的搜索Continuing the Search

To continue the search, we simply choose the lowest F score square from all those that are on the open list. We then do the following with the selected square:
为了继续搜索，我们简单的选择开放列表里具有最小F值的方块。然后对选定的方块做如下操作：

4. Drop it from the open list and add it to the closed list.
5. 将他从开放列表取出，并加入封闭列表。
6. Check all of the adjacent squares. Ignoring those that are on the closed list or unwalkable (terrain with walls, water, or other illegal terrain), add squares to the open list if they are not on the open list already. Make the selected square the "parent" of the new squares.
7. 测试所有的相邻方块。忽略封闭列表内的和不可行走的（墙，水及其它非法地形）方块，如果方块不在开放列表中，则添加进去。将选定方块作为这些新加入方块的父亲。
8. If an adjacent square is already on the open list, check to see if this path to that square is a better one. In other words, check to see if the G score for that square is lower if we use the current square to get there. If not, don't do anything.
   On the other hand, if the G cost of the new path is lower, change the parent of the adjacent square to the selected square (in the diagram above, change the direction of the pointer to point at the selected square). Finally, recalculate both the F and G scores of that square. If this seems confusing, you will see it illustrated below.
9. 如果一个相邻方块已经存在于开放列表，检查到达那个方块的路径是否更优。换句话说，检查经由当前方块到达那里是否具有更小的G 值。如果没有，不做任何事。
   相反，如果新路径的G值更小，把这个相邻方块的父亲改为当前选定的方块（在上图中，修改其指针方向指向选定方块）。最后，重新计算那个方块的F和G值。如果这样还是很迷惑的话，后面还会有图解说明。

Okay, so let's see how this works. Of our initial 9 squares, we have 8 left on the open list after the starting square was switched to the closed list. Of these, the one with the lowest F cost is the one to the immediate right of the starting square, with an F score of 40. So we select this square as our next square. It is highlight in blue in the following illustration.
好了，让我们看看它是怎样工作的。在初始的9个方块中，当开始方块被纳入封闭列表后，我们的开放列表就只有8个方块了。在这些块中，具有最小F值的是开始方块相邻右边的那个，其F值为40。所以我们选定这个块作为下一个方块。在随后的图例中，它以高亮的蓝色表示。

[图 4][Figure 4]

First, we drop it from our open list and add it to our closed list (that's why it's now highlighted in blue). Then we check the adjacent squares. Well, the ones to the immediate right of this square are wall squares, so we ignore those. The one to the immediate left is the starting square. That's on the closed list, so we ignore that, too.
首先，我们把它从开放列表取出，并加入到封闭列表（这就是它现在是高亮的蓝色的原因）。然后我们检查相邻的方块。然而，这个方块相邻右边的是代表墙的方块，所以忽略它们。其相邻左边是开始方块。它处于封闭列表内，所以也忽略它

The other four squares are already on the open list, so we need to check if the paths to those squares are any better using this square to get there, using G scores as our point of reference. Let's look at the square right above our selected square. Its current G score is 14. If we instead went through the current square to get there, the G score would be equal to 20 (10, which is the G score to get to the current square, plus 10 more to go vertically to the one just above it). A G score of 20 is higher than 14, so this is not a better path. That should make sense if you look at the diagram. It's more direct to get to that square from the starting square by simply moving one square diagonally to get there, rather than moving horizontally one square, and then vertically one square.
其它4个已经在开放列表中了，所以我们需要检查经由当前方块到达他们是否是更优的路径，使用G值为参考点。我们来看看这个选定方块上面右边的那个方块。它的当前G值是14。如果我们经由当前方块到达那里，G值将是20（10，到达当前方块的G值，再加上10垂直移动到它上面的方块）。20 > 14，所以这不是一个好的路径。看看图解能更好的理解这些。从开始方块斜向移动到那个方块更直接，而不是水平移动一个方块，再垂直移动一个方块。

When we repeat this process for all 4 of the adjacent squares already on the open list, we find that none of the paths are improved by going through the current square, so we don't change anything. So now that we looked at all of the adjacent squares, we are done with this square, and ready to move to the next square.
当我们对已经存在于开放列表的所有4个相邻方块都重复这个过程，我们发现经由当前方块没有更佳的路径，所以什么也不用改变。现在看看所有的相邻方块，我们已经处理完毕，并准备移动到下一个方块。

So we go through the list of squares on our open list, which is now down to 7 squares, and we pick the one with the lowest F cost. Interestingly, in this case, there are two squares with a score of 54. So which do we choose? It doesn't really matter. For the purposes of speed, it can be faster to choose the last one you added to the open list. This biases the search in favor of squares that get found later on in the search, when you have gotten closer to the target. But it doesn't really matter. (Differing treatment of ties is why two versions of A* may find different paths of equal length.)
现在，我们再遍历开放列表，它只有7个方块了，选择具有最小F值的那个。有趣的是，此时有两个方块都有值54。那么我们选择哪个？实际上这不算什么。为了速度的目的，选择你最后加入到开放列表的那个方块更快。当你更接近目标的时候，它倾向于后发现的方块。但这真的没什么关系。（不同的处理造成了两个版本的A*可能找到不同的等长路径。）

So let's choose the one just below, and to the right of the starting square, as is shown in the following illustration.
我们选择下面的那个，位于开始方块的右边，如下图所示。

[图 5][Figure 5]

This time, when we check the adjacent squares we find that the one to the immediate right is a wall square, so we ignore that. The same goes for the one just above that. We also ignore the square just below the wall. Why? Because you can't get to that square directly from the current square without cutting across the corner of the nearby wall. You really need to go down first and then move over to that square, moving around the corner in the process. (Note: This rule on cutting corners is optional. Its use depends on how your nodes are placed.)
这一次，当检查相邻的方块时，我们相邻右边的是一个墙方块，所以忽略它。对那个方块上面的块同样忽略。我们也忽略墙下面的方块。为什么？因为你不把临近墙的角切开就无法直接到达那个方块。实际上你需要先向下走，然后越过那个方块，在这个过程中都是围绕角在移动。（说明：切开角的规则是可选的。它的使用依赖于你的节点如何放置。）

That leaves five other squares. The other two squares below the current square aren't already on the open list, so we add them and the current square becomes their parent. Of the other three squares, two are already on the closed list (the starting square, and the one just above the current square, both highlighted in blue in the diagram), so we ignore them. And the last square, to the immediate left of the current square, is checked to see if the G score is any lower if you go through the current square to get there. No dice. So we're done and ready to check the next square on our open list.
这样就剩下5个方块了。当前方块下的两个方块不在开放列表中，所以要添加他们，并把当前方块作为它们的父亲。在另外三个方块中，有两个已经在封闭列表中了（开始方块，和当前方块上面的那个，它们都用高亮的蓝色在图中标出来了），所以忽略它们。最后一个方块，当前方块相邻左边的那个，检查经由当前方块到达那里是否得到更小的G值。没有。所以处理完毕，并准备检查开放列表中的下一个方块。

We repeat this process until we add the target square to the open list, at which point it looks something like the illustration below.
我们重复这个过程，直到把目标点添加到开放列表，此时的情形如下图所示。

[图 6][Figure 6]

Note that the parent square for the square two squares below the starting square has changed from the previous illustration. Before it had a G score of 28 and pointed back to the square above it and to the right. Now it has a score of 20 and points to the square just above it. This happened somewhere along the way on our search, where the G score was checked and it turned out to be lower using a new path ? so the parent was switched and the G and F scores were recalculated. While this change doesn't seem too important in this example, there are plenty of possible situations where this constant checking will make all the difference in determining the best path to your target.
注意开始方块向下的第二个方块，在前面的描述中其父亲已经发生改变。开始它的G值为28，指向其右上角的方块。现在它的值是20，指向其上方的方块。这是在搜索方法中某处发生的吗？在那里G值被检查，而且使用新的路径后，它得到了更小的值。所以它的父亲切换了，G和F也重新计算。而这个改变在本例中不见得非常重要，还有足够多的可能位置，在决定最佳路径的时候，持续的检查会产生各种差别。

So how do we determine the actual path itself? Simple, just start at the red target square, and work backwards moving from one square to its parent, following the arrows. This will eventually take you back to the starting square, and that's your path! It should look like the following illustration. Moving from the starting square A to the destination square B is simply a matter of moving from the center of each square (the node) to the center of the next square on the path, until you reach the target. Simple!
那么我们怎样决定实际的路径呢？简单，从红色目标方块开始，向后移动到它的父亲，跟从箭头的指示。最终你会回到开始方块，这就是路径！它应该如下图所示。从方块A移动到目标方块B就是从每一个方块（节点）的中心移动到路径上的下一个方块的中心的简单过程，直到到达目标。简单！

[图 7][Figure 7]

A*方法汇总Summary of the A* Method

Okay, now that you have gone through the explanation, let's lay out the step-by-step method all in one place:
好了，现在你已经读完了解释，让我们在这里一步一步的列出所有操作：

1. Add the starting square to the open list.
2. 添加开始方块到开放列表。
   
3. Repeat the following:
   
4. 重复下面的过程：
   a) Look for the lowest F cost square on the open list. We refer to this as the current square.
   a) 查找开放列表中具有最小F值的方块。我们把它作为当前方块。
   b) Switch it to the closed list.
   b) 把它放入封闭列表。
   c) For each of the 8 squares adjacent to this current square ?
   c) 对当前方块的8个相邻方块的每一个？
   
   • If it is not walkable or if it is on the closed list, ignore it. Otherwise do the following.
   • 如果它不可行走，或者存在于封闭列表，忽略它。否则执行下面操作。
     
   • If it isn't on the open list, add it to the open list. Make the current square the parent of this square. Record the F, G, and H costs of the square.
   • 如果它不在开放列表，将它添加进去。以当前方块作为其父亲。记录这个方块的F，G和H值。
     
   • If it is on the open list already, check to see if this path to that square is better, using G cost as the measure. A lower G cost means that this is a better path. If so, change the parent of the square to the current square, and recalculate the G and F scores of the square. If you are keeping your open list sorted by F score, you may need to resort the list to account for the change.
   • 如果它已经在开放列表了，检查到达那个方块的路径是否更优，以G值为测量值。更低的G值意味着更好的路径。如果找到，这个方块的父亲改为当前方块，并重新计算这个方块的G和F值。如果你保持开放列表按F值排序的话，可能需要重新排序来解决这个变化。
     
   
   d) Stop when you
   d) 结束循环，当你
   
   • Add the target square to the open list, in which case the path has been found, or
   • 将目标方块加入到开放列表，此时路径已经找到，或者
     
   • Fail to find the target square, and the open list is empty. In this case, there is no path.
   • 没有找到目标方块，并且开放列表是空的。此时，没有路径。
     
5. Save the path. Working backwards from the target square, go from each square to its parent square until you reach the starting square. That is your path.
6. 保存路径。从目标方块往回走，从每个方块走到它的父亲方块，直到抵达开始方块。那就是路径。
   

一点感慨Small Rant

Forgive me for digressing, but it is worth pointing out that when you read various discussions of A* pathfinding on the web and in assorted forums, you will occasionally see someone refer to certain code as A* when it isn't. For the A* method to be used, you need to include the elements just discussed above -- specifically open and closed lists and path scoring using F, G, and H. There are lots of other pathfinding algorithms, but those other methods are not A*, which is generally considered to be the best of the lot. Bryan Stout discusses many of them in the article referenced at the end of this article, including some of their pros and cons. Sometimes alternatives are better under certain circumstances, but you should understand what you are getting into. Okay, enough ranting. Back to the article.
原谅我离题了，但是值得指出的是，当你在网上和分类论坛阅读很多讨论A*寻路的时候，你有时候会发现某些人所指的A*代码实际上并不是真正的A*算法。对于应用中的A*方法，你需要包含上面讨论到的元素  -- 特别是开放列表和封闭列表，以及使用F，G，和H的路径排序。有很多其他的寻路算法，但是其它的方法不是A* -- 通常认为它是最好的算法。Bryan Stout在本文后面的一个参考文档里讨论了这些算法，有正面的，也有反面的。有时候在特定的环境下，选择其他的算法会更好，但是你应该理解你做了什么。好了，说够了。回到文章中来。

关于实现的提示Notes on Implementation

Now that you understand the basic method, here are some additional things to think about when you are writing your own program. Some of the following materials reference the program I wrote in C++ and Blitz Basic, but the points are equally valid in other languages.
现在你已经理解了基本的方法，这里是当你写自己的程序时要考虑的更多东西。下面的某些材料引用了我用C++和Blitz Basic写的程序，但是这些要点对其他语言也是同样有效的。

1. Maintaining the Open List: This is actually one of the most time consuming elements of the A* pathfinding function. Every time you access the open list, you need to find the square that has the lowest F cost. There are several ways you could do this. You could save the path items as needed, and simply go through the whole list each time you need to find the lowest F cost square. This is simple, but really slow for long paths. This can be improved by maintaining a sorted list and simply grabbing the first item off the list every time you need the lowest F-cost square. When I wrote my own, this was the first method I used.
1.维护开放列表 : 实际上这是A*寻路函数最耗费时间的元素之一。每次访问开放列表时，你都需要找到具有最小F值的方块。有很多种方法可以做到这点。你可以保存所需的路径项目，每次当你需要找到最小F值的方块时，简单的遍历整个列表。这很简单，不过路径长的时候非常慢。这个方法可以改进，通过维护一个排序的列表，每次需要最小F值的方块时，简单的抓出第一个项目就可以了。当我写自己的程序时，这是我用到的第一个方法。

This will work reasonably well for small maps, but it isn't the fastest solution. Serious A* programmers who want real speed use something called a binary heap, and this is what I use in my code. In my experience, this approach will be at least 2-3 times as fast in most situations, and geometrically faster (10+ times as fast) on longer paths. If you are motivated to find out more about binary heaps, check out my article, Using Binary Heaps in A* Pathfinding.
这个方法对小的地图相当的好，但不是最快的方案。真正需要速度的认真的A*程序员使用叫做二元堆[binary heap]的东西，这也是我的代码中所使用的。以我的经验，在大多数解决方案中，这个方法会快至少2-3倍，在长路径上更快（10倍以上）。如果你有兴趣发现更多二元堆的奥秘，参考我的文章，Using Binary Heaps in A* Pathfinding。

2. Other Units: If you happen to look closely at my example code, you will notice that it completely ignores other units on the board. My pathfinding critters actually pass right through each other. Depending on the game, this might be okay or it might not. If you want to consider other units on the board and have them move around each other, I suggest ignoring other units in the path finding code itself and instead writing some new code that detects whether two units have bumped into each other. When that happens, you can generate a new path or use some standard movement rules (always move to the right, etc.) until the obstacle is no longer in the way, and then generate a new path. Why not include other units when you are calculating the initial path? Well, because other units can move, they may not be where they were by the time you get there. This can produce some weird results, where a unit swerves to avoid a unit that isn't there anymore and bumps into units that have moved across its path after the path is calculated.
2. 其他单元： 如果你碰巧深入的阅读我的范例代码，将会注意到它完全忽略了地图上的其他单元。我的寻路怪物实际上是穿越彼此而通过。依赖于游戏，这可能是正确的，或者是不正确的。如果你要考虑地图上的其他单元，并让他们能围绕彼此移动，我建议你在寻路代码里忽略其他的单元，而另外写一些代码来检测两个单元是否发生了碰撞。当碰撞发生时，你可以生成一个新路径或者使用一些标准的移动规则，直到障碍不在路上，然后生成新路径。当计算初始路径时，为什么不包含其他单元？嗯，因为其他单元会动，他们可能不在自己的位置，当你到达那里的时候。这会造成一些怪异的结果，路径计算后，在某处单元突然转向避开一个不再停留在那里的单元，却撞上了另一个经过它路径的单元。

Ignoring other units in the pathfinding code, however, means that you will need to write separate code to handle collisions. This is fairly game specific, so I'll leave its resolution to you. Bryan Stout's article in the references section at the end of this article is worth checking out for some possible solutions (like robust tracing, etc.).
寻路代码中忽略其他的单元，然而，这意味着你要写单独的代码来处理碰撞。这是和游戏很相关的，所以我把决定权留给你。本文后面的参考资料一节里， Bryan Stout的文章值得一读，里面有一些可能的解决方案（如强力跟踪[robust tracing]，等等）。

3. Some More Speed Tips: As you develop your own A* program, or adapt the one I wrote, you will eventually find that pathfinding is using a hefty chunk of your CPU time, particularly if you have a decent number of pathfinding critters on the board and a reasonably large map. If you read the stuff on the net, you will find that this is true even for the professionals who design games like Starcraft or Age of Empires. If you see things start to slow down due to pathfinding, here are some ideas that may speed things up:
3. 关于速度的更多技巧 ：当你开发自己的A*程序，或者改编我所写的那个，最终你会发现寻路使用了大块的 CPU时间，特别是当你有大量的寻路怪物，运行在一个相当大的地图上的时候。如果你读网上的资料，你会发现甚至象星际争霸[Starcraft]或者帝国时代[Age of Empires]这样的专业游戏也会遇到这些问题。如果你发现由于寻路导致运行变慢，这里有一些可能提高速度的主意：

• Consider a smaller map or fewer critters.
• 考虑小一些的地图或者少一些的怪物。
  
• Never do path finding for more than a few critters at a time. Instead put them in a queue and spread them out over several game cycles. If your game is running at, say, 40 cycles per second, no one will ever notice. But they will notice if the game seems to slow down every once in a while when a bunch of critters are all calculating paths at the same time.
• 不要一次对太多的怪物做寻路。而是把他们放入队列，从而把他们分散到更多的游戏循环。如果你的游戏运行在，比如，40帧/秒，没有人会注意到。但是他们会注意到每一小段时间的游戏变慢，当大量的怪物都在同一时间寻路的时候。
  
• Consider using larger squares for your map. This reduces the total number of squares searched to find the path. If you are ambitious, you can devise two or more pathfinding systems that are used in different situations, depending upon the length of the path. This is what the professionals do, using large areas for long paths, and then switching to finer searches using smaller squares/areas when you get close to the target. If you are interested in this concept, check out my article Two-Tiered A* Pathfinding.
• 考虑对地图使用大一些的方块。这样就减少了寻路要搜索的方块总数。如果你有雄心的话，可以设计两种或更多寻路系统，依赖于路径的长度而用于不同的场合。这就是专业人士的做法，对长路径使用大的区域，然后当接近目标时切换到使用小一些的方块/区域的精确搜索。如果你对这个概念有兴趣，参考我的文章Two-Tiered A* Pathfinding。
• Consider using a waypoint system for longer paths, or devising precalculated paths that are hardwired into the game.
• 考虑对较长的路径应用路点系统，或者设计预计算[precalculated]的多个路径，它们对游戏是固定不变 [hardwired]的。
  
• Consider pre-processing your map to figure out what areas are inaccessible from the rest of the map. I call these areas "islands." In reality, they can be islands or any other area that is otherwise walled off and inaccessible. One of the downsides of A* is that if you tell it to look for paths to such areas, it will search the whole map, stopping only when every accessible square/node has been processed through the open and closed lists. That can waste a lot of CPU time. It can be prevented by predetermining which areas are inaccessible (via a flood-fill or similar routine), recording that information in an array of some kind, and then checking it before beginning a path search. In the Blitz version of my code, I have created a map pre-processor that does this. It also pre-identifies dead-ends that the path finding algorithm can ignore, which speeds things up even further.
• 考虑预处理地图，计算出哪些区域是从其他区域不可到达的。我把这些区域叫做“岛屿”。实际上，他们也可以是岛屿或者其他围了墙而无法到达的区域。A*的缺点之一就是，如果你告诉它搜索到达这些区域的路径，它会搜索整个地图，仅当每一个开放列表和封闭列表中的可到达方块/节点都处理后，才会停止。那会浪费大量的CPU时间。这种现象是可以避免的，通过预先决定那些区域是无法到达的，用数组或者类似的数据结构记录这些信息，然后在开始路径搜索前检查它。在我的代码的Blitz版本中，我创建了一个地图预处理器[map pre-processor]来做这件事。它也预先检查寻路算法可以忽略的死点[dead-ends]，这样速度就提高了很多。
  

4. Variable Terrain Cost: In this tutorial and my accompanying program, terrain is just one of two things ? walkable or unwalkable. But what if you have terrain that is walkable, but at a higher movement cost? Swamps, hills, stairs in a dungeon, etc. ? these are all examples of terrain that is walkable, but at a higher cost than flat, open ground. Similarly, a road might have a lower movement cost than the surrounding terrain.
4. 多样的地形代价： 在本教程以及我的附带程序里，地形只有两种情况：可行走和不可行走。如果你有可以行走但移动代价更高的地形怎么办？沼泽，山坡，地下城的楼梯，等等？这些都是可行走而移动代价高于平坦地面的地形实例。同样的，道路可能具有比它周围地形小一些的移动代价。

This problem is easily handled by adding the terrain cost in when you are calculating the G cost of any given square. Simply add a bonus cost to such squares. The A* pathfinding algorithm is already written to find the lowest cost path and should handle this easily. In the simple example I described, when terrain is only walkable or unwalkable, A* will look for the shortest, most direct path. But in a variable-cost terrain environment, the least cost path might involve traveling a longer distance ? like taking a road around a swamp rather than plowing straight through it.
这个问题很容易解决，当计算任意给定的方块的G值时，加上地形的代价。简单的加上一个奖励代价给这些方块。A*寻路算法已经写成查找最小代价的路径，应该容易处理它。在我描述得简单示例中，当地形只有可行走和不可行走时，A*能找到最短，最直接得路径。但是在多代价[variable-cost]地形环境中，最小代的得路径可能行走了较长的距离。如同选择围绕沼泽的道路，而不是直接穿越沼泽。

An interesting additional consideration is something the professionals call "influence mapping." Just as with the variable terrain costs described above, you could create an additional point system and apply it to paths for AI purposes. Imagine that you have a map with a bunch of critters defending a pass through a mountain region. Every time the computer sends somebody on a path through that pass, it gets whacked. If you wanted, you could create an influence map that penalized squares where lots of carnage is taking place. This would teach the computer to favor safer paths, and help it avoid dumb situations where it keeps sending troops and critters through a particular path, just because it is shorter (but also more dangerous).
还有一个有趣的附加考虑是被专业人士称作“影响映射[influence mapping]”的东西。如同上面描述的多代价地形一样，你可以创建一个附加的点系统，并引用到AI的路径中。想象你有一个地图，有大量的怪物守护着穿越山区的通道。每次当电脑送某人到经过这个通道的路径时，都会被困住。如果你愿意，你可以创建一个影响地图，处罚发生大量流血残杀处的那些方块。这会教电脑偏好安全的路径，并帮助它避免不利的位置：仅仅由于路径更短（但更危险），而不停的输送部队和怪物通过这个路径。

5. Handling Unexplored Areas: Have you ever played a PC game where the computer always knows exactly what path to take, even though the map hasn't been explored yet? Depending upon the game, pathfinding that is too good can be unrealistic. Fortunately, this is a problem that is can be handled fairly easily.
5. 处理未探索区域： 你是否玩过一款PC游戏，在那里电脑总是准确的知道路该如何走，即使地图没有探索？依赖与游戏，那样的寻路太好了反而不够真实。幸运的是，这个问题很容易解决。

The answer is to create a separate "knownWalkability" array for each of the various players and computer opponents (each player, not each unit -- that would require a lot more computer memory). Each array would contain information about the areas that the player has explored, with the rest of the map assumed to be walkable until proven otherwise. Using this approach, units will wander down dead ends and make similar wrong choices until they have learned their way around. Once the map is explored, however, pathfinding would work normally.
答案就是创建一个独立的“发现可行走[knowWalkability]”数组用于每一个玩家以及电脑对手（每一个玩家，不是每一个单元 -- 那将需要更多的计算机内存）。每个数组包含了玩家已探索区域的信息，另一方面，地图上其它区域直到被证实后才被假设是可行走的。使用这个方法，单元会漫步于死点位置，重复做相同的错误选择，直到他们发现周围的路。一旦地图都探索了，寻路就正常工作。

6. Smoother Paths: While A* will automatically give you the shortest, lowest cost path, it won't automatically give you the smoothest looking path. Take a look at the final path calculated in our example (in Figure 7). On that path, the very first step is below, and to the right of the starting square. Wouldn't our path be smoother if the first step was instead the square directly below the starting square?
6. 更平滑的路径： 虽然A*会自动给出最短的，最低代价的路径，它不会自动给出看起来最平滑的路径。看一看本例最后计算出来的路径（图 7）。那条路径的第一步位于开始方块的右下方。如果第一步的方块就是开始方块相邻下方的方块，路径会不会更平滑些？

There are several ways to address this problem. While you are calculating the path you could penalize squares where there is a change of direction, adding a penalty to their G scores. Alternatively, you could run through your path after it is calculated, looking for places where choosing an adjacent square would give you a path that looks better. For more on the whole issue, check out Toward More Realistic Pathfinding, a (free, but registration required) article at Gamasutra.com by Marco Pinter.
有很多方法可以解决这个问题。当你计算路径的时候，要处罚那些改变方向的方块，给它们一个附加的G值扣分。这样计算后，你可以走一遍那条路径，看一看那些选择了邻近方块而让路径看起来更好的地方。关于这个问题的完整信息，参考Gamasutra.com上Macro Pinter的文章 Toward More Realistic Pathfinding，它是免费的，但需要注册。

7. Non-square Search Areas: In our example, we used a simple 2D square layout. You don't have to use this approach. You could use irregularly shaped areas. Think of the board game Risk, and the countries in that game. You could devise a pathfinding scenario for a game like that. To do this, you would need to create a table for storing which countries are adjacent to which, and a G cost associated with moving from one country to the next. You would also need to come up with a method for estimating H. Everything else would be handled the same as in the above example. Instead of using adjacent squares, you would simply look up the adjacent countries in the table when adding new items to your open list.
7. 非方块搜索区域： 在我们的示例中，我们使用了一个简单的2D方块布局。你不必使用这个方法。你可以使用不规则的形状区域。考虑一下棋盘游戏Risk，和游戏中的国家。你可以设计一个象那样的寻路关卡。为此，你将需要创建一个表来存储哪些国家和哪些国家相邻，以及相关的从一个国家移动到另一个国家的G值。你也需要选择一种估算H值的方法。其它的处理就和上面示例一样。当添加新项目到开放列表中时，你将简单的查找表中的国家，而不是邻近的方块。

Similarly, you could create a waypoint system for paths on a fixed terrain map. Waypoints are commonly traversed points on a path, perhaps on a road or key tunnel in a dungeon. As the game designer, you could pre-assign these waypoints. Two waypoints would be considered "adjacent" to one another if there were no obstacles on the direct line path between them. As in the Risk example, you would save this adjacency information in a lookup table of some kind and use it when generating your new open list items. You would then record the associated G costs (perhaps by using the direct line distance between the nodes) and H costs (perhaps using a direct line distance from the node to the goal). Everything else would proceed as usual.
同样的，你可以创建一个路点系统，对于固定地形场景中的路径。路点通常是一条路径上往来移动的点，这路径可能是一条道路，也可能是一个地下城的关键通道。作为游戏设计者，你能预先指定这些路点。如果没有障碍存在于两个路点间的直线路径上，就可以认为它们是“相邻”的，如同在Risk中那样，你应该保存这些邻接信息到一个某种类型的查找表中，当生成新的开放列表项目的时候使用它。然后记录相关的G值（可能是节点间的直线距离）和H值（可能是节点到目标的直线距离）。其他的和往常一样处理。

For another example of searching on an isometric RPG map using a non-square search area, check out my article Two-Tiered A* Pathfinding.
另有一个使用非方块搜索区域进行斜视角RPG地图搜索的例子，参考我的文章Two-Tiered A* Pathfinding。

进阶阅读Further Reading

Okay, now you have the basics and a sense of some of the advanced concepts. At this point, I'd suggest wading into my source code. The package contains two versions, one in C++ and one in Blitz Basic. Both versions are heavily commented and should be fairly easy to follow, relatively speaking. Here is the link.
好了，现在你具备了基础知识和对一些高级概念的感觉。在这里，我建议你到我的代码中跋涉。程序包有两个版本，一个是C++的，另一个是用Blitz Basic语言写的。两个版本都有大量注释，应该容易理解。链接在这里。

• Sample Code: A* Pathfinder (2D) Version 1.71

If you do not have access to C++ or Blitz Basic, two small exe files can be found in the C++ version. The Blitz Basic version can be run by downloading the free demo version of Blitz Basic 3D (not Blitz Plus) at the Blitz Basic web site. An online demonstration by Ben O'Neill can be found here.
如果你无法使用C++或者Blitz Basic，可以找到C++版本的两个exe执行文件。通过在Blitz Basic的网站下载免费的demo版Blitz Basic 3D，就能运行Blitz Basic版本。还能找到Ben O‘Neill写的在线使用示范。

You should also consider reading through the following web pages. They should be much easier to understand now that you have read this tutorial.
你也应该考虑通读下面的网页。阅读了本文后，它们应该非常容易理解了。

• Amit's A* Pages: This is a very widely referenced page by Amit Patel, but it can be a bit confusing if you haven't read this article first. Well worth checking out. See especially Amit's own thoughts on the topic.
• Amit's A* Pages: 这是Amit Patel维护的一个很广泛的参考页面，如果你开始没有读过本文，它是有点混乱的。很值得一读。特别看一下关于Amit本人的思想那个主题。
• Smart Moves: Intelligent Path Finding: This article by Bryan Stout at Gamasutra.com requires registration to read. The registration is free and well worth it just to reach this article, much less the other resources that are available there. The program written in Delphi by Bryan helped me learn A*, and it is the inspiration behind my A* program. It also describes some alternatives to A*.
• Smart Moves: Intelligent Path Finding : 这篇文章位于Gamasutra.com，Bryan Stout所写，需要注册才能阅读。注册是免费的，为了这篇文章是值得的，因为此类的文章可不多见了。程序是Bryan用delphi语言写的，它帮助我学会了A*，我的A*程序背后也有它的灵感。它也讨论了一些替代A*的解决方案。
  
• Terrain Analysis: This is an advanced, but interesting, article by Dave Pottinger, a professional at Ensemble Studios. This guy coordinated the development of Age of Empires and Age of Kings. Don't expect to understand everything here, but it is an interesting article that might give you some ideas of your own. It includes some discussion of mip-mapping, influence mapping, and some other advanced AI/pathfinding concepts. The discussion of "flood filling" was an inspiration for my own "dead ends" and "islands" map preprocessing code, which is included in the Blitz version of my program.
• Terrain Analysis: 这是一篇高阶的文章（但很有趣），Dave Pottinger所写。Ensemble Studios的专家。这些家伙开发了帝国时代[Age of Empires]和帝国时代II：帝王时代[Age of Kings]。不要指望能理解这里的所有东西，但它是一篇有趣的文章，也许能带给你一些属于你自己的想法。它包含了一些mip映射[mip- mapping]，影响映射[influence mapping]，和一些其他的高级AI/寻路的概念的讨论。对”洪水泛滥[flood filling]“的讨论给予了我设计自己的"死点[dead ends]"和"岛屿"地图预处理代码的灵感，这些都包含在我的程序的Blitz版本里面。

Some other sites worth checking out:
其它值得拜访的站点：

• aiGuru: Pathfinding
• Game AI Resource: Pathfinding
• GameDev.net: Pathfinding

Well, that's it. If you happen to write a program that uses any of these concepts, I'd love to see it. I can be reached at
好了，没有了。如果你要应用这些概念来写一个程序的话，我很高兴看到它。我的联系地址是

Until then, good luck!
那么，祝好运！

翻译：白龙[oglpc@263.net]