PathEngine home previous: Advancing Along Pathsnext: Using PathEngine with Multithreaded Applications
Contents, Programmers Guide, Applying the SDK, Group Movement

Group Movement

PathEngine doesn't include a built-in group movement framework, or manager, but instead aims to provide a solid base against which group movement code can be implemented in a number of different ways, depending on the specific higher level requirements of a given application.

In particular, PathEngine's dynamic obstacle and collision context management functionality is useful for selective treatment of agents as obstacles, depending on agent state, and local collision queries are very useful for local interactions between moving agents (such as checking proximity, or predicting collision).

Choosing what kind of collision constraints to apply

An important choice, when building an architecture for managing group movement within an application, is the type of collision constraint that will be applied between moving agents. This is something that should be considered very carefully based on the requirements and also the implications of the choice!

A 'hard' collision constraint means that agents are not permitted to overlap each other at all.
This kind of constraint may be desired when high visual quality of interactions between agents is an important requirement, but this is something that is very difficult to resolve correctly in all situations, and in the general case.
When choosing this kind of collision constraint, then, it can be quite important to make plans for situations where agents block each other or are prevented by other agents from reaching a target.

'Softer' collision constraints allow agents to overlap in certain situations, or minimise cases in which agents overlap one another, and can make it easier to avoid situations with blocking and problems with continuity (e.g. for character animation).
(Because of this, we generally recommend this kind of collision constraint even for situations where high visual quality of interactions is desired.)

Ignoring collision between agents completely may be acceptable in some cases, and if so then this can potentially simplify many aspects of agent movement management very significantly!

General approaches, and example projects

Note that agents which are currently in movement should generally not be included as obstacles for pathfinding queries by other agents (because moving agent positions will have changed by the time pathfinding agents arrive), but tracking a set of agents that are at rest, and applying this set of agents to selected queries, can be a good basis for managing group movement.

Local collision queries then provide a fast way to get information about nearby agents, during movement along a path, which can then be used for 'flocking' style local reactive avoidance behaviours, or for RVO (reciprocal velocity obstacle) style velocity resolution techniques, and local paths can then also be generated directly by 'generate and test' approaches, based on these local collision tests.

Some example projects are provided to demonstrate some ways to implement group movement and interactions within PathEngine:

Documentation for PathEngine release 6.00 - Copyright © 2002-2016 PathEnginenext: Using PathEngine with Multithreaded Applications