This doesn’t work for all map geometry though. In the case of the repro I sent you guys, the NPCs just pile up at the end-islands (red) instead of making their way down and around (blue path) as shown below.
Have you considered adding an agent parameter under PathSettings that would restore the old Brute Force behavior? Could be something like BruteForceCalculations? My game relies on the previous method because it needs accuracy over speed in terms of calculations, so adding a PathSetting for it would allow games like mine to continue functioning while also allowing developers to trade accuracy for speed if that suits their use cases more.
For example, you could set your target to be the midpoint between your current position and the final destination
This wouldn’t work in this example because the middle point between the two ends of the map is in the void, so the NPC wouldn’t be able to calculate any sort of path there.
It’s really frustrating as a developer to have the expected behavior of the service change like this, as core parts of my experience (NPC combatants) relies on the service heavily, and the game was built with the previous system in mind (that being higher computation times in exchange for higher accuracy/success rates)
I agree with Marioman73. The tradeoff of over doubling the accuracy far outweighs shaving off a few milliseconds of computation time. Because if the NPCs don’t even go where they’re supposed to, what is the point of being faster…? The entire service would be useless with that high of a failure rate. Please provide an alternative method for node-based brute force calculations for the games that need consistency over expedience.
Thanks for the feedback. I would request you to try this algorithm out. It should not have any higher rates of failure. If it has please report to us and we will provide a solution/fix . Our intention is not to break any existing games or functionality. I would like to also clarify this 40 msec is based on our internal analysis. This is the time it takes for our A* algorithm to find a path which is not to be confused with time it takes for findPath to return the result. The only reason to highlight that we have put a time limit was to make sure developers are aware and incase they see any regressions they can report to us. We will fix all the concerns before going out of opt in phase.
I myself have not had any issues with it, but then again, I’m not doing anything overly complex. I’m working on an autonomous drone swarm that can deliver packages. Here’s a quick demo of both versions, where they hide Easter Eggs in a maze:
Default behavior:
Improved behavior:
So there’s not much difference between them. Especially hard to tell since I had to shorten and compress the videos to upload on DevForums. I can send you the game file itself if you’d like to test further.
To quote your own post from our DMs discussing this previously.
More specifically
New pathfinding algo (UseImprovedSearch true ) with the timeout logic enabled : It performed best wrt to the max compute time taken of 8 sec and avg of 3.12 sec . However I do the number of successfull searches have also reduced which I would accept in case it takes more than 20 msec in A* star to find the path. It would return partial Path though.
You state yourself that while the time is faster, it has a much lower success rate of finding exact paths. Your reasoning for accepting this is that it would return partial paths.
However, developers such as myself do not always allow for partial paths to be computed. And as I have tried to say previously, the result is that NPCs are unable to find paths that they would previously, due to the new time limit.
New pathfinding algo (UseImprovedSearch true ) without the timeout logic enabled: … However success rate was better than the with timeout logic algo. This again is expected as it gives more time for exploration.
You said it yourself that the version of the new algo without the time limit does a better job of finding paths, so we can’t we use that version? I would much prefer slightly slower computation times for much greater accuracy. Alternatively, why not have a parameter under PathSettings which restores the original system (new algo, no limit), called something like BruteForceCalculations?
the pathfinder still geeks out sometimes, also platform cheesing still happens just that it only makes the npc get baited once the pathfinder is near a ramp or near a jump point
The production opt-in for PathfindingUseImprovedSearch is now officially re-enabled. Please note that this update only affects your game if you have explicitly opted in; if you haven’t opted in, your production game remains unchanged.
Thank you for your continued feedback and support. If you encounter any issues or have any questions, please report them to us.
Important: Please monitor your game after opting in. If you encounter issues such as crashes, memory spikes, or pathfinding failures, we recommend using the Performance Dashboard to closely monitor your game’s performance. If needed, you can opt-out of the feature in Studio and re-publish your game.
Important: Please monitor your game after opting in. If you encounter issues such as crashes, memory spikes, or pathfinding failures, we recommend using the