-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regressive search is probably a bit smarter #2
Comments
Unclear if the project is still maintained but I've implemented backward pathfinding as you suggested (in a somewhat stable form?) and it is much much faster and efficient as buildGraph() does not draw full trees for every single combination of options (which the GC hates) but only for those that have a chance of succeeding. Edit: Anecdotal comparison, with 10 actions and 10 plans to find, the original model took roughly 2.5min to complete; with backward pathfinding it takes less than 0.20 seconds. |
@flamelstone Hey! I have been looking for regressive search implementation and couldn't find any... Is there any chance you could share your implementation with us? |
Seconded, would be super useful if you could share it @flamelstone |
@miro4994 @deanvaessen Sorry for the delay, life got really busy and I couldn't get around to answering you guys. Hereafter is the code I used to implement a regressive search. A few things have to be mentioned however: I implemented this in a C# context, so a lot of unity specific language has been switched to regular bools or whatnot; also this was one of the first time I was playing around with C# and coding in general so it's probably very rough and I cannot guarantee anything in terms of performance or even safety. In essence, the trick to make it regressive is to replace every precondition by the effect. I hope this helps and I will try my best to answer any question you may have though again I am myself very much of a neophyte and it's been a while since I worked on this specifically.
|
The resulting queue with this solution comes out backwards so when the GoapAgent "peeks" at it the result is the last node in the queue rather than the first one to be executed. Reversing the queue negates a lot of the speed improvements that the regressive search may have obtained. In tests, with this in place, the regressive search with two actions actually came out slower for me (146ms vs 92ms). |
@vi-jasonm so use a Stack instead of a Queue. |
I would suggest going backwards makes more sense when pathfinding to endState.
https://github.com/sploreg/goap/blob/master/Assets/Standard%20Assets/Scripts/AI/GOAP/GoapPlanner.cs#L93
That way you give the AI a higher chance of finding a solution that works instead of a predefined set of actions that give you the result.
In other words, you should match
endState
withpostEffects
and the action'spostEffects
with next actionspreConditions
or existingstartState
.endState
->postEffects
->preConditions
/startState
Though you want to make sure to always check against the
startState
for every action because you could end the planning earlier since it might just be sufficient enough from where you are.The text was updated successfully, but these errors were encountered: