The State Pattern

This topic is 2626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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.

Share on other sites
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.

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

Share on other sites
The strategy pattern has a connotation of being sort-of single-use, but there's so much overlap that the State Pattern or any variation thereof, like Antheus's code, could very easily be considered an instance of the Strategy pattern, and nobody could prove it wrong. [grin]

Share on other sites
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.

Share on other sites
Quote:
 Original post by SamboriStrategy: 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.

Share on other sites
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.

Share on other sites
Quote:
 Original post by SamboriAnti-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.[/b]

The items I have enboldened are subjective terms, open to interpretation and their application to design patterns are a matter of opinion. You cant prove or disprove any claim involving these terms.

If your decision to enforce the use of various design patterns is derived from subjective arguments, then you have to agree with everybody else you are working with that these things apply; otherwise, you'll probably find that nobody agrees with you, and then your patterns will be hindering the actual development process.

Ultimately, the decision to enforce the use of a design pattern comes down to the personal preferences of the people you are working with. It's always very frustrating when somebody attempts to use subjective arguments as logical arguments, which due to their intent, have to be objective.

Share on other sites
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.

Share on other sites
Quote:
 Original post by SamboriPatterns 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.

You're doing it wrong!

This type of mentality is exactly backwards from the intended usage of patterns, which is largely the reason they have gained a bad reputation with experienced developers.

The idea of patterns was to develop a shared vocabulary to simply describe commonly-used techniques employed to solve specific problems. This mentality suggests that you are looking at a design and asking what patterns are applicable, which often results in bloated and overly-complex codes.

That's not to say that you shouldn't use a state pattern or a factory pattern, but rather that your decision to use such a pattern should be because that's what solves the problem correctly. The fact that it is a pattern is incidental to your decision.

Quote:
Original post by Antheus
Quote:
 all the examples I found in pattern books and tutorials are plain simple and superficial.
Because that is all patterns are.

QFE. The reason all the pattern examples in those books seem simple and superficial is because they are. The reason why they are is because patterns are a descriptive language for programming techniques, not a how-to coding cookbook.

Share on other sites
Anti-patterns again! :D

Share on other sites
Quote:
 Original post by SamboriAnti-patterns again! :D

You keep saying that. What do you think that means?

Share on other sites
LoL it's an Anti-Pattern pattern in some replies. But no I don't mean the Anti-Pattern pattern.

Share on other sites
Quote:
 Original post by SamboriLoL it's an Anti-Pattern pattern in some replies. But no I don't mean the Anti-Pattern pattern.

"Anti-patterns" isn't a pattern, its a phrase for describing a group of coding techniques that are generally considered to be bad. And you did not address any of the actual points in the posts that you think are "anti-pattern." I'm not sure what you plan to accomplish by posting "Lol anti-patterns," other than stating "Patterns good!"

Its still the case that you are using patterns in the wrong manner by taking patterns and looking for a problem to solve with them, rather than vice-versa.

Share on other sites
Show some respect dude. Don't ever underestimate others' abilities and expertise.

"Prejudice Pattern"

"Nerdy Talk Pattern"

"Needless Enthusiasm Pattern"

Avoid such an attitude at interviews. This will never get you a job in the software industry.

Share on other sites
Antheus, lets see here what you have

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

Watch your words. You are not arguing with your bitch here. This is a professional forum and keep on mind that many people are highly professional and older than you. So show some respect.

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

If you understand the main principles of object oriented paradigm, the design patterns are just a way to apply those principles to various problems, and all are centered around the principle of Abstraction - don't mix terms with something like ADT.

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

I'm talking about "patterns" not "AI" idiot!

Share on other sites
In an attempt to salvage the thread, all of us were just wondering what you meant when you kept saying "anti-patterns", because you didn't really elaborate beyond that and have been quite vague and a bit off-topic since you first mentioned them. There is a standard definition for anti-pattern, is that what you're referring to? If so, could you expand a little on where you see them?

Share on other sites
Quote:
 Original post by SamboriWatch your words. You are not arguing with your bitch here. This is a professional forum and keep on mind that many people are highly professional and older than you. So show some respect.

I have a funny feeling that Antheus may have more professional experience than you.

Share on other sites
Quote:
 Original post by SamboriAntheus, lets see here what you have "And anal sex is great because it works on all genders."Watch your words. You are not arguing with your bitch here. This is a professional forum and keep on mind that many people are highly professional and older than you. So show some respect.

I don't see where he offended you.

The point as I understood it: Some people like anal sex, some don't, some are gay, some are hetero, some are bi, and so on. But simply because anal sex and other anal practices fit everyone physically does not mean that everybody must like it and that it's appropriate in every sexual situation (e.g. it is not appropriate to make children, or when the partner does not like it).

But maybe that's the german in me. Germans can be unsound sometimes, but the English and French can, too. Dunno what Antheus is. Ever seen Braveheart? Netherlands are not bad, also. Heh, don't take it personally.

Share on other sites
Quote:
 Original post by SamboriI'm talking about "patterns" not "AI" idiot!

Uh, your strange quotations made me miss this part. Really, calm down now.

Share on other sites
Quote:
 Original post by SamboriThis is a professional forum and keep on mind that many people are highly professional and older than you. So show some respect.

Quote:
 Original post by SamboriAvoid such an attitude at interviews. This will never get you a job in the software industry.

Talking down to us is not likely to win you any points in the discussion. Plenty of us are professionals, you know, and likely have more experience than you. None of that really amounts to anything on an online forum -- what matters is whether you can argue your case. From my point of view, you have failed to do so, and are now trying to appeal to your own authority.

Quote:
 Original post by SamboriI'm talking about "patterns" not "AI" idiot!

Go back and re-read your original post. You absolutely are talking about AI. It would be wise to avoid calling people idiots.

Share on other sites
The best design comes from figuring out what materials and techniques you need to build the bridge before determining how big it has to be or what kind of load it has to bear... Right?

Share on other sites
I am aware of a growing community of developers who dislike patterns (or specifically, the design by patterns school of thought), but consider the following:

Most introductory books on OO languages and computer science curricula only go as far as to say "OO is about inheritance" or something else as naive and as shallow. Very few books and courses provide any real insight on how to build real software systems using OO techniques. Patterns, on the other hand, provide a systematic approach to teaching/learning these techniques that would otherwise have to be learned through years of trial and error and studying other people's code.

Furthermore, patterns are so broad and generic, everything you would write beyond "hello world" is covered by at least one. I would argue that if a programmer introduces unnecessary complexity by designing with patterns, its because they don't have a complete knowledge of the problem they are trying to solve, their programming language (and it libraries), or design patterns themselves. The work of bad software engineers who design by patterns is not a testament to the merit of designing by patterns.

If anything, patterns (both as a vocabulary and design philosophy) encourage structure, consistency, and robustness.

Share on other sites
Quote:
 Original post by samgzmanI am aware of a growing community of developers who dislike patterns (or specifically, the design by patterns school of thought), but consider the following:Most introductory books on OO languages and computer science curricula only go as far as to say "OO is about inheritance" or something else as naive and as shallow. Very few books and courses provide any real insight on how to build real software systems using OO techniques. Patterns, on the other hand, provide a systematic approach to teaching/learning these techniques that would otherwise have to be learned through years of trial and error and studying other people's code.Furthermore, patterns are so broad and generic, everything you would write beyond "hello world" is covered by at least one. I would argue that if a programmer introduces unnecessary complexity by designing with patterns, its because they don't have a complete knowledge of the problem they are trying to solve, their programming language (and it libraries), or design patterns themselves. The work of bad software engineers who design by patterns is not a testament to the merit of designing by patterns.If anything, patterns (both as a vocabulary and design philosophy) encourage structure, consistency, and robustness.

Well, actually first you present this: "I am aware of a growing community of developers who dislike patterns (or specifically, the design by patterns school of thought)" You're trying to push conjecture here because those are two completely separate facts. You are asserting A == B and it doesn't.

I agree with the second part of that.

Moving on, patterns are great conceptual tools for both referencing and for standardizing common implementation strategies. The major problem only really comes into play with new programmers without any real experience with them misappropriating the purpose and trying to retrofit design patterns into problems instead of solving problems with design patterns.

Not "everything beyond Hello World" is a pattern, most of them are architectural implementations of solved dependency and compositional problems. Many simple medium sized projects don't really make any special attempt at having a standard architecture and often omit the use of patterns pretty much entirely. Only through rigorous refactoring would they be discovered. I'm not saying this is a -good- thing, just that again, you're making baseless claims that have no ground in reality.

Much larger applications do for sure. Without them you'd end up with the blob anti-pattern (which is what several mid-size projects end up being.)

What software have you developed that you share this insight with us?

Share on other sites

This topic is 2626 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Create an account

Register a new account

• Forum Statistics

• Total Topics
628726
• Total Posts
2984410

• 25
• 11
• 10
• 16
• 14