Loading in 5 sec....

Toward More Realistic PathfindingPowerPoint Presentation

Toward More Realistic Pathfinding

- By
**Leo** - Follow User

- 294 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about 'All FPS pathing problems in a presentation' - Leo

**An Image/Link below is provided (as is) to download presentation**

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

### Toward More Realistic Pathfinding

Authored by: Marco Pinter

Presentation Date: 11/17/03

Presented by: Ricky Uy

Background – A*

- Commonly used in video games
- Finds a path from start to goal, if one exists
- Finds optimal path given that the heuristic is an underestimate, i.e. always <= actual cheapest path cost from a node X to the goal

Background – A*

Algorithm

- Repeatedly examines the most promising unexplored location it has seen
- If an examined location is the goal, algorithm is complete; else, note all neighboring locations for further exploration

Background – A*

Algorithm

- Uses “Open” and “Closed” states for unexamined and examined nodes
- “Open” is a priority queue
- Priority determined by whatever the path is trying to minimize, e.g. distance traveled
- Total cost = actual cost from start to node X + heuristic cost from X to goal

Background – A*

Algorithm

- Initially only the start location is in Open, with start.parent = null
- Pop node off Open and examine it
- Place node into Closed list
- All unblocked neighbors updated and placed into Open queue
- If Open list becomes empty before goal is found, there is no path from the start to the goal location

Background – A*

Demo – taken from an article by Bryan Stout in Game Programming Gems

Background – A*

Limitations

- Worst case time: when there is no path from start to goal
- Produces zigzag effect
- Does not produce smooth turns
- Does not check for “illegal moves” or for abrupt turning when a unit has a particular turning radius
- Memory limitations: huge number of nodes in Open and Closed lists

Background – A*

Optimizations

- Hierarchical pathfinding, albeit subject to path failure by choosing impossible locations as midpoints
- Use a basic non-priority list with previous and next pointers instead of a priority queue
- Loses on search time: O(n) compared to O(log n), but wins on insertions and deletions

Removing the Zigzag Effect

Can just associate a cost with each turn, but that does not solve the problem entirely. A better smoothing process is to remove as many waypoints as possible.

Removing the Zigzag Effect

checkPoint = starting point of pathcurrentPoint = next point in pathwhile (currentPoint->next != NULL) if Walkable(checkPoint, currentPoint->next) // Make a straight path between those points: temp = currentPoint currentPoint = currentPoint->next delete temp from the path else checkPoint = currentPoint currentPoint = currentPoint->next

Removing the Zigzag Effect

Checks path from waypoint to waypoint. If the path traveled intersects a blocked location, the waypoint is not removed. Otherwise, remove the waypoint.

Leaves “impossible” sections as is.

Adding Realistic Turns

Want to be aware of a unit’s turning radius and choose shortest route to destination, in this case the right turn will lead to the shortest route.

Adding Realistic Turns

- Calculate the length of the arc plus the line segment for both left and right turns. Shortest path is the one to use.

Adding Legal Turns

Several Postprocess Solutions (cheats)

- Ignore blocked tiles – obviously bad
- Path recalculations – associate a byte with each tile, each bit denoting the surrounding tiles as legal or illegal; may invalidate legal paths from other directions = bad
- Decrease turning radius until it is legal – bad for units with constant turning radius (e.g. truck), good for units such as people
- Backing up – make a three point turn – good for units such as trucks, weird for people

Adding Legal Turns

Problems

- Methods shown previously are basically cheats, except for the second one (path recalculations), which can fail to find valid paths
- How can we make sure that paths taken are both legal and do not violate the turning radius?

Directional A*

Sometimes the only legal path that does not violate the turning radius constraints is completely different from the path that the standard A* algorithm produces. To get around this, Pinter proposes a modification known as Directional A*.

Directional A*

First things first

- Add an orientation associated with each node, where the orientation can be any one of the eight compass directions
- Each node now represented by three dimensions: [x, y, orientation]

Directional A*

- Check the path from a parent to a child node, not just whether or not the child is a blocked tile
- Consider the orientation at parent and child nodes as well as the turning radius and size of the unit to see if path hits any blocked tiles
- Result: a valid path given the size and turning radius of the unit

Directional A*

Directional A* does not go directly from a to c because it sees that an abrupt right turn would cause the unit to hit blocked tiles. Thus, waypoint b is found as the shortest legal path.

Directional A*

- Can easily compute the four common paths and choose the shortest one
- Can add smoothing algorithm presented earlier, with the modification of sampling points along a valid curve between two points rather than just a straight line between two points

Expanding the Search

- So far, have been using a Directional-8 search
- Some paths will fail under this method
- Try searching more than one tile away
- Directional-24: search two tiles away, rarely fails to find a valid path
- Directional-48: search three tiles away, almost never fails to find a valid path

Expanding the Search

Example of a case where Directional-8 fails, but Directional-24 finds a valid path

Modifying the Heuristic

- Standard A* measures straight line distance from start to goal
- Modify so that it measures the shortest curve and line segment as calculated earlier, considering turn radius
- If units can go in reverse, consider adding a cost penalty to encourage units to move in reverse only when necessary

Directional A* Limitations

- Very slow, constantly uses tables as a means to optimize it (directional table, heuristic table, hit-check table, etc)
- Directional-48 may still possibly (though rarely) fail
- The four common paths from origin to destination are not the only ones; there is an infinite number of paths

Better Smoothing Algorithm

- Previous method of removing waypoints has some faults

Better Smoothing Algorithm

- Perform standard A* algorithm
- Then, perform Directional-48 algorithm that favors the path found by the standard A* algorithm by modifying the cost heuristic
- Finally, perform the smoothing algorithm described earlier (removing waypoints)
- This will find the blue line path on the previous slide

Limitations on Better Smoothing Algorithm

- Fails to find valid paths that a full Directional-48 search would find

Limitations on Better Smoothing Algorithm

- Does not find blue line path because of its bias towards the original path
- Ends up not finding any path at all
- To help performance in this worst case scenario, return failure if six or more points have been searched backwards

More Optimizations

- Timeslice the search
- Only use Directional-24 and -48 if a Directional-8 fails
- Divide map into regions and pre-compute whether a tile in one region can reach a tile in another
- Use two matrices to calculate intermediate search results, one for slow, timesliced searches and the other for faster searches

One Possible Hybrid Solution

- Perform standard A* search, checking only four tiles at every node
- Perform Smoothing-48 pass; if successful, skip to last step, otherwise note farthest node hit
- Work backwards from goal using Smoothing-48 pass and note farthest node hit
- Take the two farthest point nodes and make sure they are less than, but close to, 12 tiles apart. If more than 12 tiles, return failure.
- Perform Directional-8 between the two nodes and connect the three segments into one path
- Perform the initial simple smoothing algorithm (the one that removes unnecessary waypoints)

Speed and Other Considerations

- For sand, add a cost to the heuristic
- For speed, add a cost for turns made

Summary

- Directional A* finds legal paths and realistic turns
- Directional A* is slow
- Examples only take into account a 2D space partitioned into a grid, but can be extended to support various partitioning methods in 2D or 3D
- Suggest standard A* for most units and Directional A* for various large units

Download Presentation

Connecting to Server..