Is coding using PPP v4 API easier than it was in v3?


So, I’m making a game where agents wander around most of the time and do stuff on their own. February 2016 I bought the Pro version v3, because I was put off by any other pf-solution (Apex, Unity’s NMesh). But as the programming noob I (still) am, even PPP was too difficult to handle for me.

So, my question is:

In PPP version 4, if I simply want to move an AI CharacterController along a path, how many lines of code are required? Do I still need to iterate through the path and make the object move and rotate waypoint by waypoint, or is there an equivalent of Unity’s “NavMeshAgent.destination” which needs to be set and that’s it? Or is this the same API as in v3 with a bunch of new features?

Another question: Is the following still a valid way to get a random path within a grid using PPP v4?

public void StartRandomPath()
    List<GraphNode> gn = PathUtilities.GetReachableNodes(;

    _path = _seeker.StartPath(transform.position, (Vector3)gn[Random.Range(0, gn.Count)].position);

Because I’m pretty much relying on this method when it comes to wander behaviour.

Thanks for any clarification!

I’m not sure what “PPP” is… Unless you mean PFP (Pathfinding Project).

However, this system doesn’t actually move the characters. It just generates a path.

You’d still need the code to traverse the path given, much like in v3 (atleast to my knowledge).


The movement scripts have been improved in v4, however the largest improvements have not been released yet.
Soon-ish I am going to release an update that adds a ton of useful things to the AIPath/RichAI movement script and also unifies them with a single interface.
This interface is designed to be similar to what Unity’s NavmeshAgent uses to make it easy to get started with if you have used Unity’s navmesh system previously. In particular it does include a ‘destination’ property which works similarly to how it works in Unity’s navmesh system.

With this update I will also be including some simple behavior scripts as a lot of people have requested this. For example I have a patrol scripts that just makes the character patrol between a number of fixed points and that script contains in total 21 lines of code (including ‘using’ declarations and class definitions etc.). There are 8 lines of code that actually does stuff.[quote=“HansHeinrichHohlkopf, post:1, topic:4020”]
Another question: Is the following still a valid way to get a random path within a grid using PPP v4?

Yes, that looks like perfectly valid code. I have tried to keep pretty much everything compatible. You might get warnings about some other code that is obsolete, but in general almost all code will continue to work as in 3.x.

There are some included movement scripts that you can use. For many games you will want to write your own movement scripts, but many games can just use the included ones.

Here is the interface (with abbreviated documentation to make it easier to read):
(let me know if you have any comments on it, or what things you wish it had)

/** Common interface for all movement scripts in the A* Pathfinding Project. */
public interface IAstarAI {
	/** Max speed in world units per second */
	float speed { get; set; }

	/** Actual velocity that the agent is moving with */
	Vector3 velocity { get; }

	/** Velocity that this agent wants to move with */
	Vector3 desiredVelocity { get; }

	/** Remaining distance along the current path to the #destination. */
	float remainingDistance { get; }

	/** True if the agent has reached the end of the current path */
	bool targetReached { get; }

	/** Position in the world that this agent should move to. */
	Vector3 destination { get; set; }

	/** True if this agent currently has a path that it follows */
	bool hasPath { get; }

	/** True if a path is currently being calculated */
	bool pathPending { get; }

	/** Gets or sets if the agent should stop moving. */
	bool isStopped { get; set; }

	/** Point on the path which the agent is currently moving towards. */
	Vector3 steeringTarget { get; }

	/** Force the current path to be recalculated. */
	void SearchPath ();

	/** Instantly move the agent to a new position. */
	void Teleport (Vector3 newPosition);

	/** Calculate all movement for a single movement step and move the character. */
	void MovementUpdate (float deltaTime, bool useGravity);

Wow, that interface looks very promising! Will it work similar to Unity’s NavMeshAgent then?:

Seeker seeker;

void Start()
    seeker = GetComponent<Seeker>();

void Update()
    seeker.destination = position;

If it’s going to become THAT simple, I’ll be happy to grab the upgrade. You’d do a huge leap past any other pathfinding solution in terms of “plug and play”-ability.

Though I’m curious, how are you going to handle the different kind of “movement approaches” (CharacterController, Rigidbody, Mecanim)? Will the agent automatically know what to do depending on what Component it has attached?


Almost. The Seeker doesn’t do any movement but the AIPath movement script does it. So if you just replace Seeker with AIPath in that code it will work (after the update).
That particular example isn’t that different from what you can do now however (which works even in 3.x):

AIPath ai

void Start() {
    ai = GetComponent<AIPath>();

void Update() { = position;

The AIPath movement script has support for using CharacterController, Rigidbody, Rigidbody2D and the Transform component. It will automatically detect whatever components are attached. It does not automatically handle Mecanim because there is no “correct” way to do that, every game does it differently. In the Update I will include a simple example script which uses Mecanim however. You can just attach it to the same GameObject as the AIPath script and it will work.
Here is a preview video of that (not the best movement, but it’s ok):

1 Like

Oh my, I never fiddled around enough, to realize that you can use AIPath like that. I’ll try it out this evening.

The mecanim controller looks great! And it seems to be RVO-ready. Can’t wait for the release!

Looking forward to that update, just ran into a situation where mecanim’s turning with root motion somewhat fights for control, and I wasnt really sure how to go about solving it, but that looks like it is just what I needed.


I have released a beta now with these changes.
I could not release the Mecanim example however because I do not have a set of animations that I can include in a commercial package yet. The controller script is there though (it is called MecanimBridge).

Thanks! I updated to v4 now and the Bridge you mentioned does save a lot of work. Thank you so much! But still, there seems to be a little problem. This Mecanim helper script seems to target a very specific 2D Cartesian setup inside the walk blendtree.
No matter how I set it up, the character walks extremly slow towards the destination and the closer it gets to the end point, the slower it becomes.

Do you happen to have a screenshot of the walk blendtree setup from your preview example?

Here is a screenshot of the blend node. It is just 8 animations of the character walking in different directions.

You probably just want to scale up the X,Y mecanim input so that it fits your animations.

Thanks, but where and how do I scale the X, Y input up? Somewhere in the bridge script?

Check these 2 lines

anim.SetFloat("X", smoothedVelocity.x * insertSomeScaleHere);
anim.SetFloat("Y", smoothedVelocity.z * insertSomeScaleHere);

Yes, that solved it. Thank you!