Apex Path v2.0 [RELEASED] - High Performance, Easy to use dynamic Pathfinding

Apex Path is a high performance, easy to use dynamic pathfinding solution developed by Apex Game Tools.








Advanced Dynamic Pathfinding
Support changes in level geometry at runtime. Doors can open and close. Walls can be destroyed. Buildings can be added and removed. Objects can fall and block corridors. Platforms can move. All changes are reflected in the pathfinding and agents automatically update their paths at runtime.


Highly Optimized, tuned for performance
The packed support multithreading and to ensure a steady frame rate in complex scenes it also comes with it’s own load balancer. Over 1,000 agents have been supported on a standard desktop PC.


Extensive documentation
Despite the advanced technology, Apex Path is very easy to use and work with, the API is fully documented and supported with an array of both written and video tutorials, examples on how to implement common game functionality.

[VIDEO UPDATED] The new video shows the same scene as before but now includes basic avoidance to steering!

You can find all the details, documentation etc. on our web site
Support forum http://apexgametools.com/forums/

Link to the: Asset Store

Apex Path Example Scenes
Apex Path Example scene Basic Navigation

Apex Path Example scene Performance

You can find all our video example scenes at our website http://apexgametools.com/apex-path-examples/

Tutorials
Apex Path Tutorial Getting Started

Apex Path Tutorial Game World

You can find all our video tutorials at our website http://apexgametools.com/tutorials/apex-path-tutorials/

Apex Path version 2.0
Apex Path 2.0 contains lot's of improvements, new features, even better performance, bug fixes and Unity 5.0 support.

Changelog: Apex Path v 2.0 feature update.

New Features:

• A new Upgrade Scene menu item is available, which will upgrade scenes made with older versions of Apex Path to this version, adding and replacing components.
• Unit interaction is now done through a IUnitFacade, please watch the tutorial videos for details.
• Added a UnitsSelectedMessage, which will be posted when units are selected.
• The height navigation options are now set per scene or per unit instead of per grid, through the new Navigation Settings component available on the Game World.
• Height sampling and navigation now provides 4 options. Generating and using a height map or no height at all are still present.
• New are ray cast and sphere cast. Both new options do not generate a height map and hence take no memory for this, instead they do real time height sampling.
• Grouping of units via selection or otherwise has changed completely, see the tutorial videos for details.
• All Apex Components are now consolidated by the Component Master, to reduce component clutter.
• Unity 5.0 support.

Improvements:

• The ZeroHeightMap now returns negative infinity instead of pos.y when sampling a position, since a zero height map represents no height.
• Moved various path finder settings to its own component which is shared among those that use it.
• Grids now have an option to select the method used to detect terrain and obstacles, this is mainly due to a Unity bug where the default CheckCapsule will fail in certain scenarios.
• All registered units in a scene can be retrieved via the GameStateManager (through GameServices)
• Various extension to existing data structures and a couple of new ones
• Numerous tweaks to existing components.

Breaking changes:

• Steering has changed completely, watch the tutorial videos for details.
• The INeedPath interface now only requires a single method to be implemented. All unit related data is passed to the request by way of the 'requesterProperties'.
• The CallbackPathRequest constructor no longer requires unit data such as radius and attributes, these are contained in the new required 'requesterProperties' property.
• The path finder options of a path request are now consolidated in the pathFinderOptions property
• Removed the speed index property from the HumanoidSpeedComponent since it is not an optimal way to control animations as it does not reflect the actual speed of a unit.
• Off Grid Navigation is no longer an option since it works poorly with groups and is just generally not useful.

Bug Fixes:

• Fixed yet another bug with WP8 and WinRT.

Important: Due to folder structure changes you must remove the old version of Apex Path before importing this update.


v1.2.5
Improvements:

• Added patch functionality to the Products window so that minor fixes such as this can be applied without having to download a new package manually.

Bug Fixes:

• 
  
  
  • Fixed a bug with the Grid that was caused by the new Portal Editor.
  • Fixed the Portal Editor so portals can now be properly drawn on elevated terrain.

v1.2.4
Improvements:

• Replaced the AsyncFailed event of the Path Finder Service with a callback to fix a problem with AOT compilation.
• Portals editor has been changed, which should hopefully make it easier to set up portals.
• Portals can now be either one- or two-way.
• Prepared for Advanced Dynamic Obstacles release
• The max constraint on Obstacle Sensitivity on the Grid has been removed. This may lead to some funky behaviour if set to an unreasonably high value.
• The original constraint is still applied when processing height settings for cells.

Bug Fixes:

• Again a few win8 specific errors had crept in, they are now fixed.

v 1.2.3
New Features:

• Obstacle Sensitivity Range is now in effect for Dynamic Obstacles similar to static obstacles. Options exists to use the Grid's setting or a custom one.
• Added a simple utility to create and edit an Attribute set.
• Added a marshaller that allows marshalling actions from another thread onto the main thread. This is now used by the CallbackPathRequest, hence callbacks will now be made on the main thread.
• Added automatic update checking and a Products window for Apex products to give an overview of installed / available packages.
• The grid component now has an 'offset' property when 'Link Origin to Transform' is checked. This allows the grid to be offset some amount in relation to its transform.

Breaking Changes:

• ISteerable has been deprecated and merged into IMovable. The distinction between these two really caused more confusion than clarity.
• The currentDestination property on IMovable has been deprecated and is now called nextNodePosition instead. The property has always returned the location of the next node along the path being travelled, but its name suggested otherwise.
  It is now also a nullable Vector3 instead of an IPositioned, to align it with the finalDestination property.
• RectangleXZ is now a struct.

Improvements:

• Dynamic Obstacle performance improved by approximately 400%.
• The PathResult's properties are now writable so that result processors can change them.
• The Grid Field tool has moved to the Tools menu.
• The UnitNavigationEventMessage NodeReached event is now raised after the next node has been resolved, so that nextNodePosition will return the expected next node rather than the one already reported as reached.
• The path service now exposes a property that makes changing the cost provider to use easier than before.
• Portals now have an option to be treated relative to their transform, i.e. the end points will use local space. This means portals can work properly in prefabs.
• The 'currentPath' property of the IMovable is now of type Path instead of the previous less helpful IIterable<IPositioned>
• The grid visualizer will now update if the transform, on which the grid resides, is moved.
• Minimum required Unity version to download from the Asset Store is now 4.3 instead of 4.5
• Improved a few component editors.

Bug Fixes:

• Corrected a multithreading issue involving dynamic obstacles with frequent updates.
• Corrected a few labels on attributed components in the Unity editor.
• Fixed the PortalActionTeleportComponent, it was teleporting units into the terrain.
• Fixed a bug where runtime initialization of a grid with a portal already on it would only partially initialize the portal.
• Fixed a bug where static obstacle detection would detect obstacles outside the boundaries on elevated terrain.
• Terrain checking will no longer fail to detect terrain at the joint points of terrain pieces.
• Fixed a bug with the Navigating Unit with Selection quick start in Win8 / WP8 apps when a custom input receiver is defined.
• Fixed a bug with manually initialized grids, where loaded at runtime and moved to position before initialization would not move the grid accordingly.

v 1.2.2 Patch 2 / Minor feature release

New Features:

• ISteerable now has a finalDestination property
• A new request type CallbackPathRequest was added. This allows for interaction with the path finder without having to implement INeedPath
• All request types now have a 'type' property. Currently two types are available, Normal and IntelOnly, the latter being an optimization for AI use.
• SteerForPathComponent now implements IInjectPathFinderOptions which allows for having custom requests injected with the path finder options assigned to a unit
• Path results now include a 'pathCost' property which represents the length of the path and the cost of its individual nodes.
• Paths are now represented by the Path class. It derives from the StackWithLookAhead and thusly is not a breaking change. It is simply more clear and adds some additional possibilities, e.g IMovable.MoveAlong(...).
• A SimpleQueue was added to data structures
• A new Example scene 'Item Pickup' was added, showing some of the new features.

Breaking Changes:

• RepetableAction is now correctly named RepeatableAction. Simply search and replace.
• The ManualPath and the matching IMovable.MoveAlong method felt clumsy and have been deprecated. Instead use the new Path class and the matching IMovable.MoveAlong methods.
• Cleaned up the IPathService interface to only expose methods intended for use outside the framework. Not likely to affect you.
• Cleaned up the IPathRequest and its implementation. Not likely to affect you.

Improvements:

• StackWithLookAhead now has an indexer and implements IIndexable
• The currentPath and currentWaypoints properties of ISteerable are now indexable
• Connector portals now produce smoother paths (even more so than 1.2.1)
• Shortcut portals covering multiple cells will now correctly choose entry and exits points that result in the shortest path.
• IUnit now also implements IHaveAttributes

Bug Fixes:

• Windows Store App and WP8 Apps no longer throw exceptions on compilation, for real this time.
• Fixed a nasty bug where units would increase their speed in certain scenarios, especially obvious when issuing manual paths.
• Two examples that broke in patch 1 are now back in operation.
• The path finder and path smoother, now properly respects the custom cost of individual grid cells.

v 1.2.1 Patch 1 Released

New Features:

• The GridManager now has methods to get references to GridComponents given a position or bounds struct.
• A new message 'GridStatusMessage' is sent when grids do runtime initialization or are disabled.
• New factory methods enable runtime instantiation of grids and portals
• The GetCell method on IGrid now has an overload that allows to adjust the position to the grid bounds, i.e. find the closest cell on the grid if the position is outside the grid.

Breaking Changes:

• The Disable method on the GridComponent now requires an argument specifying the maximum milliseconds to use per frame. This is related to the changes/fixes below.
• IMoveCost signature changed. Unlikely to affect anyone, but a breaking change nonetheless.
• IPortalAction's GetActionCost now takes a IMoveCost argument to allow for better cost calculations.

Bug Fixes:

• Windows Store App and WP8 Apps no longer throw exceptions on compilation.
• The editor for attributed components no longer fails if no attribute set is defined.
• Portals now respond to grids being initialized / disabled at runtime and no longer cause exceptions when placed on grids where automatic initialization is turned off.
• Dynamic obstacles now have an option to support dynamic grids, i.e. initialization / disabling at runtime. Set this to true if you initialize / disable grids at runtime.
• The callback argument in the Initialize method on the GridComponent can now be null if you don't require a callback.
• Basic avoidance will no longer throw an exception if a unit being avoided, is destroyed

Improvements:

• The 'Navigate to Nearest if Blocked' setting now also applies to actual blocked cells.
• Changed the Mac Support of the default input receiver. It now has a 'Right Click Supported' property instead. If your Mac is not set up for right click support, uncheck that option.
• Grids not set to automatic initialization are now drawn semi transparent.
• Movement across stitched together grids is now smoother.

Known issue: The dynamic obstacles in the wander performance example scene do not block as they should.
This is due to them being spawned outside the grid. If you wish to fix this, you can simply set the grid's upper boundary to 30 instead of 10.


Apex Path version 1.2 contains lot's of improvements, new features, even better performance and some bug fixes.

changelog: Apex Path v 1.2 feature update.
New Features:

• The Grid visualizer will now perform far better. It will now only draw the grid when within a configurable zoom level.
• Portals now come in two flavors, shortcuts and connectors. Shortcuts are portals such as teleporters that could provide a shortcut to the unit, while connectors simply connect with each other without being seen as shortcuts.The difference is that shortcut portals have a rather heavy cost with regards to path finding, whereas connectors have no cost. A video explaining this will be released soon.
• Added a Stop method to the IMovingObject interface.
• Cell size is now a float.
• The IMovable interface now has a MoveAlong(path) method which can be used to feed a path directly to the unit.
• The cell's isPermanentlyBlocked property is now public.
• The patrol behavior now has an option to visit patrol points at random.
• The default input receiver now also works on Mac. You should still replace it with your own though.
• The CharacterControllerMover is now included by default and will be used automatically for locomotion of units with a CharacterController.The example class is still there as a reference for overriding locomotion.
• The cut corners setting on the Path Service has moved to the Steer for Path component to allow per unit basis settings of this value.
• New option to prevent off-grid navigation, this will force unit to move only on grids and they will only be able to move between grids using connector portals.
• New option to make units move to the closest possible location if the actual destination is blocked or otherwise inaccessible.
• New option to send out an announcement for every node reached along a path.
• First iteration on improving the Inspector editors for the various components. This have caused some properties to appear in a different order than before.
• Added a tool window under the Windows menu. Apex Path - Grid Field will allow for easy creating of a field consisting of multiple stitched together grids.

Breaking Changes:

• The 'Use Path Smooting' property on the Steer for Path component had its typo corrected to 'Use Path Smoothing'.So if you disabled path smoothing, you will have to do so again, sorry.
• The enum SlowingAlgortim and the Steer for Path property Slowing Algoritm also had their typos fixed, so if you made changes here, you will have to do them again, sorry.

Bug Fixes:

• Selecting units at various heights should now work properly.
• Adding a portal now properly places it in relation to its game object.
• The path visualizer no longer incorrectly shows an extra intermittent node in connection with portals.
• A number of minor bugs.

Delayed improvements:

• We wanted to improve the memory footprint of the grid height map. This proved to be a tougher challenge than initially assumed, so we have delayed that to a later update.

Apex Path 1.1 patch 1 RELEASED

New Features:
- Option to disallow diagonal movement added to the SteerForPath Component.
- IControlFacingOrientation now has an Unsubscribe method.

Bug fixes:
- MenuExtensions had escaped the editor folder, they are now back in the fold.
- The basic avoidance steering will no longer affect units with no velocity.


Apex Path 1.1 Released

[NEW] Basic Avoidance Steering
In addition to a number of minor improvements, and by popular request from the community we now have a basic implementation of avoidance steering included with Apex Path!


[NEW] Grid prefab’ing and late initialization
We have added new options for grid initialization to ensure spike free loading of grids at run time.

The updated version is available here Unity Asset Store


Full release notes

• v. 1.1 Minor feature update
  • Adds basic avoidance to steering. A new Quickstart will now add this to units.
  • Minor improvement to the replacement of input receivers, input receivers are now resolved by means of an attribute.
  • Improved configuration options when defining load balancers.
  • Streamlined facing orientation control to behave the same as locomotion with regards to overriding default behavior. This is a *Breaking* change.
  • Grid baked data can now be stored as an asset. This allows for prefab'ing baked grids.
  • Grids now have an option to disable automatic initialization, and instead an Initialize method must be called manually. This Initialize method does its work smoothly over several frames.
  • Grids can now be disabled to release all memory used, but calling Disable().
  • The dynamic update time limit on grids has been removed and instead must be supplied in the call to perform a dynamic update.
  • Baked grids can now be re-baked without first having to press 'Edit'.
  • SteerableUnitComponent now has a setting to control the minimum speed at which units turn.
• Bug fixes:
  • Game services are now properly initialized before other components.

Remember if you like what we are doing and like to get our updates you can always follow us on our social channels ;-)

The Apex Team
www.apexgametools.com

 

I am really curious about this. It has a lot of promises but I am skeptical because there are no reviews and my budget is limited. I bought 1 path finding asset and it is giving me a headache so I am in the market for a new one.

May I suggest putting in code tutorials (Unless there is some and I don't see it?) on your site so I get a feel for how I would be coding everything out in my AI?

 

Hi,
Did you bench your Asset on Mobile?

Cedric.

 

Hi twick
Thanks for your feedback I really appreciate it!

Regarding tutorials and getting started guides, have you looked at these pages:

• Apex Path Tutorials
• Apex Path Documentation
• Apex Path API

​

We are already working on video examples, tutorials and example scenes, but everything regarding the release etc. have just gone much faster than we where expecting or have hoped for, but that's all just a very good thing.

We also have the thread here and every one on the team is following and watching it closely, so if you have any question we'd love to answer them or just help out!

The Apex Team
www.apexgametools.com

 

I can tell you what i need. A pathfinding solution for an RTS game, where i have a physic based (with force) generic steering behavior for vehicles, soldiers, airplanes and so on. The generic steering should have a speed limit, an acceleration, max. steering angle, should have 'eyes' (lincasting the environment) and should have some avoidance maneuvers, slow down vehicles in curves and more.

The idea is, get a 3d vehicle, implement an controller for basic steering (steer right/left, move forward and backward), or use a static animated unit and put the physic based generic steering behavior over this, that allows me to simply move it on path.

 

Yes I did but I see no code examples. I see the API Document but its a bit confusing.

For example.. I have AI that can have many behaviors, all controlled from C# and coroutines. What I would like to see is a simple code sample showing how I would integrate/call the pathfinder and use smooth steering from within C#.

An advanced example would show how to get the nearest patrol route, navigate to the first patrol node, and continue on from there but this one isn't as important right now.

 

What Apex Path provides is exactly a path finding solution which is ready for you to plug in your own steering logic, locomotion and AI.
The foundation is in place, so 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.

The Apex Team
www.apexgametools.com

 

We have no benchmarks for devices, we may create some in the future.
I can however tell you that performance has been a key focus in the implementation, both cpu cycles and memory allocation. The only '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.

The Apex Team
www.apexgametools.com

 

So, what about dynamic waypoint? I love this opportunity offered by your 'competitor'.

 

We do have a good number of code examples in the example and tutorial project that is part of the Apex Path package.
Of course that does not help you in your decision making.

As mentioned there is the API documentation, but it is as all API documentation, a comprehensive reference to all classes and interfaces, and not a tutorial. So it is intended as a look-up.

So here is a compacted example of how to get a unit to move.

Code (CSharp):

1. var unit = this.As<IMovable>();
2. unit.MoveTo(somePosition, addAsWaypoint);

Of course you would not want to resolve the unit each time but rather do that on Awake or similar.

Regarding your example on patrol routes, it would be the responsibility of the AI to decide when to patrol and when to stop patrolling in order to do something more important.

Finding the nearest patrol route is trivial, simply enumerate the patrol routes in the scene and compare squared distances. We may even add a small helper for this in a future patch.
Making a unit start to patrol is also a simple matter, just add the PatrolBehaviour to the unit's GameObject.
Alternatively add it at design time and enable/disable it to start/stop patrolling.

You mention coroutines. Coroutines are definitely useful for a number of things, but they can also be troublesome if whatever logic is executed per yield takes a long time, e.g. evaluating AI behaviours.
Apex Path includes our load balancer, which can be used to schedule work, much like a coroutine but with full control over how much time is used per frame.

If you have additional questions, please feel free to ask.
I will soon start to post some code examples to the Showcase forum, starting with some of the ways to extend Apex Path, but suggestions for other topics are welcome as well.

The Apex Team
www.apexgametools.com

 

What about 2D grid based pathfinding where the grid data changes often?
Also, garbage / allocations? These are killer for us.

 

We do not have Point Graphs, what we have is a grid based solution. The uniformness (if that is a word) 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.
The Nav Mesh on the other hand has the advantage of supporting overlapping multi-level geometry.

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

The Apex Team
www.apexgametools.com

 

That's pretty much what I needed. I understand the actual decision to move to a patrol point is based on the AI. I already do this.

The prompt responses are awesome. I really appreciate it. There's a good chance I'll be picking this up today.

 

Hello,
I have a single question regarding Apex. Do diagonal obstacles properly update the grid based on their rotation, or just the world space bounding box is calculated?
Let me know if this wasn't clear enough

 

Well it depends on what you mean. In practice our grid is 2D on the x-z plane or rather the height element (y-axis) is optional. However if you refer to the new Unity 2D or 2D in the xy-plane, then I am afraid we do not currently support that.

When you say that grid data changes often, do you mean the grid itself, i.e. position and size, or do you mean level geometry and obstacles etc.?
If it is the latter you mean, then it is fully supported, and actually one of the main reasons we created this product.

With regards to allocations. 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.

The Apex Team
www.apexgametools.com

 

I went ahead and purchased it. I'll implement it into my game tonight and give some feedback and a review rating.

Thanks for the development. I will be watching for your other releases.

 

Great! we are looking forward to hear your feedback.

 

Do you have anything like the helper classes in A* Pathfinding Pro like its ConstantPath, RandomPath, FleePath?

 

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.

Dynamic obstacles on the other hand do use the bounding box. The reason for this of course, is performance. Constantly calculating the actual extents of a given element is slow. The consequence of this, as I reckon you already realize, is that if you have something like a simple rectangle askew at 45 degrees it is likely to block more cells than it actually covers.
Dynamic obstacles are meant for obstacles that move, change size or both on a regular basis, and hence they need to be fast.

Using bounding box of the collider is a nuisance however, and the task of finding a viable alternative is already on our back log.

 

I am not familiar with the functionality provided by the behaviors you list.
However a qualified guess would be that RandomPath is what is usually known as Wander. ConstantPath might be Patrol?
Fleeing is of course also a known term, but a flee behavior can mean a number of things, is it just fleeing from a specific other, is it a more advanced AI behavior taking enemy positioning, lines of fire etc. into account?

In any case, we have deliberately avoided making implementations of behaviors that are not well defined, since the likelihood of them matching the actual needs of any given game is low.
We do have Wander and Patrol behaviors and a rich API that makes it easy to implement your own behaviors that fit the exact needs of your game.

 

Constant path is the most important. It returns an array of all possible nodes that a unit can traverse with a path cost of X. Assuming you can specify different node traversal costs (like for slopes or custom functionality like for swamps or something) it doesn't just return nodes within X distance of the origin point but takes into account the cost of reaching them.So this is helpful to do things like display possible movement paths or evaluate possible destinations with your own logic.

 

Yes one of the advantages of a grid based solution is the ability to easily gain information for use with the AI.
Obtaining a list of cells that are reachable at a certain cost is trivial.
I take it the use case is something like a unit has a certain amount of movement points and you want to show where the unit can move to?
We do not currently have a helper for this particular functionality, but we do have generalized methods for getting a range of cells from the grid. However the product will evolve over time as we get feature requests, and adding a such helper is one of the easy ones, so I will add it to our feature request list.

 

Thank for the replay.
Point Graphs seem better for an outdoor situation.

 

We are in the market for a pathfinding solution. Our world is procedurally generated using a tile system (3d, no unity terrain just meshes). Our problem right now with pathfinding is the navmesh generation. It works well enough but the workflow is extremely tedious. Our biggest concern is that we have buildings with multiple floors stacked on top of eachother. Does your system support multi floored buildings? if having multi floored buildings is possible- since our tiles are loaded in at runtime, would we be able to save the grid data into a prefab?

 

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.

In general there is no need to bake grids since initialization is fast, however you can bake them if you wish, which will then save the data. However we do not save the grid data as a separate asset, so I will need to test how Unity actually responds to having a baked grid prefab'ed.

But if you ensure that you have your tiles loaded before the grids are initialized, you probably wouldn't need to prefab if I understand you correctly.

 

I apologize if this makes me sound inexperienced (because I guess I am in this regard.). Are you going to come out with a C# tutorial on getting and executing a pathfind? I do understand how to actually move the gameobject and get a vector3 position of where I want it to move.

I am really feeling pretty stupid at this point. I suspect I am supposed to create a new BasicPathRequest object, input my to and from variables but what do I do with it. Can you provide a very basic example of its usage?

As for patrols, I pretty much get this, in C# I am basically just set the patrol route I want it to use and it goes on its way without a problem using the Patrol and Steering behaviors but how can I interrupt the patrol to have the gameobject do something else?

I am coming from a Pathfinding solution that all I do is Request a path, iterate through a list of Vector3 Locations, and move my object along that path. So obviously I haven't had a very high level path finding approach.

 

We are planning to release a number of tutorials on various topics, in addition to those already included, but you are right the tutorials are not focused on how to use the API.

That said the example I gave in an earlier post, is all you need to make a unit move to a location.
In other words you do not explicitly make any calls to the path finder, this is done under the hood.

You can however interact with Apex Path at pretty much any level you wish, so if you want to control locomotion (the actual movement of the unit) that is as easy as implementing a one method interface. If you want to completely take over steering you can, of course that will require you to do a fair bit of coding.

If on the other hand what you are after, is a way to call the path finder directly to obtain a path or a path result indicating if a path exists or not, for AI use, that too is of course possible albeit requires a few more lines of code.

To communicate with the path finder, the first thing you need to do, is have a class implement the INeedPath interface which is how the path finder delivers the result. Note that the path finder calls in on another thread (if you have multithreading enabled).

Then from that class you can issue a request as follows:

Code (CSharp):

1. var request = new BasicPathRequest()
2. {
3.     from = from,
4.     to = to,
5.     requester = this
6. };
7.  
8. GameServices.pathService.QueueRequest(request);

You can refer to the API docs if you want to see the full list of possible arguments to send with a request.

Next, regarding patrols. You can simply disable the patrol behavior to 'turn it off' and vice versa.

I hope this answers your questions, but if it does not, please don't hesitate to ask again.

 

Just bought this to replace our current solution using the default NavMesh & Agent solution. Absolutely loving it so far. I agree with @twick as above I would like to see more in depth about the API and how to integrate all the options in code. (Ganna have to go in and change out the set up we have in place using NodeCanvas - nice to see @nuverian above inquiring also)

Here is a question for you, is it possible to make an agent aware of other agents, as in they are seen as a dynamic obstacle? I tried adding the dynamic obstacle component to them and as you can probably guess, that did not turn out at ALL like I had planned. Lol.

 

So it pretty much just clicked on how to really use this well. I am really impressed.

In order for me to get the unit.MoveTo to work I had to do the following in c#.
IMovable unit = gameObject.GetComponent<SteeringComponent>() as IMovable;

One more question. I am using a StateMachine to handle AI behaviors. Is it possible to setup a callback to the steering so when it completes the path it will call specified function? (Or similar)

 

Glad you like our product.
Regarding the API, we do have full documentation included in the package as well as a guide on extensibility and quite a few examples and tutorials with associated code. That said we will look into making some additional hands on tutorials on how to accomplish various things through code.

Now to your question about making agents aware of each other. This is commonly referred to as perception.
Perception is not part of the Apex Path package since it is not path finding related. In the upcoming update there will be very basic perception, since we are adding basic avoidance steering.
We will have perception included with our steering package, which is the next product in line to be released.
We will have more advanced perception included with our AI package, which will be released some time after the steering package.

And no you are right, agents are not meant to be dynamic obstacles .

 

Actually to make your code work correctly you should replace the SteeringComponent type argument with SteerForPathComponent. SteeringComponent is an abstract class and there will likely be multiple steering components attached to a single unit. In other words change your code to this:

Code (CSharp):

1. IMovable unit = gameObject.GetComponent<SteerForPathComponent>() as IMovable;

However that is rather verbose. There is a small short-cut you can use to get an instance of an attached component implementing a certain interface. This removes the need to explicitly state the implementing type, and therefore makes for a looser coupling.

Code (CSharp):

1. var unit = this.As<IMovable>();

This code snippet can be called from within any MonoBehaviour. Since it is an extension method you will not see the intellisense show this as an option until the code file has a using statement at the top to include the Apex namespace or a sub namespace.
It should be noted that the As extension is somewhat slow, so it is recommended to establish references in Awake or Start.

Regarding callbacks. What we use is 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 either knowing about each other.
There is a whole section in the Extensibility Manual that explains in more detail about the two message bus types.

But let me give an example of how you would subscribe to messages regarding unit navigation.

Code (CSharp):

1.     public class YourBehavior : ExtendedMonoBehaviour, IHandleMessage<UnitNavigationEventMessage>
2.     {
3.         protected override void OnStartAndEnable()
4.         {
5.             GameServices.messageBus.Subscribe(this);
6.         }
7.  
8.         private void OnDisable()
9.         {
10.             GameServices.messageBus.Unsubscribe(this);
11.         }
12.      
13.         public void Handle(UnitNavigationEventMessage message)
14.         {
15.             /* Here you react to the message */
16.         }
17.     }

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. In the next patch the initialization of the message bus is enforced to happen before anything else.

That was a rather long post, hope it all makes sense.

 

This worked like a charm. Thanks a bunch its working great. I think I have a much better understanding. Really happy with the results and performance.

 

Is there a good way to make this follow behind the player or another AI character?

 

A follow behavior is not really related to path finding, it is something you would implement in the AI.
Follow could mean to follow some other unit up close, in which case it could be a steering behavior.
If the unit you want to follow is some distance away you would typically set an interception course using path finding and then follow by steering once close enough.

So in other words, you can definitely implement a follow behavior using Apex Path, but it is not part of the product.

However follow is a simple behavior and could look something like this:

Code (CSharp):

1.     public class SteerToFollowComponent : SteeringComponent
2.     {
3.         private const float _closeEnough = 0.01f;
4.  
5.         public UnitComponent unitToFollow;
6.         public float separation = 1.0f;
7.  
8.         protected override Vector3 GetMovementVector(Vector3 currentVelocity)
9.         {
10.             var minSeparation = this.unitToFollow.radius + this.radius;
11.             var separationVector = this.unitToFollow.forward * (minSeparation + this.separation);
12.  
13.             var steer = this.unitToFollow.position - this.position - separationVector;
14.             if(steer.sqrMagnitude <= _closeEnough)
15.             {
16.                 return Vector3.zero;
17.             }
18.  
19.             return steer;
20.         }
21.     }

To add additional steering components, you would follow the same formula.

 

Hi there,

I am interested in any pathfinding solution and I'm currently trying to decide which to risk investment in for my game. I use a unity terrain which has dynamic obstacles but here are my concerns/questions:

1) Will I have to manage my own animations relating to the movement? (all of your examples just show a static, non animated arrow - what about a fully animated object with 5 animations?).

2) Is it possible to check if an object will block the destination of the agents in a custom script? Following on from that, disallow the object to be placed into the world? Something like if (destinationForAllAgents != blocked) { Instantiate object } else { Debug.Log("Blocked - not allowed"); }

3) I see you have pause zones. I need to create an animal that will pick valid random points close to its current position and move to it, then pause for 5-10 seconds before moving again. Is this possible? A bit like a random wander with a pause between each point (and obviously checking the point is valid on your nav mesh).

4) Are the senses for sight/audio so you can calculate a new target destination if they are within X distance? For example, chase a player on sight?

I'm currently using a free AI solution which has everything I require other than dynamic obstacles and it's holding me back so I'm having to look elsewhere.

I understand this is just a pathfinding solution and if your perception and AI addons will do all of the above in the future, consider it a purchase (I take it these are bolt-on's to this pathfinding asset?). There's a bit of a fine line at times when it comes to differentiating pathfinding and AI.

Hopefully some of these questions will help others decide if this product is for them.

Thanks

 

1) Yes, there are a few ways in which you can control your animations.
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, its simply a matter of implementing a small interface.

2) Yes 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.

3) Our wander behavior already supports this functionality. And just to avoid any misunderstanding, our solution is grid based, i.e. not Nav Mesh based.

4) Perception is not a part of Apex Path since it is not related to path finding. Perception will be part of future packages, starting with steering which will have some perception and later the AI package with full perception features.

And yes as mentioned above, perception and a number of other features will be part of future packages.
It is true that some people refer to path finding as AI, but in truth it isn't. Path finding is a tool required to build a solid AI.
What we provide are the building blocks. You can choose to buy some and make the rest yourself, the only requirement is that if you want the roof you need to have the foundation also , i.e. AI will depend on Path finding.

I hope this answers you questions, and helps you decide.

 

Thanks Geminior,

Sounds like I'm having to wait for the AI package to get what I require. Point 2 may raise some concerns about performance as there may be 50 agents in the scene with different paths to get to point "A" and I will have to go through each and every one to check if it's valid and only once all are valid, can the object be instantiated. Having said that, I would likely be in this situation regardless of which asset I use/purchase.

The only animations that I require would just be a run (or walk), attack animation (this would be based upon perceptions which you don't have yet), and a death animation.

I thought about getting a behaviour tree asset to bolt onto this but I think I will wait until you release your AI module. I'm in no great rush at the minute to perfect the AI, I've plenty to be getting on with regarding my game

Again, thanks for your answers and I look forward to your AI module for this asset.

 

Any idea when the steering part will be released?

 

We are still in the process of deciding what to include in the package, and therefore we cannot say when it will be released, and I can't even give you a serious estimate at this point.

Are you interested in any steering behaviors in particular?

 

Apex Path v1.1 is now available, it includes Basic Avoidance Steering, full description is in the first post!

 

Bug in 1.1.
We have just been informed of a bug in 1.1. The class MenuExtensions located under Apex\Scripts\QuickStarts is an editor script and should have been located in the Apex\Editor folder instead.

We will of course fix this, but until a new patch is made you can simply move the file yourself and you will be able to build your game.

 

We just published a getting started video tutorial!

There are more tutorials coming!
Hope it's useful and you like it.
I have also updated the original post ;-)


The Apex Team
www.apexgametools.com

Follow us and get all our news, updates, tutorials, etc.

 

This is an old post but I just wanted to say I have found a solution for this. In our game we have the ability to place/rotate objects. The solution we have found is to attach multiple dynamic avoidance objects to each single object. The dynamic objects attached to each object are smaller than a 1x1 grid size. Example: A table will have 4 dynamic avoidance objects at each corner (Simple box mesh). When the object is rotated it is only affecting single grid points at each avoidance point. This gives use the ability to rotate objects while maintaining a walkable path that makes sense.

The reason: When we had 1 large avoidance point encompassing the entire object it was taking the length/width of the object and created a large box. This made points that should be accessible, inaccessible. The above solution I mentioned has worked for us. Maybe you guys over at apex could test this out and a better solution could be made from this, or this could be the standard. Either way I'm happy.

 

12 example videos and 6 tutorial videos

We updated our website with a lot of example videos and video tutorials, I have also added a couple of the to the original post.
You can find all our example videos at: http://apexgametools.com/apex-path-examples/
and all our video tutorials at: http://apexgametools.com/tutorials/apex-path-tutorials/

Currently there is 6 tutorial videos and 12 example videos, we will be adding even more over the next couple of days!
All our videos are also available at our YouTube Channel

Let us know what you think!

The Apex Team
www.apexgametools.com

Follow us and get all our news, updates, tutorials, etc.

 

Thanks for posting your solution, I am sure it will benefit others.

With regards to a generalized solution, it is not quite that simple I am afraid, since dynamic obstacles can have any shape and form imaginable. So what we really want is a way to establish the non-axis aligned bounding box and use that, but as of yet we have not found a solution to this that provides reasonable performance.

 

Hi there Geminior!

I am quite interested to see if your pathfinding solution would work for my game. I have multiple (4) terrains joined together which are 4000x4000 units each (total of 8000x8000 units) with obstacles ranging from cliffs to rocks to water. Using the built-in navigation is not an option because it creates a baked mesh - something the game simply cannot support in memory. Does your pathfinding solution support such vast environments and AdHoc pathfinding at runtime?

Thanks!
-Mark

 

Hello~ does Apex Path work with 2D world game?

 

Very large maps is the achilles' heel of grid based solutions due to their uniform nature.

I can say for sure that grid visualization would have to be turned off, since drawing gizmos has extremely poor performance and would kill the editor.

Now since our solution does not require baking, it might work, but the start-up time would be significant if the grid has to cover all of the terrain. And even then it may still require too much memory.

So let me ask you a few questions to better be able to give you a qualified answer.

Are you using Unity Terrain?

Do you need the grid to cover all terrain, or do you have open obstacle free spaces where no actual path finding is needed (Apex Path supports off-grid navigation)?

 

Please refer to this answer: 2D support

 

Thanks for the reply!

I am using Unity Terrain via TerrainComposer. The map I am creating is 8km x 8km in size for various reasons - but it's an open world type of simulation which requires a significant chunk of ground.

Baking and predetermined grids are, like you said, extremely resource-intensive. I'm looking for a more light-weight solution.

The potential navigation area is the entire map (apart from the "off-limit" areas determined by terrain slope, obstacles, etc). For example, the terrain is composed of mountains and valleys. The NPCs (for which this will be used) are bound to realism - i.e. they can't scale a cliff but they can walk between valleys and over mountain passes. So there are areas which are less lightly to have issues, but I don't want to have to manually assign these zones as I plan to fill them with rocks and other details which are not walkable.

Thanks for your reply!
-Mark