Jump to content

A simple method to speed up path finding

4: Adsense

The method is simple.
Attached Image: 1.jpg
Red grid is block grid,Green grid can walk.
first,Pre process on map to get datas that we need:
1) The map is divided into many regions, each region consist of a number of grids, these regions must be convex polygon(int most cases,they are rectangulars), there are not block grids in these regions.
Attached Image: 2.jpg
2) then generate the shortest path information between regions, such as: the shortest path information between region r1 to region r4 is: r1 -> r2 -> r3 -> r4, save these information in a table.
3) get shared adjacent grid between regions,for the sake of brevity,I shall select middle grid in share adiacents.
4) Save the above information to map data file.

Second, path finding process:
1)Determine region where the source grid at and region where dest grid at, for example the source grid in the region r1, the dest grid in the region r4.
2) find the shortest path between the two regions by searching the region path table, the shortest path between the region r1 and region r4 is: r1 -> r2 -> r3 -> r4, this is rough path.
3) the result path will is: source grid -> g2(regions r1 and r2 share grid g2) -> g3(region r2 and region r3 shared grid g3)-> dest grid.
Attached Image: 3.jpg
Because there are not block grids in these convex polygon regions, so we can walk a straight line in these regions.


May 27 2013 09:37 PM

Brief, good

May 29 2013 09:48 AM

Rock on dude!!!

Jun 01 2013 09:55 PM
Interesting, how would it deal with large maps and dynamically changing environments?
Oct 29 2013 11:59 AM

Excellent idea , Seems quite hard to implement in game programming.

Dec 05 2013 09:36 AM

This technique won't guarantee finding the shortest path. The shortest path between 2 regions will in many cases depend on where in the starting region the source is, and where in the destination region the goal is.


A more accurate implementation in terms of the optimal path would be to build the table not out of the region to region table, but the list of shared edges to the list of shared edges. Then that lookup table distances can be supplemented with the knowledge of the distance to those edges within the starting and ending region to better calculate an optimal path. This is the same reason why in a navmesh, using the center of the regions is a very poor reference point for the weighting calculations for the search.

Note: GameDev.net moderates article comments.