Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
20 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to General and Gameplay Programming

The State Pattern

Started by
58 comments, last by snake5 13 years, 6 months ago
Quote:Original post by ApochPiQ
Quote:Original post by M2tM
Finally, one last point, I am not sure if this was directed at me or not:

Quote:ApochPiQ: Also, on a related note, refactoring code to suit a pattern is just boneheaded religion.


When I said this:

Quote: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 meant what I said. I didn't mean refactoring code to suit a pattern, but rather in refactoring structureless blob-like code you'd probably end up formalizing and adding patterns by accident even if you didn't know that's what they were. If my first comment in this thread went unnoticed and people are misreading me by thinking I'm advocating refactoring to suit patterns I strongly urge you to re-read my first post with <sarcasm> tags around it.



No, that wasn't directed at you at all. It was just a general remark. In fact I like your wording a lot - patterns are to be discovered, not driven towards.


Cool, the paranoia kicked in when I read it and realized I said "refactoring" and "patterns" in the same sentence (kinda via reference with "they"). :D
_______________________"You're using a screwdriver to nail some glue to a ming vase. " -ToohrVyk
Advertisement
Patterns form the base of proper O.O design, how objects are related and put together.

How to not violate the main principles of O.O design is by using patterns.

I would say Patterns are Effective O.O ;-)
Quote:Original post by Sambori
Patterns form the base of proper O.O design, how objects are related and put together.


You're stating an unproven assumption. That's certainly not the intention of patterns as discussed by the GoF book. Its possible to have a proper OO design that doesn't use patterns.

Quote:Original post by Sambori
How to not violate the main principles of O.O design is by using patterns.


You don't have to use patterns to follow SRP principles. They're not necessary for abstraction or encapsulation either.

Other posters are correct that any project of sufficient size will have patterns emerge in its implementation, but no-one was ever arguing that using patterns at all was bad.


Quote:Original post by Sambori
I would say Patterns are Effective O.O ;-)


Everyone is entitled to their opinion, but nothing of what you've stated here supports your assertion that patterns are the foundation of good design.
Quote:Patterns form the base of proper O.O design, how objects are related and put together.


1. Many people already have told this - patterns don't form anything, they are simply names for certain pieces of programs that we're using quite often.
2. Discussions have lots of arguments thrown around. You have given us no arguments of any kind that would support these weird claims. So it's hard to call this piece of text a discussion.

SGScript scripting language | GitHub | Pastebin

I disagree. The intent of patterns as of GoF is somehow dated.

My original post was about how to best use the State Pattern in game AI. More specific, where to put the core AI, in state objects, or keep it in the game character object.

Each pattern satisfies all the OO principles.

Each OO principle can be applied using any pattern based on the problem.

Quote:Original post by Sambori
I disagree. The intent of patterns as of GoF is somehow dated.


Any further thoughts on this beyond your own opinion? Given that the GoF is probably the best-known and most-used set of patterns to this day, I'd say that their input is still highly relevant.


Quote:Original post by Sambori
My original post was about how to best use the State Pattern in game AI. More specific, where to put the core AI, in state objects, or keep it in the game character object.


Which shows the problem with your approach and the reason why patterns are descriptive, not prescriptive.

Quote:Original post by Sambori
Each pattern satisfies all the OO principles.


A pattern satisfies OO principles, but not all objects satisfying OO principles are pattern objects. That's the whole point. Patterns are not the base of effective OO, effective OO is the base of patterns. Patterns are descriptive language for common OO techniques.

Quote:Original post by Sambori
Each OO principle can be applied using any pattern based on the problem.


No, just no. A pattern is good for solving a specific problem. Each pattern uses one or more OO principle. A pattern is not applied to implement an OO principle. You're stating this exactly backwards.

Also, you haven't actually supported any of your assertions. Your arguments have been generic to the point of being meaningless.
I think I have problem expressing my original post. Whatever we say about patterns is all generic and biased.

Anyone could support his/her argument so far? No.
Unrelated, but kind of important:

It's worth pointing out in this discussion that many of the GoF patterns are actually pretty strongly tied to the languages they are represented in and are meant to address specific problems encountered in those languages.

Many of them do not have any real purpose in languages which have automatic garbage collection, prototypes (dynamic class modification), or a duck typing built in to the language. Some do, some are implemented differently, but it's an important consideration when making broad statements about GoF patterns being prevalent in -every- program...

In the C++ world, sure, most programs of sufficient size probably do. In other languages you encounter different patterns, or familiar patterns implemented much differently as in PHP or &#106avascript/Actionscript or whatever. It's very narrow to suggest OOP must be based on a set of prescribed patterns. Patterns emerge in everything, but unless your job is to make lace you probably aren't looking to make them.
_______________________"You're using a screwdriver to nail some glue to a ming vase. " -ToohrVyk
Quote:Original post by Sambori
Anyone could support his/her argument so far? No.


Um, yes.

Most everyone here has posted detailed arguments for their points - except for you. Just look at the size of the average post here, compared to the size of your posts. People are putting a fair amount of effort into supporting their arguments. You aren't showing any.


As to your original post: the entire point people are trying to make to you is that your question is broken. You're thinking of the state pattern as something to aspire to, something you should target, something you should try to emulate; this is bad.

Tell us what AI problem you want to solve. Tell us how your game/application is supposed to work. Tell us what you are trying to achieve. Then we can help you come up with a good design.


Trying to use patterns to dictate your design will get you bad results. That is why everyone is belaboring this point so heavily here. We are dealing with your question - you're just not getting the answer you want to hear.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Quote:Anyone could support his/her argument so far? No.

Let's break it down to really simple things:
-patterns came after the code they were first written in -> patterns described already existing, recurring solutions
-OO languages came before patterns -> they weren't designed to fit patterns -> patterns aren't the "center of OO programming"
-not all OO languages can support all patterns -> they weren't designed to fit patterns -> patterns aren't the "center of OO programming"
-people have written OO code in non-OO languages ( http://www.planetpdf.com/codecuts/pdfs/ooc.pdf ) -> how does your idea about patterns being the center of OOP fit in that? :D

I think these are good enough arguments to the idea(--definition of patterns) that patterns don't describe what you have to do, patterns describe what has been already done so that people could just have a name for pieces of code they use often.

[Edited by - snake5 on October 8, 2010 8:13:09 AM]

SGScript scripting language | GitHub | Pastebin

This topic is closed to new replies.

Advertisement

Popular Topics

aigan
The promise of freedom in story games Game Design and Theory
Nosey
Ideas for a new genre (anonimous) Game Design and Theory
KielanT
DirectX 12 Renderer Graphics and GPU Programming
MrK45
Inheriting from application registered class AngelCode
Advertisement

Recommended Tutorials

Kord
Prototyping with Graphs Game Design and Theory
Myopic Rhino
The Physics of Racing Series, FAQ Math and Physics
Myopic Rhino
Introduction to Asset Management with ionForge Evolution Business and Law
Myopic Rhino
Point in a poly II Math and Physics
GameDev.net
Installation Tools for Distributing Your Games Engines and Middleware

Reticulating splines

About GameDev.net
Community Guidelines
Terms of Service
Privacy Policy
Contact Us
Copyright (c) 1999-2024 GameDev.net, LLC
Back to Top