Hey all,

As the heading says I'm trying to get my head around Goal Objective Action Planning AI.  However I'm having some issues reverse engineering Brent Owens code line-by-line (mainly around the recursive graph building of the GOAPPlanner).  I'm assuming that reverse engineering this is the best way to get a comprehensive understanding... thoughts?

Does anyone know if an indepth explanation on this article (found here: https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793), or another article on this subject?

I'd gladly post my specific questions here (on this post, even), but not too sure how much I'm allowed to reference other sites...

Any pointers, help or comments would be greatly appreciated.

Sincerely,

Mike

Have you read  the original material on GOAP by its creator, Jeff Orkin?

In general, understanding an algorithm from reverse engineering code is one of the worst ways. It contains an ocean floor full of details that are needed for the implementation, but they make you get totally lost in finding the one or two key ideas at the surface that bring you safely across the pond.

The other direction is much faster. From the key ideas that you read in articles / papers / presentations, you can see the entire structure and understand the idea at global level. With that understanding you can move code of an implementation into the right spot immediately, since its function in the algorithm is clear already. Code here serves as a reference in how exactly they did some sub-sub-sub step in the algorithm.

An alternative is to write your own implementation after reading the articles / papers, to check that your understanding is correct and complete.

As for GOAP, the first hit I got is http://alumni.media.mit.edu/~jorkin/goap.html which looks adequate in resources to get you started. I would suggest you read the various descriptions how it works. As usual with complicated algorithms, there is no single solution, but you can vary parts of the algorithm and tailor them to your specific problem.

Once you understand it, go to your own problem (assuming you have one), and try to find out what parts are relevant for your case, and study those in more detail, until you can write an implementation.

Concur with the above. It's actually not that complicated of an algorithm. Read the concept and you can write your own.

You guys are brilliant! Many thanks!

Alberth - that link was one I came across as well... but mistakenly thought I should handle the Brent Owens "easy" implementation before looking at the more in depth F.E.A.R. examples (and yes, I did think that was ALL that site was showcasing - that'll teach me to skim read!)

IADaveMark - Jeff Orkin! Brilliant, now I have another name to scour for information regarding.  Many thanks for this.

Again, you're both life savers.  Many thanks.

Hopefully, the next post will be of my triumphing over this challenge - #thenoobknowsnothingofwhatstocome

4 hours ago, Tset_Tsyung said:

IADaveMark - Jeff Orkin! Brilliant, now I have another name to scour for information regarding.  Many thanks for this.

What do you think "~jorkin" means in the url I linked? Ie you already have that resource.

I have been looking information too (in particular in robotic context, ie RGOAP), but found very little, much to my surprise. Not sure why that is the case. Perhaps competition from eg Prolog or other methods is too strong?

4 hours ago, Tset_Tsyung said:

#thenoobknowsnothingofwhatstocome

That's always the fun part, you may run into many nice and less nice surprises

Hope you figure it out.

Just so you know. GOAP isn't all that great for many game AI applications. It suffers from having a harder time with complex environments with many verbs (plan time) and when the game state is very dynamic (frequent replanning). That is, most of the time your long, detailed plans get invalidated by the next think cycle and you have to replan entirely.

7 hours ago, IADaveMark said:

Just so you know. GOAP isn't all that great for many game AI applications. It suffers from having a harder time with complex environments with many verbs (plan time) and when the game state is very dynamic (frequent replanning). That is, most of the time your long, detailed plans get invalidated by the next think cycle and you have to replan entirely.

I can see why it doesn't quite work in games. In robotics, time is not that relevant at planning level, state doesn't change often either, while robustness (ie adapting to the environment) is a major problem.

Thanks for the information.

Ah, so are you saying that GOAP isn't so great for games?  If that's the case, what would you peeps recommend?

In case you haven't noticed, I'm a noob when it comes to AI...

I started reading "Programming Game AI by Example" and in there it mentions the 'State Design Pattern' system. (I stopped reading as I realised that the 'free pdf' was actually a pirate and shouldn't have been free... I'll save up and buy a book instead - recommendations would be appreciated).

Again, many thanks for your replies.

What are you trying to implement? AI is not about picking a nifty-sounding algorithm and throwing it at anything and everything under the sun; starting with a solid understanding of the problem you want to solve is key.