The smooth version of "A * Path Search primer"??

A * Getting Started with path search

Patrick Lester published on October 8, 2003 8 o'clock in the afternoon 33 AI

If you find that there are errors or problems in the text (missing images or files, damaged code, incorrect text formatting, etc.), cause you cannot read it, contact the editor so that you can correct it. Thank you for helping us improve this resource.

Updated on July 18, 2005

This article has been translated into Albanian, Chinese, French, German, Portuguese, Russian and Spanish. Other translations are welcome. There is a contact email address at the end of this post.

For Beginners, A * (read a-star, translator Note: Foreigner reading A-star) algorithm may be somewhat complex. Although there are many articles on the Internet that explain the A * algorithm, most are written to the basic. This article is for the pure novice. (Translator: If you do not understand the novice, I am sorry is the wrong translation.) ）

This article does not attempt to become an authoritative book on this subject. Instead, it is the elaboration of the principles and the readiness to allow you to read all the other materials and understand what they are saying. At the end of this article there are links to some of the better and more readable information.

Finally, this article is not a concrete solution. You should be able to accept any computer language that appears in the text. As you would expect, anyway, at the end of this article, there is a link to the demo program. There are two versions in the demo package: one is C + +, and the other is Blitz Basic (http://www.blitzbasic.com/Home/_index_.php). If you want to run a * program, there is also an executable file.

But we are going beyond ourselves. Start from the beginning ...

Introduction: Search area

Suppose you want to reach point B from point A. There is a wall separating ab two points in the middle. As shown in the face, use green to indicate the start a, the end B in red, and the middle wall in blue.

[Figure 1]

First, the search area is divided into grid-made grids. This is called simplifying the search area, which is the first step in the path search. This method simplifies the search area into a two-dimensional array. Each element in the array represents a square in the grid, and the squares are recorded as being able to walk and not to walk. The squares that pass from point A to point B are called paths. Once the path is found, it is possible to move from the center of a square to the next center until it reaches the target.

These center points are referred to as "nodes." When you look at other paths to search for data, you often see a discussion node. Why don't you call them squares? Because it's really possible not to divide the path search area into squares. Can be a rectangle, hexagon, triangle, or any shape. A node can be represented by any shape-in the center or along the edge, or anywhere else. However, because the squares are the simplest, we use squares.

Start Search

Once the search area is simplified to a manageable number of nodes, like the grid layout described above, the next step is to search to find the shortest path. From point A, check the adjacent squares and spread the search outward until you find the target.

Start the search by doing the following:

1. Start from start A and add it to the "open list". Opening the list is a bit like a shopping order. Although there is only one item in the list, there will be more in the future. It contains probably what you want, or maybe not. Basically, this is the list of squares that need to be checked.

2. Find all reachable or accessible squares adjacent to the starting point, ignoring walls, water or other illegal terrain. Add them to the open list. For each square, save point A as their "parent". The father is important when it comes to tracing the path. It will be explained later.

3. Remove start a from the open list and add it to the close list that you do not need to find again.

At this point, you should have an impression similar to the illustrations below. In the diagram, the dark green squares in the center are the starting squares. It is outlined as light blue to indicate that it has been added to the close list. Check all squares adjacent to it in the open list and frame them with light green. Each square has a gray pointer back to their parent, which is the start of the square.

[Figure 2]

Next, we choose to open an adjacent square on the list and more or less repeat the previous procedure as described below. But which box do we choose? One with the minimum F value.

Path scoring

In the calculated path, the following formula is the key to determining which squares to use:

F = G + H

Over here

G = The running cost of moving from start a along the resulting path to a given square.

H = estimated operating cost for moving from a given square to end B. This is often called heuristics, which can be a bit confusing. Because it's an estimate, so to call it. Before we find the path, we really don't know the actual distance, because all kinds of things are on the way (wall, water, etc.). A method for calculating H is given in this tutorial, but many computational h methods can be found in other articles on the web.

By iterating through the open list repeatedly, select the squares with the minimum F values to generate our paths. This process will be described in more detail in this article. First, take a closer look at how to calculate with formulas.

As mentioned above, G is the moving cost of moving from the starting point to the path generated by the given point. In this example, we will specify that each horizontal or vertical moving grid cost is 10, and the cost of the diagonal move is 14. We use these numbers because moving along the hypotenuse is the square root of 2 (Don't be afraid), which is about 1.414 times times the horizontal or vertical movement. We use 10 and 14 for the sake of simplicity. The proportions are roughly correct, and you can avoid calculating square roots and decimals. It's not just because we're stupid, we don't like maths. Using these numbers is to make the calculations faster, too fast. You will soon find that if you do not use these shortcuts, the path search may be slow.

Since the G value we calculate is along a specific path to a given square, this approach is to find the square's parent's G value, and then add 10 or 14 depending on whether it is orthogonal (non-diagonal) or diagonal from the parent's move. In this case, the need for this method will become a bit more obvious as we start to get more than one square from the beginning of the square.

H can be estimated in various ways. Here the Manhattan method is used to calculate the total number of squares moved horizontally and vertically from the current square to the target square, ignoring diagonal motions and ignoring any possible obstacles in this way. Then, multiply the total by 10, moving the cost horizontally or vertically one grid. This is (possibly) called the Manhattan method, as it calculates the number of city blocks from one place to another, and cannot cross diagonally.

Reading this note, you may have guessed that the heuristic is just a rough estimate of the distance between the current square and the target, "like a Crow flying" (Translator note: straight-line distance). That's not true. We are actually trying to estimate the remaining distance along the path (usually farther). It is estimated that the closer the actual remaining distance is, the faster the algorithm is. If this distance is overestimated, then it is not guaranteed to give the shortest path at the beginning. Under such circumstances, we have so-called "unacceptable heuristics".

Technically, in this case, the Manhattan approach is unacceptable because it slightly overestimated the rest of the distance. But we can use it anyway, because it's a much easier to understand our intentions because it's just a slight overestimate. In rare cases, the resulting path is not the shortest, and this will be the shortest approximation. Want to know more? You can find the same or additional instructions here (http://www.policyalmanac.org/games/heuristics.htm) about heuristics.

F is the and of G plus H. The results of the first step of the search can be seen in the following description. The values in F,g and H are written in each square. As in the square to the right of the starting square, F is printed in the upper-left corner, G is printed in the lower-left corner, and H is printed in the lower-right corner.

[Figure 3]

So, take a look at some of these squares. On a square with a letter, G = 10, which is because it is in a horizontal direction from the starting square with only one square. Adjacent to the top of the starting square, below, and the left square has the same G value 10, the diagonal square g value is 14.

The H value is calculated by estimating the distance to the red Target Square in Manhattan, where the calculation is only moving horizontally and vertically and ignoring the wall. Using this method, starting from this square directly to the right 3 blocks is the red lattice, H is 30. (Translator note: linear distance) then the H value of the squares above this square is 4 blocks away (remember, only horizontal or vertical movement) an H value of 40. You may see the method of calculating H values for other squares.

The F-value of each square, again, simply adds the G and H together to the calculated result.

Continue Search

To continue the search, we simply select the squares with the minimum f value in the Open list. Then we use the selected squares to do the following things:

1. Remove it from the open list and add it to the close list.

2. Check all adjacent squares. Ignore those (walls, water, or other illegal terrain) that are in the closed list or not, and if they are not in the open list, add to the open list. Selects the selected Square as the "parent" of the new square.

3. If the adjacent squares are already on the list, see if it is good to go along this path to that square. In other words, check to see if we use the current grid to get there, if the G value of the square is lower. If not, do nothing.

On the other hand, if the new path has a lower g value, change the parent of the adjacent squares to the selected squares (above, change the direction of the pointer to the selected square). Finally, recalculate the square's F-value and g-value. If this seems confusing, in the back you will see the description of it.

Well, let's see how this works. In the first 9 squares, there are 8 open lists after the starting square is placed in the closed list. Where the lowest f value is a square immediately to the right of the starting point, with an F value of 40. Therefore, select this square as the next square. Highlight the blue part as shown.

[Figure 4]

First, remove it from the open list and add it to the close list (that's why it's highlighted in blue). Then check the adjacent squares. Well, the square on the right side is the square on the wall, ignoring it. Next to the left is the start square. It is closed on the list, so it is also ignored.

The remaining 4 squares are already in the open list, so check the G value as the reference point if using those squares as paths is better than using the squares. Take a look at the box on the right side of the selection block. Its g value is 14, if we get there through the current square, the G value will be equal to 20 (10, now the G value of the square, plus the 10来 vertically to its top). The G value is 20:14 high, so this is not a better path. If you see a better understanding of this. Move a square diagonally from the beginning of the grid to a more straightforward place, rather than moving a square horizontally, and moving a square vertically.

When you repeat this process for the 4 adjacent squares in the open list, you will find that no path is higher than the current one, so it does not change anything. So, now, look at all the adjacent squares, use this box to finish the check, and prepare to move to the next square.

So, by opening the list and now reducing the list to 7 squares, we then select one with the minimum F value. Interestingly, in this case, the F-value of two squares is 54, so which one do we choose? It doesn't really matter. For quick purposes, selecting the last box you added to the open list can be faster. This biased search is more favourable than searching slowly, when you are closer to the target. But it doesn't really matter. (Different processing results in two versions of a * may find different equal-length paths.) ）

Therefore, we choose to start the grid at the bottom right of the grid as shown in.

[Figure 5]

This time, check the adjacent squares, you will find that one to the right immediately is a wall of squares, so ignore. Also use the above. The squares below the wall are also ignored. Why is it? Because you can't let the squares cut through the nearby corner directly from the current grid. In this process you really need to go down and move that square around the corner. (Note: The rules for cutting corners are optional depending on how your nodes are placed.) ）

There are 5 squares left. The other two squares are below the current grid and are not in the open list, so add them and change the current squares to their parent. The other 3 squares, 2 of which are already in the closed list (start squares, and a little above the current grid, in the blue highlighting two figures), so ignore them. And the final square, before the current square to the left, to check if you go through the current grid to see if there is a low G value. There's no squares. So, you're done, you've checked the next square in the open list.

Repeat the process until you add the target grid to the close list, at which point it looks like the following illustration.

[Figure 6]

In, it is important to note that the parent of the two squares under the beginning of the grid has changed. Before, it has a G value of 28, which refers back to the square on its right. Now it has a value of 20 and points it above the square. This occurs when searching along a path, checking the G value and taking a smaller value as a new path-so the parent is switched, and the G-Value and F-value are also recalculated. In this example, although this change does not seem to be very important, there are many possible scenarios in which the constant check will make a big difference when determining the best path to reach the target.

So how do you determine the path? Simple, just start in the Red Target box, and try to move back to the parent square, below the arrow. This will eventually take you back to the start square, which is your path. It should look like the following illustration. Moving from square A to target square B is the problem of moving from the center of each square (node) in the path to the center of the next square until it reaches the target.

[Figure 7]

A * Method Summary

Well, now by explaining, in one place, showing a step-by-step approach (Translator Note: Here, organize each step):

Add the start grid (or node) to the open list.

Repeat the following actions:

A) Look for squares that open the minimum F value on the list. Use it as the current square.

b) switch to the close list.

c) For each of the 8 squares adjacent to the current grid .... (For each)

If it cannot go, or if it is on the close list, ignore it. Otherwise, perform the following actions.

If it is not in the open list, add it to the open list. Make the current square the parent of this square. The recorded square F-value, G-value, and H-value.

If the list is turned on, check to see if it is better to use the G value to measure the path to that square. A lower G-value means that this is a better path. If so, change the grid's parent to the current square and recalculate the G and F values of the squares. If you keep the open list sorted by F value, you may need to re-save the list due to this change.

D) When you stop:

In the case where the target square is added to the closed list, the path has been found (see note below), or the target square cannot be found, and the open list is empty. In this case, the path does not exist.

Save the path. Go back from the target square and move from each square to its parent until you reach the start square. This is the desired path.

Note: In earlier versions of the article, it was suggested that when the target grid (or node) has been added to the open list instead of the closed list, you can stop. This will be faster and it will almost always give you the shortest path, but not always. In some cases, this can have an impact when the movement cost of moving from the second to the last node to the last (target) node can vary significantly-for example, if the river crosses between two nodes.

Small "Anger"

Excuse me, but it's worth pointing out that when you read a * path search on the Web, and in various discussions on various forums, you occasionally see someone mentioning that some code is not a *. For a * Use method, you need to include the elements discussed above-especially open and closed lists and paths with F-values, G-values, and H-values. There are many other path search algorithms that are often considered the best method but not a *. At the end of this article there are Bleinstort discussions, including some of their many pros and cons cited by the article. Sometimes alternatives are better in some cases, but you should understand that you are entering. (translator: Don't be misled) okay, cool. Back to the topic.

Precautions for implementation

Now that you understand the basic approach, there are some extra things to consider when you write your own program. Here are the programs I wrote in C + + and blitz Basic, which are also valid in other languages.

1. Other units (collision avoidance): If you happen to look closely at my demo code, you'll notice that it completely ignores the other cells on the screen. These cells pass through each other. Depending on the game, this may be possible and may not be possible. If you want to think about other cells in the path search algorithm and let them move around, I recommend that you only consider stopping units or paths to search for cells near the calculated path, and cannot walk to their current position. For moving adjacent cells, you can prevent collisions by punishing the nodes along their respective paths, prompting the path-finding unit to find an alternate path. (There are more descriptions in # #).

If you choose to consider moving cells and paths looking for other cells that are not next to each other, you will need to develop a way to predict where they will be at any given point in time so that they can get the proper avoidance. Otherwise, you are likely to be useful for twists and turns to avoid the strange path of nothing and other elements.

You will, of course, need to develop some collision detection code, because no matter how good the path is in its calculations, things can change over time. When a collision occurs, the unit must either calculate a new path, or if the other unit is moving and not an oncoming collision, wait for other units to pass before the current path continues.

These tips may be enough to get you started. If you want to learn more, here are some links you might find useful:

The role of the steering behavior:

http://www.red3d.com/cwr/steer/

Cregreno's work on the steering wheel is a bit different from the path search, but it can be integrated with path search to make a more complete move and collision avoidance system.

The length of the computer game turns:

Http://ducati.doc.ntu.ac.uk/uksim/uksim%2704/Papers/Simon%20Tomlinson-%2004-20/paper04-20%20CR.pdf

An interesting survey in steering and path search. This is a PDF file.

Coordinate unit operation:

Http://www.gamasutra.com/features/game_design/19990122/movement_01.htm

The first series consisting of two parts of the Imperial designer Dave Chai in the formation and group-based movement.

Achieve coordinated movement:

http://www.gamasutra.com/view/feature/3314/implementing_coordinated_movement.php

Two parts of the Dave Chai are made up of the second series.

2. Variety of terrain costs: In this tutorial and my accompanying program, the terrain is just one of two things – can walk and can't walk. But what if there is a terrain to go, but a higher cost of movement is needed? Swamps, hills, dungeons, stairs, etc.-these are examples of terrain that can be walked, but at a higher cost than flat open spaces. Similarly, roads may have lower operating costs than the surrounding terrain.

This problem is easily achieved by calculating the G value of any given node plus the cost of the terrain. Simply add an additional cost to such a node. A * path search algorithm is used to find the lowest cost path and should be easily handled by this problem. In the simple example I described, when the terrain is only able to walk and cannot walk, A * will find the shortest, most direct path. However, in a variable-cost terrain environment, a longer distance may be traveled with a minimal cost path-just like bypassing the Swamp road, rather than passing it directly.

An interesting additional consideration is what professionals call "impact mapping". As the above variable-cost terrain, you can create an additional integration system and apply it to the AI path. Imagine that you have some map of the units that pass through the mountains. Whenever the computer sends a pass through a path, it is hit. If you want, you can create a map of the effects of a mass slaughter to punish the nodes. This will teach the computer to take sides in a safe path and help it avoid the foolish case that it keeps dispatching troops through a particular path, just because it is short (but more dangerous).

Another possible use is to punish the nodes that move along the path. One disadvantage of a * is that when a group of cells all try to find a similar location path, there is usually a significant overlap with one or more cells trying to take advantage of the same or similar route to their destination. Adding a penalty point that has been "halted" by other units will help ensure a degree of separation and reduce collisions. Do not think of such a node as being unable to walk, however, because you also want multiple units to be able to squeeze through narrow passages in turn, if necessary. In addition, you should only punish the path to search for nearby cells, not all paths, otherwise you will get to avoid the unit's strange evasion behavior, are far less than their current path. In addition, you should only punish nodes along one of the current or future paths, rather than having already visited and left the previous path nodes.

3. Dealing with unexplored areas: You have played a PC game, the computer always know exactly how to go, even if the map has not been explored? Depending on the game, it is unrealistic to always get such a good path search. Fortunately, this is a very easy problem to deal with.

The answer is to create a separate "known through" array for each of the various players and computer opponents (each player, not every unit-that will require a lot of computer memory). Each array will contain information about the area that the player has explored, with other parts of the map until proven to be feasible. Using this method, the unit will wander around the dead end, making a similar error selection until they find the surrounding road. Once the map is explored, however, the path search will work correctly.

4. Smoother path: Although A * will automatically give the shortest, lowest cost path, it will not automatically give the path that looks the smoothest. Take a look at the final path of the calculation in the example (Figure 7). In this path, the first step is followed by the right side of the start square. If the first step is just below the starting point, isn't our path smoother?

There are several ways to solve this problem. When you are calculating the path, you can punish the nodes where there are changes in the direction, adding a penalty for their G-value deduction points. Alternatively, you can browse your path after the calculation and look for a path that looks better when you select adjacent nodes. To learn more about the whole issue, look to the more realistic path search (toward more realistic pathfinding), a (free but need to register) article on gamasutra.com macro Pinter.

5. Non-grid search area: In our case, we used a simple two-dimensional grid layout. You don't need to use this method. You can use irregular shape areas. Think about the risk of board games as well as the country in the game. You can design a path search scheme for games like that. To do this, you need to create a table that is used to store the neighboring country and to move from one country to the next related G value. You also need to come up with a method for estimating H. Everything else will be handled as in the example above. Instead of using adjacent squares, when adding new items to the open list, you will simply find the neighboring country in the table.

Similarly, you can create a signpost system for a path to a fixed topographic map. Signposts usually go through the points on the path, perhaps on a dungeon road or critical tunnel. As a game designer, you can specify these points in advance. Two signposts will be considered to be "adjacent" to each other without obstacles in the straight path between them. Because of the risk in the example, you will save the adjacency information in some sort of lookup table and use it to generate a new open list item. Then you will record the relevant G-values (possibly by using the straight-line distance between nodes) and the H cost (possibly using a straight-line distance from the node to the target). Everything will continue as usual.

Amit Pater also wrote a short article to delve into some alternatives. For another example of using an isometric RPG map search on a non-square search area, take a look at my article Layer two, A * path search (http://www.policyalmanac.org/games/twoTiered.htm).

6. Some speeding hints: when you develop your own a * program, or adapt what I write, you will eventually find that the path search uses a large chunk of your CPU time, especially if you are on a fairly large number of paths to search for the unit's board and a fairly large map. If you've read something online, you'll find that it's true even when designing professionals like StarCraft or Empire-era games. If you see something starting to slow down because of the path search, here are some ideas that might speed up:

Consider a small map or fewer units.

Never do a path search for several units at a time. Instead, put them in a queue and they are distributed over several game loops. If your game is running, say, 40 cycles per second, no one will notice. But they will find that when a group of cells at the same time are calculating the path, the game seems to slow down every time for a while.

Consider using larger squares (or whatever shapes you are using) for your map. This reduces the total number of nodes that are searched to find the path. If you have ambitions, you can design two or more path search systems that are used in different situations, depending on the length of the path. This is done by professionals, using a large area of long paths, and then switching to a finer use of smaller squares/area searches when you approach the target. If you are interested in this concept, look at my article two levels of a * path search.

For longer paths, consider revisions that are hard-wired to the pre-calculated path of the game.

Consider preprocessing the map to find out which areas are inaccessible from the rest of the map. I put these fields in the "island". In reality, they can be islands or any other area that is otherwise walled off and inaccessible. One of the drawbacks of a * is that if you tell it to look for paths and so on, it will search the entire map, stopping only when each squared access/node has been processed by opening and closing the list. This can waste a lot of CPU time. It can be prevented by pre-determining which areas are inaccessible (by flood filling or similar programs), logging in some type of array information, and then checking it before starting a path search.

In a crowded, maze-like environment, consider the node markings do not cause the dead ends. These areas can be manually pre-specified by the map editor, or if you are ambitious, you can develop an algorithm that automatically identifies the fields. Any collection of nodes in a given cul-de-sac can be assigned a unique identification number. Then when the path is searched, just stop to consider a dead-end area node, and if the starting position or destination happens to be in a particular cul-de-sac problem, you can safely ignore all the dead ends.

7. Maintain Open list: This is actually one of the most time-consuming elements in a * path search algorithm. When you have access to the open list, you need to find squares with a minimum f value. There are several ways to do this. As needed, you can save the path item, and each time you need to find a square with the minimum f value, simply traverse the entire list. This is simple, but very slow for long paths. This can be achieved by maintaining a sorted list, each time requiring a minimum F-cost square time to simply grab the first item from the list to be improved. When I write my program, this is my first method.

This will work pretty well for small maps, but it's not the quickest answer. Serious A * programmers who want to use a real speed is called a binary heap, which is what I use in my code. In my experience, this approach will be at least 2-3 times faster in most cases, and on longer paths in geometry faster (faster than three times). If you take the initiative to find out more about the binary heap, look at my article in a * path search using the binary heap (http://www.policyalmanac.org/games/binaryHeaps.htm).

Another possible bottleneck is your way of clarifying and maintaining the data structure between the path search calls. I personally prefer to store all arrays. Although nodes can be generated, recorded and saved in a dynamic, object-oriented manner, I find that the amount of time required to create and delete these objects increases the extra overhead and unnecessary levels slow down. If you use an array, however, you need to call something clean between them. You'll think the last thing in this situation is to spend 0 of your time doing everything. After the call path is searched, especially if you have a large map.

I avoid this overhead by creating a two-dimensional array called whichlist (x, y), which is specified on each node of my map as either an open list or a closed list. After attempting the path search, I do not return to the zero group. Instead, I search for each path in the call reset Onclosedlist and onopenlist values, each path tries to look like +5 anything is incremented. In this way, the algorithm can safely ignore any data left by the attempt to search for garbage from previous paths. I also like to store the cost values for F,g and H arrays. In this case, I just write in any pre-existing value and do not bother to clear the array when I do.

Storing data in multiple arrays consumes more memory, although so, there is a tradeoff. In the end, you should use what method you are most comfortable with.

8. Dijkstra algorithm: When a * is usually considered the best path search algorithm (see the small anger above), there is at least one other algorithm that has its purpose-Dijkstra algorithm. Dijkstra is basically the same as a *, except that there is no heuristic (H is always 0). Because it has no heuristics, it also expands the search in every direction. As you might imagine, since this Dijkstra algorithm is usually the end of exploring a larger area before the goal is discovered. This usually makes it slower than a *.

So, why use it? Sometimes, we don't know where our target is. Suppose you have a resource collection device that needs to get some kind of resource. It may know several resource areas, but it wants to go to the nearest one. Here, Dijkstra is better than a *, because we don't know which one is the closest. Our only option is to re-use a * to find the distance to each one and then select the path. There may be countless similar situations where we know that position we might be looking for, want to find the nearest one, but don't know where it is or which one might be the closest.

Extended Reading

Well, now you have the basics and some advanced concepts. At this point, I recommend you to wade through my source code. There are two versions in the package, one is C + + and the other is Blitz Basic. Two versions have a lot of comments, which should be relatively easy to follow. Here is the link.

Http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=turtle177604062002002208&comments=no "

(Translator Note: This link is not available now, please use: http://www.policyalmanac.org/games/AStar.zip)

Demo Code: A * Pathfinder (2 D) version 1.9

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 a free trial version of Blitz basic 3D (no Blitz plus) on the Blitz Basic website.

You should also consider reading through the following pages. If you've read this tutorial, now they're much easier to understand.

Amit's A * page:

Http://www-cs-students.stanford.edu/~amitp/gameprog.html#Paths

This is a very widely quoted page written by Amitpater, and if you have not read this article, it may seem a bit confusing. Well worth a try. Especially the topic of Amit own ideas.

Smart move: Smart Path Lookup:

http://www.gamasutra.com/view/feature/3215/myths_and_facts_in_avoiding_.php

This article is published by Brain Stott in the gamasutra.com that need to be registered for reading. Registration is free and well worth seeing, not to mention the available resources. Written by Brian with Delphi to help me learn A * program, it is the inspiration behind my A * program. It also introduces some of the A * alternatives.

Terrain Analysis:

Http://www.gamasutra.com/features/gdcarchive/2000/pottinger.doc

This is an advanced and interesting article written by Dave Pottinger, a full-fledged studio expert. This guy coordinated the development of the Empire era and the kings of the century. Don't expect to understand everything here, but it's an interesting article that might give you some ideas of your own. It includes mipmapping (translator Note: There is a common technique in mapping rendering of three-dimensional computer graphics), impact mapping, and other concepts of advanced AI/path search.

Some other sites about path search are worth a try (Translator Note: Basic no access):

Aiguru:pathfinding

Game AI resource:pathfinding

GameDev.net:Pathfinding

All right, that's it. I was thinking of you using these concepts to write programs. I can receive it via email.

[Email protected]

Good luck before placing your pen!

The smooth version of "A * Path Search primer"??