33 minutes ago, Tset_Tsyung said:

Ah, so are you saying that GOAP isn't so great for games?

We were just discussing some disadvantages of the GOAP algorithm. All algorithms have strong and weak points. As ApochPiQ says, there is no golden bullet that will solve any AI problem you throw at it (if such an algorithm existed, it would be one and only algorithm in the entire AI field).

You normally select an algorithm that has the strong points you need for solving your problem, while at the same time its weak points don't affect you (much).

In the end, the proof is in implementing the algorithm, and seeing it in action. Implementing it is also great for educational purposes, hands-on learning works best.

@ApochPiQ I don't have a major 'project' at the moment.  I was gonna to try to build a basic 'scene' where a blue cube mines for a resource top buy his escape whilst shooting green cubes that come at him (with grabbing better weapons on occasion) just so I could get used to it.  I would like to try a SMALL horror game in the future where the player is hunted by a monster in the woods (listen to player and watches for flashlight).  I was going to use the first 'scene' to practice GOAP with.

Following on from Alberth's latest comment I suppose I could use this simple scene to practice different styles (FSM, State Design Pattern, GOAP, custom-frankensteins-monster-hybrid, whatever.)

Many thanks for all your replies all.  I think I'm gonna just go and experiment/play with different concepts for a bit.  If I get stuck on something more specific you will probably hear from me... but not after extensive google searches first

Again, thanks all.

Start here:

http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

As for a pirated copy of Mat's book, I don't think he cares. We make about a buck (or less) off these books. His publisher may care, though. Anyway, that's the book we recommend first anyway. That or Millington's. 

On 7/23/2017 at 11:37 PM, 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.

Why not use GOAP for longer term planning or strategies, and supplement with a different system (like a utility system) for shorter term actions/reactions?

Merging architectures based on "time into the future" can sound appealing on paper, but often degenerates into really difficult sub-problems that end up making the whole thing less than ideal.

For example, in your suggested scenario, what happens if I find the utility of an already-formulated plan to be zero? What happens if I plan to do something but ignore its utility? Obviously that's not going to fly, so we have to compromise and integrate utility into the planning heuristics somehow. But now we need to know the utility of future hypothetical gamestates, so all we've really done is complicate both algorithms substantially. The handoff between the two designs is not clear or well defined, meaning that it will be hard to keep the two from polluting each other.

This is of course just an off-the-cuff example. When you get into the weeds of blending architectures, it often turns nasty because of this kind of thing. It is actually pretty hard to find disparate architectures that "hand off" well between them in the general case, when you're talking about time into the future blending. If you're lucky and your particular case doesn't have those thorny edges, cool; but otherwise you end up just writing a lot of special case hacks and workarounds that don't really suit the goal of getting the game done.

Layered architectures are a different thing. That's where you have a system that controls the fine-grained details and one or more additional systems that control the big picture stuff. They are designed to feed data back and forth, and to cooperate. Layering is a good thing and used all the time for things like strategy-vs-tactics distinctions, for example.

Occasionally there are architectures that work well across the "time into the future" spectrum. For example, utility architectures can be set up to do partial planning with some careful forethought. When you have a single solution for a wide range of problems, it's much more appealing to use that solution generally than to try and wire together a bunch of special cases.