Jump to content
  • Advertisement
  • entries
  • comments
  • views

Pathfinding Part 2

Sign in to follow this  


See Part 1 for background: https://www.gamedev.net/blog/717/entry-2255124-pathfinding-part-1/

OK, so I had reached the point of frustration with my old pathfinding... what to do about it? It had become obvious to me that my pathfinding would have to do some searching to find a path to the target, rather than just walking towards the target semi-blindly.

The classic pathfinding algorithm is called A*. Simplified: A* does a search of the pathfinding space, optimizing the search such that it looks first at paths that go towards the target. It is relatively efficient and quite effective. I won't try to give a full description of A* as that has already been done, many places, very well. Here's one example from the comments: http://www.policyalmanac.org/games/aStarTutorial.htm

However, I had some concerns about A*:

  1. While efficient as far as search algorithms go, it is still a search algorithm. Running it every "tick" (generally 60 times per second) for every actor in a SENG game would have some cost.
  2. A* works very well for one entity searching in a static environment. However, as few as 2 entities can get stuck doing A*, constantly running into each other without ever finding the target. This is solveable, but I'd already solved these issues with my heuristic.
  3. Most importantly: A* works on a discrete space, like a chess-board. SENG has a continuous movement space. The Internet suggests some ways to deal with this, but it isn't a clear cut-and-dried algorithm. Mostly, "first, divide your space into discrete chunks".

A quick note: SENG uses a tile system for basic terrain (2.5 feet x 2.5 feet tiles). However, "objects" (like tables) and actors can have arbitrary position. Movement of actors is in any direction. Disallowing movement except along tiles (in order to implement A*) would be a significant step backwards for the game engine.

I decided to do a combination of A* and my heuristic:

  1. If we are close to the target, or far from the target, just use the "move towards the target" heuristic.
  2. Run A*, just using the tiles of the area (ignoring other actors).

    • If A* fails (no path to the target, or path too long), just move towards the target.

  • Pick the point on the A* path 12.5 feet from the moving actor. Call this the waypoint.

    • Use the heuristic movement to move towards the waypoint until we are halfway there, or if we aren't making progress towards the waypoint.

    • Go back to (1).

      OK, here's an example. In this picture, the actor wants to follow the green path. A* calculates the blue path as the optimal path to the target. (Note that this path would actually be a jagged line due to the tile based nature of the algorithm, but I didn't feel like drawing that). The red path represents the waypoint that the actor has selected to move towards.


      In this picture, the actor has gotten halfway to the waypoint, so he recalculates:


      And, in this last picture, the actor got halfway to the next waypoint. Note that the waypoint is now starting to move around the corner; however, the heuristic movement is capable of negotiating simple obstacles and will "bounce" around the corner of lava in the way.


      I am very pleased; this new pathfinding algorithm combines many of the good features of A* and the heuristic:

      1. Very efficient. We generally only perform a search of the area tiles every few seconds (per actor). There is no noticeable performance impact of this pathfinding algorithm vs the heuristic.
      2. Works well with moving targets and moving obstacles. The heuristic algorithm, with its simple minded directed movement, deals quite well with this. A* is restricted to the long-range planning where these problems aren't a factor.
      3. Movement is continuous, so the actor moves directly towards the target with no zig-zagging. There is actually just a little visible zig-zagging due to waypoints always being the center of a tile, but it is barely noticeable.
      4. Properly moves around indentations, long walls and other complex formations, due to use of A*.

      When I next release a beta of 10 Fantasy Fights, you can experience for yourself!
  • Sign in to follow this  


    Recommended Comments

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Advertisement

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!