Apex Path Q&A

We have made a few simple performance test runs on different devices, read more.
Performance has been a key focus in the implementation, both cpu cycles and memory allocation. The only real ‘benchmark’ we have is on a mid range pc, where 256 agents wander about avoiding dynamic obstacles falling from the sky. The combined impact of path finding and steering peaks at 4 ms per frame, with an average of 2 ms.
Apex path have basic steering behaviors included steer for path and a few local avoidance behaviors.
All you need to do, to add a steering behavior, is to derive it from our SteeringComponent class and implement one method to return the steering vector. If you wish you can also completely ignore the built-in steering and simply use the path finder.

Here is an example of a follow steering behavior that shows how to inherit from the SteeringComponent class.

Here is a compacted example of how to get a unit to move.

Just add the Unit on Patrol quick-start to the unit’s GameObject.
Apex Path currently does not support pathfinding in the XY plane, but we are considering this for a future product.
It is hard to completely avoid memory allocations, but it has been a focus of ours throughout the development to limit it to the bare minimum, to keep the GC idle.
Apex Path does not have Point Graphs, what we have is a grid based solution. The uniformness of the grid offers a number of advantages over the Nav Mesh or Point Graphs, dynamic obstacles and good AI integration to name the top two.

So in the end it comes down to what solution best matches your game.

We operate with three kinds of obstacles. The first two are static obstacles which are specifically marked as obstacles or natural obstacles (also static) which are defined by the height map settings. These types will only block the cells that they actually cover, i.e. they do not use the bounding box.

These obstacles are the ones involved in dynamic creation / destruction of level geometry.

The Dynamic obstacles implementation that comes with Apex Path does use the bounding box.

The Advanced Dynamic Obstacles Add-on adds support for arbitrary convex obstacles at any orientation.

Apex Path does not currently have this function, but it has been added to the feature list for upcoming releases.
We do support multiple floors, each floor simply has its own grid. Grids will then need to be connected using portals, i.e. explicit connections, so a stairwell going from one floor to the next will not automatically be a connection.
Dynamic Obstacles are designed with efficient pathfinding in mind, and is related to changing geometry or dynamically moving objects in the game world. You can of course use some of the functions for AI and general perception. However, it is not designed as such. Perception for intelligent beings in the gameworld is a part of the Steering and AI packages from Apex.
Apex Path uses a messagebus (Event Aggregator is also a common name for it). This allows a component to send out messages, and other units to receive these messages, without even knowing about each other.

There is a whole section in the Extensibility Manual that explains in more detail about the two message bus types.

An example of how you would subscribe to messages regarding unit navigation is as follows.

In this example the class derives from ExtendedMonoBehaviour instead of MonoBehaviour, the reason being the method OnStartAndEnable. This avoids the ‘who loads first’ race condition.

As there could be many different ways of implement follow behavior, care should be taken to describe exactly what type of following is relevant for the specific game. A simple behavior could look something like this:

If you only want to adjust animations based on character speed and orientation, you can use the Humanoid speed component’s speed index to control your animations. If you have non-humanoids you can write your own speed component to control it in a similar way.

If you want your animations to do the actual movement, you can easily replace the default means of locomotion with your own, it’s simply a matter of implementing a small interface.

All units that move along a path have a destination property, so its a simple matter of iterating over the units and checking if the destination conflicts with what you are about to do.

Mind you, if you need to know whether an object will block a unit’s path somewhere between now and its destination, that would require a little more work, iterating over the unit’s path. But all the data is available.

Perception is not a part of Apex Path since it is not related to pathfinding. Perception is a part of the Apex Steer and Apex Utility AI packages.
Yes. Apex Path is designed for fully dynamic and destructible worlds.
No. Spherical terrain is a challenge since it is hard to mathematically wrap a grid around a sphere.
There are two ways in which you can control movement. One is to define and control speed settings, doing this allows to control how fast a unit is moving and can also be used to control the animations of a unit. The second is the actual movement of the unit, commonly referred to as locomotion.

You can easily implement your own locomotion, and we have an example on how to do this included in the package.

You can define a maximum height that a unit can step onto, which will override any slope limitations. So yes even though the slope of individual steps on a set of stairs is vertical units can still navigate up and down stairs.
We don’t recommend such large grids, as especially creating heightmaps uses many raycasts to be generated and you will need to keep the entire map in memory.
Apart from the features directly related to path finding, for which you can find a comparison chart here http://apexgametools.com/products/apex-path/, there are a number of additional features, such as Attributes, Load Balancing, Messaging and more.
Yes. Apex Path does support dynamically changing geometry. The bookshelf would not be marked as an obstacle but rather as terrain. It would then be inaccessible when upright, but once toppled over it would be walkable.

This is not an automatic thing however, you need to tell the grid to update its height settings for the affected area, which is a simple matter of calling a method (Update(Bounds extent)) on the grid.

As an alternative you could also let it start out as a static obstacle and once toppled over change it to terrain (change its layer), and then call the grid update. Come to think about it, the latter is probably the better of the two when looking at general grid performance.

To use your own steering you simply need to implement the INeedPath interface and issue a path request:

Once the request completes it will call back through the INeedPath interface with the result, part of which is the path.

Alternatively, there is another way to request a path which may be simpler for many use-cases. A CallbackPathRequest can be issued, which takes a callback method to invoke once the path request is completed.

The third option is to use the built in steering, but override locomotion, i.e. how the unit is moved. To do this you simply implement the interface IMoveUnits on a MonoBehaviour and attach that to your unit. This allows you to pass on the movement vector to the animation.

The examples project also has a simple example of this locomotion override, called ‘CharacterControllerMover’, although it is not related to using the animations to move.

The turn speed logic is different from the move speed logic, in that it is left up to those that request a certain facing direction to also control at which speed the turn is made.

By default there is only one component that requests the unit to turn, the Steerable Unit Component. It has a Turn Speed property that can be set to whatever you want.

You can however also choose to implement IProvideFacingOrientation and override the facing orientation of the unit to do whatever you want instead of just facing the direction of movement.

There is an example class FixationPoint in the Apex ExamplesScriptsMisc folder (in the examples project).

Yes using portals this would be possible, i.e. define each side of each grid as a portal to the next. You would need to create a null action that does nothing, which should make the unit just walk the distance between the portals.

However beware that one of the reasons to use multiple grids is to reduce the time needed to find a path, if using portals path finding will take longer as it will process the entire path in one go.

Apex Path does not include crowd steering behaviors, nor flow field support. These features can be found in the Apex Steer product.
You can connect various sections of a grid or one grid with another using portals. Portals can be set up do whatever you please, e.g. climb a ladder, jump a certain distance, etc., however you will have to implement this logic yourself.
Yes on the grid you will find a method called GetNearestWalkableCell, which will give you what you seek. Although walkable means that the cell itself is not blocked, it does not ensure that a path exists to that particular cell.