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

thanks for quick reply.

Oh, greate! I want to study and challenge about asset.
I will purchased on sell

 

What would be the reason for after doing a MovableAgent.MoveTo a unit stops moving without either generating an Event.DestinationReached message or any of the Stopped messages like Blocked, NoRoute, etc?

 

Apart from being explicitly told to Stop, it sounds like a bug that it would just stop by itself without announcing the reason.

I recommend that you write us on the support email (support(at)apexgametools.com), with a bit more detail of when this occurs.

 

Is it possible to integrate Apex in a Dedicated Server version of a Game?

I want to programm an Authoritative Server so I need to do the pathfinding on the serverside at least that much that I can find out where every NPC or Mob shouble after some specific time

Sorry for my bad english

 

Apex Path relies on Unity for grid initialization, and the path finder relies on the grid.
Are you running Unity on the server as well, if so it should be possible, but it is not something we have looked into.

 

I am slowly getting to grips with Apex Path...

I need it for wandering + fleing AI creatures in large terrains. As I now understand a grid based solution might not be the best choice for a large area,.. but since I bought it and since I like its simplicity I decided I might as well try to use it the best I can.

My creatures doesn't necessarily need to traverse large distances so I will make many smaller grids I guess and then initialize them when needed...

I'm not there yet. Right now I'm struggling with the basic setup. I made a 50 x 50 x 40 gameworld, I discovered how to add the terrain height map component and I added a unit with the wandering behaviour.... It is working as intended....

BUT... It hits the terrain trees, it hits the rocks... and get stuck there??? I tried adding these to both the terrain and the blocks layer... but the unit still gets stuck... why??

Both the terrain trees and the rocks are added with Terrain Composer. I somewhat expected that trees could be a problem since they are part of the terrain... but the rocks are just normal gameobjects..

Jesper

 

First off, yes stitching together grids and having just a few active at a time is the way to go in large worlds.

You don't actually need to add a terrain height map, one is added automatically, and the grid has its own height map.

So why are trees and rocks not properly identified as obstacles. Well my guess is that they do not have a collider.
Objects that are to be considered obstacles, must have a collider in order to be identified as obstacles. This is true for both height induced obstacles and those explicitly added to the obstacles layer.
But then you say it gets stuck, which suggest that colliders are present?

Also the granularity of the height map must be fine enough to hit all objects, so if you changed the default 0.1 value to a higher value that may be one reason.

If neither of my suggested causes match reality, please contact us at the support email support(at)apexgametools.com so we can delve a bit deeper into this.

 

About the trees and rocks issue that someone else was having, I had the same thing and found it was because I didn't bake the grid. On top of that I had another issue where units required a collider that wasn't set to a trigger in order to function properly (this was most annoying, because I needed a collider as a trigger for my units too). I'm sure there are work arounds, I tried adding two colliders but that didn't sit well at all on my lil' tanks.

 

Ok, so now the rocks are working as intended. They are normal gameobjects added to the terrain with Terrain Composer. They turn red on the accessibility map and are avoided by my frog.

But the trees do not work no matter what I do. They are terrain trees. They have a capsule collider on the trunk as is normal practis with trees. I tried adding them with Terrain Composer and I tried painting them on the terrain like normally within Unity. I tried having them in the Blocks layer and the Terrain layer....

The only way they will work is if I add them as a normal gameobject. That is not an acceptable option.

The granularity is 0.1.

Jesper

 

Not meant bad but your PathFindingEngine should at least be able to to do the following and it doesn't

Moving from one Grind to another and also eveluating if the next Grid is so close that it has to lookup if there is something in the way on the other grid and then adjust on the current grid so that it can move in the new grid without bumping into objects.

Sorry for my bad english

If you want to know why I even got to this kind of problem I will tell you:
As far as I understood from the previous posts your engine is not able to update huge grids so I thought to myself let's workout another solution. So I tought to myself lets create hundred of small Grids and only enable the ones my NPCs currently needing. It's not working because of the little problem I stated above.

Please fix this


###Found a workaround by overlapping the grids but it is only a workaround in this case I don't know how it's gonna keep reacting if I add a more complex environment gonna update it when I get more problems

#Update: If its getting more complex the pathfinding Engine is nolonger capable of finding a way

 

Path finding across disconnected grids is obviously not a possibility.

To use multiple grids efficiently they should be connected, or stitched together, by portals.

With the release of update 1.2 we will also release a number of videos one of which will show the way to stitch together multiple grids.
We expect 1.2 to be live on the asset store in a few days.

 

Ok this sounds odd. Is the upper and lower boundary of the grid set so the trees are inside the bounds?

If so, could you please write us at the support email, as this is not the best place to have back and forth conversations.

 

Just a footnote, the requirement of having a non-trigger collider on a unit is not imposed by Apex Path.
But it is true that units with no collider will, well not collide with anything, so they can walk through walls etc.

 

Thanks alot for your help I will be looking forward to the release of 1.2

 

ok thanks. seems like I'm screwed lol

 

Apex Path Q & A page!

We have collected the most common questions regarding Apex Path, and created a Apex Path Q & A page, including small code snippets.

http://apexgametools.com/apex-path-qa/


The Apex Team
www.apexgametools.com
Apex Path Q & A
Support forums

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

 

Hello, I am still figuring out how to use Apex so please bear with my newbie questions:

Right now I have an enemy AI following my player around by calling the MoveTo() method every second so the AI moves to my player no matter where my player moves.

I have some dynamic obstacles in my scene. Whenever my player stands next to a dynamic obstacle (a red grid area), the AI stops following my player.

Basically, whenever my player is standing on a red grid area, MoveTo() seems to have no idea where my player is, and stops moving the AI.

Is there an easy way to have the AI continue to move toward the last known grid cell that that player was on, and once the AI gets close enough to the player, just move toward the player directly even if the player is not standing on a valid cell?

Maybe do some sort of call to GetNearestWalkableCell when the player steps into a red grid area. Something like that.

Thank you!

 

Apex Path 1.2 RELEASED

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.

The Apex Team
www.apexgametools.com
Apex Path Q & A
Support forums

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

 

What you are experiencing is the default behavior, where units that get an invalid destination simply stop.

You have a few options.
The first is to add a result processor to the units to override the default behavior, this video explains it.

The second option is to use the setting 'Navigate to Nearest if Blocked' on the SteerForPath component. This is a new setting in version 1.2.

In fact you may want to use both. The first option can replan the path to the nearest unblocked cell, and the latter can make sure the unit moves as close as possible in the case when no actual route exists to the target.

 

Thank you, your solution will get the AI as near as possible to a target destination that is within a group of blocked cells. But how to move the AI directly the rest of the way to the target destination?

In other words, sometimes my target player is standing within a group of blocked cells (for example, standing next to a dynamic obstacle, which usually have a wide border of blocked cells around them) or even standing outside the grid:

1) I want Apex to find a path for the AI to the nearest walkable cell.

2) Then I want Apex to move the AI into the blocked area (or even off the grid) to touch the target player.

How to do this? Thanks!

 

What you describe cannot be achieved through path finding. The path finder's job is to find a path around obstacles, not into them .

It does sound a bit strange to me that you have units standing in invalid areas.

In any case you could implement it as a steering behavior. So first to go as close as possible and then you activate the 'seeker steering' that will just move the unit straight towards the target.

We will have a video on how to implement custom steering behaviors within a day or two, but there is also a post here that explains it briefly.

 

I have a big world(10000x10000) and I gonna split my Grids into 100x100 sized would it effect performance if I connect every grid cell at the border of my grid with the border grid cells of the neighbouring grids?

I calculated that it would be around 400000 Connectors for the hole map
Or are connectors not active components and don't need computing time every frame?

 

That sure is a big world. Connector portals are not active and do not update every frame (or at all).

But how Unity handles that many objects I cannot tell you, you will need to experiment. Just use the new Grid Field tool to set it up. Oh and by the way it will 'only' take 19801 portals, but its still a lot.

If you do run into problems with this, I would instead generate the grids at run time. You will have to manually initialize them in any case, so having them predefined is not a big advantage.

 

Nevermind controlled it within my avoidance. I'm looking forward to seeing what your more expanded avoidance / steering solution looks like when its ready.

 

This doesn't seem to do anything for me... I checked the box but the AI enemy unit still stops moving when I'm standing in an invalid area. Do I need to do something else besides check the box?

I don't know why that is so strange to you... in the scenario below, my player currently cannot be reached by any enemy melee units. Perhaps I am not using Apex the way it is intended?

 

I've got a slightly different but related issue now as well...

I got the enemy AI moving to the closest walkable cell if my player target is standing on an invalid cell by using the SteerForPathReplanWhenBlocked script instead of the 'Navigate to Nearest if Blocked' checkbox.

However, the enemy AI disregards a blocked line of sight, so that the nearest walkable cell returned could be on the other side of a wall, for example (see picture). Is there a way to do some kind of line of sight check when using the NearestWalkableCell functionality? (perhaps return the nearest walkable cell that has a line of sight to the target destination)

I'm just trying to build a very simple enemy AI -- when the enemy gets close to you and sees you, it chases you. If you go around a corner, it follows you. When it gets near you, it hits you. Thanks for all your help!

 

First of all, as I stated initially, you probably want to use both options. The things is that currently the 'Navigate to Nearest if Blocked' setting only applies to inaccessible areas but not actually blocked destinations.
Initially it was meant to do both, but we decided to not do it for directly blocked, since this can be achieved by using the SteerForReplanWhenBlocked processor or similar implementation.

But as you mention yourself, this is AI territory, and the whole line of sight thing is not part of a path finder's repertoire.
But you can implement this yourself and you can use the GetNearestWalkableCell. The easiest way would probably be to get the nearest walkable cell to the target and use that as the destination for the player.

Lastly, those obstacles, are they normal obstacles or are they dynamic obstacles?

 

Is it possible to make a Grid being attached to unit and then gets moved around with the unit?

 

No I am afraid not, the overhead of such a solution is simply too great.

What you can do however is to dynamically instantiate grids at runtime to cover the immediate area where the action is taking place. At the same time you would disable the grids no longer relevant.

 

Could please you elaborate on what I have to do? The enemy AI is already finding the nearest walkable cell to the player target, but that cell happens to be on the other side of the wall. How can I get Apex to find the nearest walkable cell to the player target that has line of sight on the player? Thank you.

They are dynamic obstacles but they don't move. I made them dynamic because each time a level loads the obstacles and walls are created and placed randomly on the map, so the grid doesn't know about them until a few seconds after the grid has been initialized.

 

Since Apex Path does not include AI functionality, Line of Sight functionality is not available. The task of intelligently evaluating the most optimal destination is a job for the AI.
However if you find the nearest walkable cell to the target from the target, i.e. seen from the target's position what is the nearest walkable cell. You then use that as the destination of your NPC.

So in short the difference is the point of view, i.e. inRelationTo.

Ok I would highly recommend that you either assign your initialization code a placement in the script execution order that is before the grid, or that you manually initialize the grid at runtime.
This will allow you to use static obstacles, which are more precisely adjusted to the obstacle geometry (dynamic obstacles use the bounding box).

You simply set Automatic Initialization to false on the Grid, and then once you have placed all your level geometry you call the Initialize method on the grid.

To see more on grid initialization options, you can watch this video.

 

We have published even more video tutorials.
9 tutorials added, now there is 10 basic tutorials and 14 scripting tutorials in total.

The new titles:

• Apex Path Tutorial Consuming Path Finder Results
• Apex Path Tutorial Large Worlds
• Apex Path Tutorial Locomotion
• Apex Path Tutorial Messaging
• Apex Path Tutorial Moving Units 2
• Apex Path Tutorial Path Finder Interaction
• Apex Path Tutorial Portals
• Apex Path Tutorial Replacing Selection Visuals
• Apex Path Tutorial Steering Components

You can find all of our video tutorials on our tutorial page or on our YouTube Channel

Let us know what you think, your feedback is highly appreciated!

The Apex Team
www.apexgametools.com
Apex Path Q & A
Support forums

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

 

Sorry to be stuck on this issue but I don't quite understand what you suggested... if I find the nearest walkable cell from the player target to the player target, Apex could still potentially return one of the walkable cells that is on the other side of the wall, couldn't it?

 

Hi Eridani,

To elaborate on Geminior's suggestions.

The challenge to your problem seems to be that the unwalkable cells are blocking line-of-sight from one direction (down or south) but not line-of-sight from the other directions (up, right and left / north, west and east). The pathfinder does not have information about which directions inside an unwalkable cell is blocking line-of-sight, so this is indeed an AI problem, and not a pathfinding problem. In the following I will outline an option that could solve your problem, and which might also make it into our future Apex AI solution in a more advanced form.

Hence, to achieve what you want, you could do the following:

a/ Sample a set of cells from the grid surrounding your guy with the gun.
b/ Extract only the walkable cells from this sample.
c/ For each cell, you cast a ray or line using the Unity Physics-class towards the guy with the gun, so see if the line-of-sight is clear. (you should have the wall in a specific layer to make sure the ray or line detects it)
d/ You extract only the cells which have a clear line-of-sight.
e/ You then determine which cell the monster should walk to. You can basically implement any algorithm here, including the closest cell, the cells that are behind the guy with the gun, the cells that are e.g. 3 meters away etc.
f/ You can now request a path for the monster to this cell.

Keep in mind that the above process is quite processor intensive, so you should not do this every frame. Instead use a coroutine to schedule it e.g. every 5 seconds or use the LoadBalancer in the Apex Path to ensure it does not cause framerate drops.

If you want to experiment, you can enhance the cell-selection algorithm to include additional selecting criteria to make the monster attack when the player is looking away etc, to make it really scary.

Happy coding.

The Apex Team

 

Inspector Bug in 1.2

As some have already noticed there is a bug with the new editors if no attribute set is defined. All components with an attribute property, such as the Unit Component, will mess up the Inspector and log errors to the console non-stop.

To fix this until the next patch is released, please locate the file Apex/Editor/AttributePropertyDrawer.cs and replace

EditorGUILayout.HelpBox("To enable...

with

EditorGUI.HelpBox(position, "To enable...

 

Hi Jakub, thanks for your explanation and your suggestions. I am seeing that even making a simple enemy AI is more complicated than I thought. I can't wait until you guys make an AI asset that works with Apex Path =)

When computing the nearest walkable cell to my player target, I think Apex finds the nearest walkable cell from the center of the cell that the player target is standing on, correct?

Is it possible to make an option to find the nearest walkable cell from the exact position of my player character instead? If this was the case, I could implement a simpler strategy such as making sure the thickness of the wall was at least 50% of the cell width. This way Apex would never choose a walkable cell that is on the other side of the wall. Does that sound like a workable strategy to you?

I'd rather not code the multiple raycast strategy if possible because I'm working on a mobile project and I'm trying to keep the processing as light as possible, lol. Thanks for your help!

 

Hi Eridani,

You might still have the problem that the cell is not accessible from all sides. What you might want to do it to ensure that your guy with the gun only walks in walkable cells. Then Apex Path would work more-or-less out of the box getting the closest walkable cells on the same side of the wall where the guy is. I understand this might create a greater distance to the wall - however, the question is where you need this precision to realise your vision for game.

The Apex Team

 

The GetNearestWalkableCell uses whatever it is given as an argument. So in the case where the SteerForPathReplanWhenBlocked behavior is used, it uses the exact position of the requested destination seen in relation to the exact position of the unit, i.e. it does not use the cell center of the unit's position.

 

Thanks so much guys, I'm completely clueless about AI and pathfinding as you can see. I just want to make games, not work on lower level stuff like enemy pathfinding... I wish there was an out-of-the-box asset for a simple top-down rpg/shooter with dynamic obstacles and reasonably smart enemy AI. Maybe you guys can make one! I'm sure there are many indie devs who would buy it. Anyway, hopefully some last questions on this topic:

Hi Jakob, what would be the best way to ensure my character is restricted to walkable cells? Right now he is a simple capsule collider and rigidbody so he is allowed to move anywhere except when he bumps up against an object.

I've already made the cell sizes smaller on the Apex grid, which helps with my issue somewhat. I guess my next question would be what size grid would start getting too expensive for mobile? Right now my grid is 120 x 120 cells and I get a memory heap warning that the initial heap size of 200 on the Path Service Component is not enough.

Hi Geminior, in this case, is there a way to return the nearest walkable cell to the target position without regard to any InRelationTo direction? Meaning, the absolute nearest walkable cell to the exact target position (in an absolute straight line), no matter where that cell might be or what direction the "chaser" is coming from.

Thanks again =)

 

The only way to completely prevent the unit from entering blocked cells would be to adds some logic to check for it. And if he is moved by wasd or similar that may prove to be a bad idea.
The other option is to ensure that as much of your level geometry fills out cells entirely, or at least fills them enough to prevent a unit's center to enter blocked space.

The heap is of no concern really, the warning is merely there to allow you to raise the initial value which will avoid some unnecessary memory allocations.
A grid of size 120 x 120 with the default height granularity will take up just over 5 mb of memory, and path finding performance is barely impacted. Of course you will start to see a noticeable start-up delay due to the time it takes for the grid to initialize.
In any case you do not want to reduce the cell size to anything below the diameter of the largest unit to navigate the grid.

Well that would simply be achieved by using the same value for inRelationTo as for position, i.e. GetNearestWalkableCell(target.position, target.position,....).

 

Starting with a fresh project I imported Apex Path 1.2 and assigned the QuickStarts -> Navigating Unit set of components to an empty GameObject and I am receiving the following error:

The part that relates to ApexPath is towards the upper middle:

 

Nice update! Thank you very much for including the option to randomise waypoints for units. Out of curiosity when can we expect Steer and AI to come out? These assets would literally finish my game for the most part. What can we expect in the AI package? If I'm aware, I can focus on other aspects like getting a frontend and art assets in and worry about controls and AI later.

 

Please refer to this post.

 

We expect Apex Steer to launch by the end of this year.
With respect to the AI package it as too early for us to be able to give a release date for that. It will follow after the Steer package.
I realize that it is not super helpful if you need to plan your own release cycles, but we would rather tell it like it is, instead of posting complete guesswork, which would be even less helpful.

 

Awesome, thank you.

 

Hello, question about waypoints...

Instead of issuing a MoveTo command to a destination and having a unit start moving, is there a way to get the first waypoint to that destination, and I will handle the movement myself through some other code?

So in other words, I just want to get the path waypoint information without actually initiating any movement. For example, perhaps I just want my unit to turn toward the first waypoint, but not move.

Thank you!!

 

Yes you simply request a path directly from the path finder.

You can find two videos that explain this here and here.

An alternative is to write a result processor to basically overrule the default result processing following a MoveTo.
There is a video explaining result processing here, although it does not cover this specific scenario.

 

So, how do I get at the current path on a Unit? any advice? A simple code example would be great.
(I'm not a coder but can hack things together if given enough info) I'm trying to create a "look at next node" for animation purposes.

Cheers!

 

A unit's current path is a property of the ISteerable component, which is implemented by the SteerForPath component.
So given you have a reference to the unit's gameobject, you can get a reference to the ISteerable like this:

Code (CSharp):

1. var steerable = unitsgameobject.As<ISteerable>();
2. var path = steerable.currentPath;

or explicitly referencing the component

Code (CSharp):

1. var steerable = unitsgameobject.GetComponent<SteerForPathComponent>();
2. var path = steerable.currentPath;

 

Awesome! simple enough even I can understand it cheers!