A simple method to speed up path finding

Published January 03, 2012 by Niu Jian, posted by NiuJian
Do you see issues with this article? Let us know.
Advertisement
The method is simple. 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. 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. 3.jpg Because there are not block grids in these convex polygon regions, so we can walk a straight line in these regions.
Cancel Save
0 Likes 5 Comments

Comments

zgysx

Brief, good

May 28, 2013 03:37 AM
hele

Rock on dude!!!

May 29, 2013 03:48 PM
GDM
Interesting, how would it deal with large maps and dynamically changing environments?
June 02, 2013 03:55 AM
Fennekin.hnnaik

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

October 29, 2013 05:59 PM
DrEvil

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.

December 05, 2013 03:36 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement