next »

[sevn]

Following along with the book, Game Programming Patterns, I've been studying the State Pattern and want to continue discussion on here about it.

The most obvious use cases and the one listed in the book is to do with character states. Idle, Walking, Running, Jumping etc... For game programming it seems most useful when dealing with game objects that have a bit of complexity. Anything that is animated and interactive.

It could also be used for game states as well. Apart from that, I can't think of many other places where you'd use state pattern. What other times would the state pattern be good for?

[CutterSlade]

Enemy AI is definitely one of the places you'd use it.

[SirEel]

Player input handling as well: you might have different controls while running, vs swimming, vs piloting a vehicle.

My personal rule is that if I've got an enum, and a lot of separate functions are switching on it and there's a lot of code in that switch, then I should be using a state machine.

[Boreal]

I'd say that state machines (I don't like "design patterns") are applicable to pretty much any user interface element, be it a GUI control or a player input handler.  Anything where you can gain from turning a switch statement within the game loop into polymorphic state objects.

[sevn]

Enemy AI is definitely one of the places you'd use it.

Ah yes! of cause. I'm not experienced enough in AI to give examples, but I could imagine AI design would benefit greatly from hierarchical states and state stacking. Especially when simplifying the designs of very complex AI.

[zerooneinfinity]

I worked on a pretty complicated mechanic that I made into a state machine so I could step through to debug it in real time.

[InfiniteStateMachine]

Enemy AI is definitely one of the places you'd use it.

Ah yes! of cause. I'm not experienced enough in AI to give examples, but I could imagine AI design would benefit greatly from hierarchical states and state stacking. Especially when simplifying the designs of very complex AI.

Watch out for state stacking/layering. That's WAY harder to debug.

[zath]

State pattern might be used when implementing own network protocol for multiplayer mode. You got connection, authentication, then main gameplay states. When user got disconnected protocol might be switched to another state to handle this situation properly. I like having mutliple layer of States - So every State might also contain a State Machine. This way complicated protocol is divided into more maintainable pieces. Also adding new features is just a matter of adding new state here and there.

My recent idea is to use this pattern to implement a complex puzzle mechanics. User is given a set of inputs he might somehow enable/disable. Input might be a switch, a trap, or god's altar. User operates on these inputs and change its values. Next thing is Transition table. It is responsible for having a knowledge what should be a next state for given current state and given input changes. It might also activate set of outputs when transition happens. Output might be a door, bridge, moving wall, enabled/disabled water pump. Things like that.