I'm confused about the State pattern. I'm aware of the main purpose of the State pattern which is to implement state switching using state objects instead of a hard coded switch statement to reflect a FSM. However my confusion comes from it's applicability in game AI.

Are the state object responsible for core game entity AI and logic, or they just play one rule which to transit from one state to another based on a set of conditions? In this case, would not these conditions somehow govern the AI/logic of the entity? In this sense would not be appropriate to delegate all the AI to the state objects?

Maybe I'm missing the game here, but could someone please shed me on some situations or examples that clarify this further. all the examples I found in pattern books and tutorials are plain simple and superficial.

Thanks.

Quote:Original post by Sambori

However my confusion comes from it's applicability in game AI.

class Thinker {  void update() {    actual_thinker->update();  }  void set_behavior(Thinker * t) {    actual_thinker = t;  }private:  Thinker * actual_thinker;};thinker * t = ...t->set_behavior(idle_behavior);...t->set_behavior(combat_behavior);...t->set_behavior(sleep_behavior);... // meanwhile, elsewherewhile (running) {  t->update();}

State pattern is merely one way of selecting different actions over same instance of an object. A switch statement works just as well, so do scripts, function pointer tables, delegates, ...

Quote:all the examples I found in pattern books and tutorials are plain simple and superficial.

Because that is all patterns are.

First, understand the problem you're trying to solve. The solution will likely resemble one or more of patterns. But patterns will do absolutely nothing to help find the solution.

There is no reason why one would actually need State pattern for any of the above, but some solutions might end up implementing it.

Got it! Thanks.

Antheus: that looks more like the "Strategy" pattern to me, am I right?

I see one application of the Strategy and State patterns in game objects as follows:

Strategy: to handle variations of some AI algorithm. For example, a game character may utilize different pathfinding strategies based on the situation.

State: mainly represents the transition logic of high level game character states such as: Attack, Patrol, Escape, Collect Resources, while lower level states such as Run, Walk, Step, Jump, Fire, can be handled through a different object since they are more a representation of the object than an actual AI state.

Quote:Original post by Sambori
Strategy: to handle variations of some AI algorithm. For example, a game character may utilize different pathfinding strategies based on the situation.

Good in theory, but after considering how many systems need to be touched by pathfinding, strategy pattern is the least of problems.

Quote:State: mainly represents the transition logic of high level game character states such as: Attack, Patrol, Escape, Collect Resources, while lower level states such as Run, Walk, Step, Jump, Fire, can be handled through a different object since they are more a representation of the object than an actual AI state.

As said, any GoF pattern can be used. But it doesn't solve anything of use. It's merely two ways to structure data, neither of which particularly helps.

For rich AI, the complexity of interactions is the problem. How to avoid various rule conflicts (A talks to B every Sunday to trigger an event only if mood > 20 and it's raining, but B takes vow of silence on Sundays, meaning event will never trigger). Here various rule-based systems and perhaps even constraints programming may help. Using scripting or declarative or functional approach can help.

For fast AI, there are many bottlenecks. While optimizing code may help, different strategies may need to be used, so encapsulation as provided by various patterns becomes limiting factor. Instead, one prefers to simply operate over entire state at same time. Rather than pretending all actions are opaque (oh, I do not want to know what A will do on update()) it instead makes sense to group items by behavior (all idlers updated at same time, on each update up to 15 will scan up to range 5 to see if anything happened).

In both cases shoehorning anything into forced abstraction doesn't bring any tangible benefits. Especially in statically typed languages, where either number of interfaces or complexity of interfaces quickly gets out of control.

This is the problem of patterns - they don't provide any useful answer. Even though most AIs are defacto strategy pattern and while each one does contain state subject to some rules, knowing this in advance does absolutely zero when developing any meaningful solution.

Once you're familiar with intricacies of such tasks, you'll go back and say "of course, it's like strategy pattern except with XYZ". But the other way doesn't work.

To understand AI, study the actual AI. Don't start with patterns, they don't teach anything useful.

Anti-patterns! ;)

Patterns can greatly help setting up an object oriented game framework that can be used in different genres. Regardless of the AI used or the presentation of various in game objects, the design should scalable and maintainable.

With patterns I can create such a system, which is a completely abstract and then let a different team of programmers plug their AI logic and rendering.

I agree Patterns will not solve flow of logic of objects, but it will provide a beautiful and elegant way to implement objects that will represent various aspects of the game.

Quote:Patterns can greatly help setting up an object oriented game framework that can be used in different genres.

And anal sex is great because it works on all genders.

Quote:With patterns I can create such a system, which is a completely abstract and then let a different team of programmers plug their AI logic and rendering.

Abstraction over what? Plugs into what? What does this have to do with AI or rendering?

Quote:I agree Patterns will not solve flow of logic of objects

Which is a big problem, since AI is all about flow of logic.