A * method summary

Now that you have read the entire instruction, let's write the operations in each step together:
　

Add the Start entry to the Enable list.
Repeat the following steps:
A) Search for the lattice with the lowest f value in the enabled list. We call it the current grid.
B) switch it to the disabled list.
C) For each of the adjacent 8 cells?
If it fails or is already in the closed list, skip it. Otherwise.
If it is not in the Enable list, add it. Use the current grid as the parent node of this grid. Record the F, G, and H values of this grid.
If it is already in the enabled list, use the G value as the reference to check whether the new path is better. A lower G value means a better path. In this case, the parent node of the grid is changed to the current grid, and the G and F values of the grid are recalculated. If you keep your enabled list sorted by the F value, you may need to sort the enabled list again after the change.
D) stop when you
Add the target cell to the Enable list. At this time, the path is found, or
The target cell is not found. The enable list is empty. At this time, the path does not exist.
Save path. Starting from the target lattice, move along the parent node of each grid until the start lattice is returned. This is your path.
Sorry, it is worth mentioning that when you see different discussions about a * on the Internet or in related forums, sometimes you will see some code used as a * algorithm, but they are not actually. To use a *, you must include all the elements discussed above-a specific list of enable and disable, and use F, G, and h for path evaluation. There are many other pathfinding algorithms, but they are not a *, and a * is considered to be the best among them. Bryan stout describes some of their advantages and disadvantages in a reference document later in this article. Sometimes other algorithms will be better in a particular scenario, but you must be very clear about what you are doing. Okay, enough. Return to the article.

Implementation Annotation

Now that you understand the basic principles, you have to consider some additional things When writing your program. Some of the following materials reference programs I wrote in C ++ and blitz basic, but they are equally effective for code written in other languages.

Maintenance activation list: This is the most important part of a * pathfinding algorithm. Each time you access the Enable list, you need to find the square with the lowest f value. There are several different methods to achieve this. You can save the path element as needed. When you need to find the element with the lowest f value, traverse the enabled list. This is very simple, but it is too slow, especially for long paths. This can be improved by maintaining a sorted list. You only need to select the first element of the List to find the square with the lowest f value each time. This method is my first choice when I implement it myself.
In the small map. This method works well, but it is not the fastest solution. A * programmer who is more demanding on speed uses a method called "binary heap", which is also the method I use in code. Based on my experience, this method will be faster than 2 in most cases ~ 3 times, and the speed on the long path is increased in a geometric series (10 times or more ). For more information about binary heap, refer to my article: using binary heaps in a * pathfinding.
Other units: if you happen to have read the code in my example, you will find that it completely ignores other units. My Pathfinder can actually cross each other. Depending on the specific game, this may be okay, maybe not. If you want to consider other units and want them to bypass each other, I suggest you ignore other units in the pathfinding algorithm and write some new code for collision detection. When a collision occurs, you can generate a new path or use some standard moving rules (such as always to the right) until there is no obstacle on the road, and then regenerate the new path. Why not consider other units in the initial path calculation? That's because other units will move. When you reach their original location, they may have left. This may lead to a strange result: a unit suddenly turns to avoid a unit that is no longer there, and will hit the calculation path and rush into the unit in its path.
However, ignoring other objects in the pathfinding algorithm means you must write a separate collision detection code. This is different from the game, so I leave this decision to you. In the reference list, Bryan Stout's article is worth studying. There are some possible solutions (such as robust tracing and so on ).
Some speed tips: when you develop your own a * program or rewrite my program, you will find that path searching takes a lot of CPU time, this is especially true when a large number of objects are found on a map. If you have read other materials on the Internet, you will understand that, even if you have developed Starcraft or the Empire era experts, this is helpless. If you think the path is too slow, some suggestions here may be effective:
Use a smaller map or fewer Pathfinder.
Do not route multiple objects at the same time. Instead, they are added to a queue to distribute the pathfinding process across several game cycles. If your game runs at a speed of 40 cycles per second, no one can notice it. However, they will find that the speed of the game suddenly slows down when a large number of Pathfinder calculate their path.

Use a larger map grid whenever possible. This reduces the total number of grids to be searched in the search path. If you are interested, you can design two or more tracing systems for use in different scenarios, depending on the path length. This is exactly what professionals do. They use a large area to calculate a long path, and then switch to a small GRID/area to find the path when approaching the target. If you are interested in this point of view, read my article: two-tiered A * pathfinding.
Use the path point system to calculate the long path, or pre-calculate the path and add it to the game.
Preprocessing your map indicates which areas of the map are not reachable. I call these regions "isolated islands ". In fact, they can be islands or other areas that cannot be reached by walls. The lower limit of a * is that when you tell it to find the path to those areas, it searches for the whole map, until all reachable squares/nodes are computed by enabling or disabling the list. This wastes a lot of CPU time. You can pre-determine these regions (such as through flood-fill or similar methods) to avoid this situation, record this information with some types of arrays, and check it before you start searching. In my blitz code, I created a map Preprocessor to do this. It also indicates the dead end that can be ignored by the pathtracing algorithm, which further improves the pathtracing speed.
Different terrain loss: In this tutorial and my program, there are only two kinds of terrain-accessible and inaccessible. But you may need some terrain that can pass through, but it takes longer to move-swamp, Hill, dungeon stair, and so on. These are all terrain that can be passed but are more expensive than flat land movement. Similarly, roads are less costly than natural terrain movement.
This problem can be easily solved by increasing the terrain loss when calculating the G value of any terrain. Simply add some additional losses to it. Because the * algorithm has been designed to find the lowest-cost path, it is easy to handle this situation. In the simple example provided by me, only the terrain can pass and cannot pass. A * will find the shortest and most direct path. However, in different terrain scenarios, the path with the lowest cost may contain a long moving distance-like bypassing the swamp along the road rather than directly traversing it.
An additional consideration is what experts call "influence mapping ). As described above, you can create an additional score system and apply it to AI. Suppose you have a map with a large number of Pathfinder users, all of which are going through a certain mountainous area. Every time a computer generates a path that passes the mark, it becomes more crowded. If you want to, you can create an influence ing map to adversely affect the grids with large numbers of slaughter events. This will make computers more inclined to secure paths and help them avoid continuing to send teams and Pathfinder to a specific path just because the path is short (but may be more dangerous.
Dealing with unknown areas: Have you ever played such a PC game, and the computer always knows which path is correct, even if it hasn't detected a map? For games, finding the path too good will seem unrealistic. Fortunately, this is an easy solution.
The answer is to create an independent "knownconfigurability" array for each different player and computer (each player, rather than each unit-that would consume a large amount of memory, each array contains the areas that the player has explored, and other areas that are considered accessible through the area until they are confirmed. In this way, the Unit lingers at the dead end of the road and leads to wrong choices until they find the path around them. Once a map is explored, the path is searched as usual.
Smooth path: although a * provides the shortest and lowest cost path, it cannot automatically provide the seemingly smooth path. Let's take a look at the final path of our example (in Figure 7 ). The first step is the bottom right of the starting grid. If this step is directly down, will the path be smoother?
There are several ways to solve this problem. When calculating the path, it can exert adverse effects on the grid that changes the direction and add additional values to the G value. You can also use another method. You can run the path again after calculation, and find the places that will make the path look smoother by replacing the adjacent cells. For the complete results, see the article "toward more realistic pathfinding" published by Marco Pinter at gamasutra.com ).
Non-square search area: In our example, we use a simple 2D square chart. You may not use this method. You can use irregular areas. Think about adventure games and those countries in the game. You can design a path-finding level like that. To do this, you may need to create a table of neighboring countries and move the G value from one country to another. You also need to estimate the H value. Other things are exactly the same as in the example. When you need to add new elements to the open list, you do not need to use adjacent grids. Instead, you need to find neighboring countries from the table.
Similarly, you can create a path point system for a definite topographic map. The path points are generally the turning points of the road or the dungeon channel. As game designers, You can preset these path points. Two path points are considered adjacent if there is no obstacle in the straight line between them. In the adventure game example, you can save the adjacent information in a table and use it when you need to add an element to the list. Then you can record the associated g values (the linear distance between two points may be used), H values (the linear distance to the target point can be used ), you can simply follow the previous steps.
Another example of searching for an RPG map in a non-Square area shows my article: two-tiered A * pathfinding.

Further reading

Well, now you have a preliminary understanding of some further points. At this time, I suggest you study my source code. The package contains two versions: C ++ and blitz basic. By the way, both versions are detailed and easy to read. Here is the link.
Sample Code: A * Pathfinder (2D) version 1.71

If you neither use C ++ nor blitz basic, there are two small executable files in C ++. Blitz basic can be run on the free litz basic 3D (not blitz plus) demo version downloaded from the blitz basic website. Ben o ''neill provides an online demonstration available here.

You should also look at the following webpage. After reading this tutorial, they should become much easier to understand.

Amit A * Page: This is a widely used page created by Amit Patel. It may be hard to understand if you have not read this article beforehand. It is worth looking. In particular, we should look at Amit's own views on this issue.
Smart moves: Smart path searching: This article published by Bryan stout at gamasutra.com must be registered before you can read it. Registration is free and is worth the money compared to this article and other resources on the website. Bryan uses a program written in Delphi to help me learn a *, which is also the source of inspiration for my A * code. It also describes several changes of.
Terrain Analysis: This is an advanced but interesting topic, written by Dave pottinge and expert at ensemble Studios. This guy is involved in the development of the empire and kings. Don't expect to understand everything here, but this is an interesting article that may make you come up with your own ideas. It includes some advanced AI/pathfinding ideas about MIP-mapping, influence mapping, and others. The discussion of "Flood filling" inspired me with my own "Dead End" and "island" code, which is included in my blitz version of code.
Other Websites worth reading:

Aiguru: pathfinding
Game AI Resource: pathfinding
Gamedev.net: pathfinding
Other references:

Artificial Intelligence: pathfinding and searching
Featured articles: featured articles