How do you do AI path following within a 2d physics engine like farseer/box2d?

Question

I'm in the process of moving a 2d top down game I've been working on into a proper rigid body physics engine like Farseer. Up until now, I had just hacked together my own physics code where needed.

I'm trying to learn the proper way of doing things here.

What is the proper way to make your AI follow a set path once you have made them rigid bodies inside of the physics engine?

If I have a path of navigation nodes on my map that I need the AI to follow, previously I would just move them along the path manually by calculating the next position they should be at for the next time step and manually setting them to that position.

But now they are rigid bodies and subject to collisions and any forces that may hit them and knock them off path.

So to make the AI move I believe I should now be applying impulses/forces to them? I should no longer be manually setting their position each frame.

So I think I need to go from a deterministic world where I force the AI to strictly follow a path to a non-deterministic world where they could get knocked about in any direction if hit and I simply nudge them towards the next node in the path to make them move.

Is that right? Is that how other people do it?

This raises some questions about how to then avoid your AI getting stuck on corners of scenery now that they aren't walking a precise path, how do you guys handle that type of thing?

Or is it better to somehow mix the two and still have your AI follow a fixed path by setting their position manually, and only react to other forces under certain circumstances you can easily control?

Thanks for any advice guys.

Answer 1

Steering behaviors work very well in combination with a physics-engine, as they are usually implemented in a way that they return a "steering force" which can then be applied to your physics-body.

To make a unit follow a path, you could use Seek to go from path-node to path-node (make sure to avoid overshoot) and then use Arrival at the last node in your path.

As for your concerns about getting stuck: Modelling the path-following using forces should actually be quite accurate. You're right that an object might get thrown off the path if it collides with another object, but since you'll calculate a steering-force in every update, the object should be on track again in no time. If the deviation from the path after a collision can potentially be huge, then I suggest you remember your last position whenever a collision occurs and then steer the object back to that last position before continuing the normal route.

Answer 2

Judging by what @davidluzgouveia commented on annonymously's post, I'll bring up my project. Path following and path finding are very different though. Path finding is more of what annonymously was posting about, and for path finding I would look into Dijkstra's algorithm. For path following I use my choice physics engine entirely. The way I have it set up is that each location a unit class walks to, is set up in it's pathing subclass via 2D offsets, yes they are 2D and not 3D this is because of the way I have my physics set up in my game.

3D explaination: Each unit has only one main collider that is exclusively set up for collision with the terrain and world objects. It's a capsule shape and has a radius, and height programatically speaking. It's built at the center of the model and should extend just past the front and top of the model. But I also have a surface offset for how far it is off the ground at all times, and a float of how much it's allowed to slide down before bouncing up slightly, at a time. This sounds like I'm applying some sort of screwed up fix for a terrain collision problem, but I have my reasons.

Anyways, you should apply force to this capsule object, and it should remain hovering above the ground at all times. That's not to say it can't go any higher, just that it can't go any lower. The reason why it needs to hover (in my case) is because in a rigid body and ragdoll physics engine, the legs of my units are procedurally animated. So by applying a simple force to the capsule, the legs of my entity will reposition themselves on their own. They will also have their separate gravity applications! What this does is allows that if my character is on a slant, one foot can be at a lower elevation than the other.

This is exactly how you should do it. Judging by what you're asking that is. If you want to leave out some features, that's obviously fine, especially if it's an RTS or FPS and no one will ever see units feet or care anyways. But in general, the unit should have one MAIN collision object that works with movement of the character almost exclusively.

Specifically 2D: You still should have a main point, or just some sort of reference, for the engine to push around that is for the movement of a unit. You could give each unit a pathing subclass that has a few locations it needs to go, you could specify it in the level code, (e.g. location1(x,y) location2(x,y) etc.) the best way (I don't know what kind of game you're working on) would probably be to specify locations in the level and have that each unit will process them in order specified by the level and after it reaches each location, have it replace it's desired location with the next one it needs to get to.

There are tons of ways you could modify that, like having a list of locations in the first place for each unit, since this would mean not all units have to go to the same locations. However, as the same way, you could do this in the level code as well ( unit1.location1(x,y) unit1.location2(x,y) grunt.l1(x,y) knight.loc3(x,y) whatever)

Just a few ideas! I suggest you read the 3D version even though it's far less relevant.

EDIT: I decided to just supply both for anyone who might read this (Yea that's true).... (I originally only skimmed your question and didn't realize it was pretty 2D specific till I reread it >.>)

Answer 3

I'd say you're on the right track, you might want to look at this article.

It explains some basic collision avoidance and path-finding using the A* algorithm.

Edit:

If you really only need what the best way of propelling your objects in the right direction is, then you should use a force (say, MovementForce or something) pointing in the direction of the best path you found using the path-finding algorithm of your choice