Support Forum

Unity Pro vs A* Pathfinding Project Pro

Hi, just updated to Unity Pro and asking myself if the Unity Pathfinding is better then Aron’s?

1 - Where are the differences?

2 - Is one faster then the other? Bake and ingame calculations.

Which one would you recommend?

Thanks
weyoun

Hi

There is a comparison page here: https://arongranberg.com/astar/freevspro

In veeery broad strokes: this package is a lot more flexible (more graph types, custom movement scripts, different modifiers etc.), unity has better support for off mesh links, scanning a recast graph in Unity’s system is faster (because c++, both Unity’s system and my package are based on the same base project called Recast). I’m not sure how runtime updates compare. This package can save graphs to files and load them during runtime, which I don’t think is possible with Unity. Penalties and tags are more flexible with this package than what Unity has. I think raw pathfinding in this package is faster (I am not 100% sure though), among other things because I think Unity only has the option to use a single thread for pathfinding while this package can use any number of threads. This package has different path types that are useful for some games (e.g FleePath and RandomPath).

I can obviously not make any recommendation as I am the author of this package and is thus partial. You can take a look at some reviews of the package here (click the ‘show more’ button): https://arongranberg.com/astar/

Brackeys just made a video about it: https://youtu.be/G9Otw12OUvE

And another one: https://youtu.be/CHV1ymlw-P8
Oh man, it looks so easy when he does it ^^ Wasn’t pathfinding a Unity Pro exclusive?! Stopping distance seems promising… Remember our Getnearest/pushing issue?

That last one looks pretty much equivalent to the get started video tutorial for this package (though for a recast graph instead of a grid graph). I’m not sure what the purpose of posting it is as it doesn’t really compare the packages at all, it’s just a tutorial for Unity’s navmesh system. I only skimmed through it, but from what I saw, everything is doable just as easily in this package. E.g ai.destination instead of ai.SetDestination, RecastMeshObj component instead of NavMeshModifier, layer masks work pretty much the same way in both packages.

Sorry, I don’t wanted to praise Unitys inside navigation. But for me, if I knew this integrated pathfinding is doing so well and is free, it had or will be possible that I switch to it for longterm compatibility so I am sure every new Unity version supports it.

I bought your asset for 2D oldschool movement (with unit colliders) which isn’t doing well / is not the focus?! Nowadays it’s hip to let every unit walk through another like in Rimworld or Prison Architect but that’s just not what I want. I think units have to avoid eachother without pushing on the way or at the end (ok, except SCVs ^^).

I am not into pathfinding and can not say how hard it is to accomplish. On the other hand many open source projects like openRA, openDune… show how it’s done. Would love to have it integrated here.

Don’t get me wrong, I love this asset, rated it 5-star and want it to grow. But my rts does not feel right because of this and if I see what Unity offers, I question my decision to go for 2D. Or use orthographic 3D + navmesh and I am fine…

Sorry again.
Hope you get my point

Yeah, I understand. It’s just hard because this package caters to a huge number of different game styles. Your style of 2D oldschool movement is unfortunately currently not one that is supported out of the box. Furthermore I haven’t really been compelled to implement that kind because usually if I do research it a bit further, I usually find pages and pages of people saying the pathfinding in that particular game was absolute crap (e.g SC1 and many other games with a similar oldschool pathfinding system, here is one more extreme case showing how tricky it can be: https://richg42.blogspot.se/2018/02/on-age-des-pathingmovement.html). Maybe I wil try to make some kind of old school pathfinding at some point though.

I don’t think you will be able to do any kind of old school pathfinding with Unity’s system though. It’s harder to do that with navmesh-based systems. (on the other hand, if you do succeed, I’d be very interested in knowing how).

Unity’s navmesh system is very good for many things though. So it is perfectly reasonable to point out the places were it does do better than this package so I can improve it :slight_smile:

Well here is my opinion - you can achieve almost the same effect with both, especially if you are working on a small game, but here’s why I stopped using unity navigation (I’m working on open world game):

The navmesh surface cannot bake tree colliders places on the unity terrain. I had to spend some time to be able to export the colliders and then bake them.

Another thing is that it’s a pain to have different walkable surfaces. Let’s say you have a flee AI that can go everywhere on the terrain, but you then want to limit where it can go and “draw” a zone for it. So a river-snake won’t be able to chase the player in the forest, or a wolf won’t be able to chase the player in the water. This is where I give up using the unity’s default navigation. You can place invisible boxes and bake 2 navmesh surfaces - for river creatures and forest creatures but the problem is that their colors are overlayed on top of each other’s so if you want to have one in the middle, let’s say a beach creature like a crab, then you have to deal with 3 colors and what if you need one more - it becomes hell! You will also have to make a custom tool that draws the walkable zone for each one (because placing invisible boxes to surround areas is a nightmare).

There’s no local avoidance, you have to implement it yourself.

Now I feel like I have more access to “things” like check if the ground underneath the player is walkable for that specific AI (not sure if it can be used in unity’s navigation, haven’t tried it)

The A* developer responds and works on things fast. A couple of people posted a ticket on github for the unity navmesh surface to include a way to bake terrain trees colliders and it’s been more than 6 months, still no response.

I have to say I agree. Unity support on the navigation forum is completely dead. A*PPP support may only be ran by a (highly responsive) one man team but that is currently one more then Unity for quite a while now. As unity versions have progressed the “new” nav components have gotten buggier and many holes exist in the exposed API. No updates on their GitHub in ages. It looks like they are working on c#job system and navigation but no one’s talking about it. Super frustrating.

1 Like

Thanks guys. That gave me an insight and that’s what this thread was all about…