• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
DrEvil

A.I. Path Following

5 posts in this topic

So I have a nav mesh, the implementation and usage of which is pretty easy. The part of navigation systems that I typically struggle with a bit is the logic for following a path, which in principal doesn't sound like it would be difficult, but it has a number of non trivial elements.

 

Suppose you have a series of points representing a path to a destination. You often simply 'seek' to the next point in the path, but the tricky part comes in when it comes to what the logic is for 'advancing' the 'active' point to the next point. If you use some sort of 'in radius' check it can sometimes cause guys to abandon a point early and seek to the next point where they haven't cleared a corner for instance, and may get caught on the corner. In nav meshes in particular, paths around corners tend to hug the wall as closely as possible, whether due to string pulling or whatever, so incrementing the seek point needs to do so in a reliable way so as to recover from getting hung on a ledge.

 

In the past I would increment the current point index and/or remove points from the head of the list, but what I don't like about that is that it is destructive to the path points in a way that removes information useful if the A.I. needs to get back on the path. Maybe he was blown out of a navmesh region, or got hung on something or whatever. Since the path alteration is destructive errors often manifest as guys running into walls seeking to a point because they didn't fully get around the last corner vertex and got hung up.

 

Curious how others avoid this issue and/or maintain their path following such that it can recover and reliably follow the path. In many ways the path following part has proved more difficult for me than implementing the navmesh itself.

0

Share this post


Link to post
Share on other sites
Disclaimer: I don't have much experience with path following (it was pretty trivial in the cases where I've done it).

Instead of dumbly going straight to the target node, you can use steering behaviors to tend to go towards that position but avoiding obstacles.

Another idea is to change your target node when you are within a certain radius of the current one and you have a line of sight to the next one.

Some combination of those two ideas should get rid of most of the problematic cases, if not all.
0

Share this post


Link to post
Share on other sites

Disclaimer: Neither do I have much practical experience doing path following in more complex scenarios.

 

 

Instead of dumbly going straight to the target node, you can use steering behaviors to tend to go towards that position but avoiding obstacles.

 

 

I think this approach can fall short when the agent has been pushed off his course far enough to end up behind a wall whereas his target position resides exactly on the opposite side of that wall -> steering forces would eventually cancel out each other. And worse: he could then start sliding himself into a dead-end while still trying to reach the target position and avoiding that wall.

 

Here's what I would try to experiement with: apply a slightly modified Funnel algorithm on a more local basis while moving. You could pass in the target point where your agent intends to steer towards to, then let the algorithm figure out a point that lies withing a valid funnel. If the figured-out point happens to be your target point, just steer straight towards it as your agent won't go off the navmesh. Otherwise, scale the direction from your agent to that point by some amont representing your intended steering force, and move towards that point. Repeat while moving.

 

Does that make sense?

 

 

--

Shadax

Edited by Shadax
0

Share this post


Link to post
Share on other sites

I have two solutions. Both of them rely on treating the path not as a path per-se but as a trajectory. What you want is for your agent to move such that at each point in time, the agent is close to the path, and his velocity is along the path. So, you've got to add another dimension to your path: time. You can turn your static path into a function that says "where should I be at time t?" the agent then tries to get to the point "where he should be". This is called a trajectory.

 

The easy solution:

  • Take the entire trajectory as a single curve paramaterized by time t between 0 and 1. Create a function which goes from [0,1] to a 3D point f(t).
  • The agent starts at t = 0. He seeks the point f(t) until he's within a radius (called the blend radius).
  • t then advances by a small amount.

That's it! 

 

The better solution:

  • Start again with a trajectory paramaterized by a single number between 0 and 1.
  • Find t_x such that the distance between the agent and the trajectory is minimized. (If you trajectory is piecewise linear, this involves projecting to the nearest line)
  • Seek the point  f(t_x + e)  where e is a small number representing the "lookahead time". e can be larger the further away the agent is from the trajectory.

I also have source code and a graphical example for the second solution:

http://www.openprocessing.org/sketch/96006

Edited by mklingen
0

Share this post


Link to post
Share on other sites
If you use some sort of 'in radius' check it can sometimes cause guys to abandon a point early and seek to the next point where they haven't cleared a corner for instance, and may get caught on the corner. In nav meshes in particular, paths around corners tend to hug the wall as closely as possible, whether due to string pulling or whatever, so incrementing the seek point needs to do so in a reliable way so as to recover from getting hung on a ledge.

If your mobile guy entities are approximately the same size, it could be possible to offset the navigation mesh away from obstacles by a little more than the radius of the moving guy enties. It's a sort of baked-in method, like the way they did it in Fallout 3.

0

Share this post


Link to post
Share on other sites

Even with an extruded nav mesh this problem arises due to the navigation and collision differences.

 

I've put together a reasonable I think implementation that seems to address the question and a number of other issues.

 

When I pathfind through my navmesh, I ultimately get back a list of edges that may be portal edges, which are the crossing segments between sectors, or if it doesn't point to a portal, it uses the position, which is what the start and destination will show up as. The edge also has a pointer to the sector it belongs to, and a copy of the 'version' of the sector that was used to generate the path.

 

Basically what I do each frame is when I update what navmesh area the guy is in, I update his current sector, and iterate the edges to update what edge index corresponds to the current sector the guy is in. This allows me to maintain the entire result path without destructively culling points as they are reached and such. This means that getting blown back into a previous sector will not require a repath, getting blown ahead in the path doesn't require a repath, etc. Also during this loop I check to see if the sector versions have changed from the sector version number that the path was built with, and replan the path, as that means the sector has been rebuilt due to temporary obstacle baking or other such change that affects pathing. If I get through the edge list and don't find an edge pointing to the current sector, that means the guy is 'off path' so again there I re-path.

 

So far it seems to work well. Having the path be non destructive also helps debugging, as I don't lose the context of the entire path of the AI if they are in the middle of following it.

 

I'll post a vid later if anyone is interested.

0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0