Pattern for State Transitions in a Game?

[Jimmy Ho]

Hi, all, I'm architecting a small game engine using Java/JBOSS/Hibernate, and just wanted to ask if there are any known patterns for handling the state of the game? It's a simple card game I'm doing more as a portfolio item to show employers, so it has some simple states like, Waiting for More Players, Round in Progress, Waiting for Player X to Play Card, or whatever. It'll keep track of player scores, manage a small chat room, have a couple of card decks as data, etc.

Thanks!

[K. Tsang]

Hi Jimmy

Are you familiar with the Gang of Four patterns? The patterns and their description are listed here.

[Jimmy Ho]

Yeah, there's a State Pattern that manages states, but all the toy examples I can find are for states where the possible inputs are the same, regardless of the state. There are some semi-ugly modifications to the pattern when each state has different actions possible.

Example:
State1: Can mouse click in the drawing canvas
State2: Can mouse click, but results in different behavior
State3: Can mouse click, but results in different behavior

But in my game:
State1: Actions to recruit more players to the game via Facebook (or something)
State2: Repeating rounds of playing cards, and each player plays a card (or something)
State3: Game shutdown, with buttons to post results to Facebook (or something)

Each "state" has a different set of methods/actions associated with it, and the State pattern, as written, doesn't seem to accommodate it well.

[K. Tsang]

Well the "state" pattern may not be the one you need. Honestly, I'm also learning patterns so can't give too much advice.

From what I see your states are really actions or even use cases.

Think simple at first.

[Ulf Dittmer]

Not sure about patterns, but maybe using a finite state machine library would help? http://stackoverflow.com/questions/10875317/recommended-fsm-finite-state-machine-library-for-java lists several, some of which seem dead, some quite complex, but a couple (like https://github.com/oxo42/stateless4j/) look promising, IMO.

[Jimmy Ho]

Thanks! I'll look into these!

[E Armitage]

In the state pattern an object changes its behavior when its state changes. Think of it as one method that performs different operations when the value of a property changes e.g one displayEmotion method that displays a sad crying face when the emotion (emotion is the state) is sad and a smiling face when the emotion is happy e.t.c. For you to fit the state pattern to your program you would need to have an action that you call which implements different behavior when the game is in different states. If you don't have such an operation then state won't fit very well.
A state machine can be useful if you have many possible states but a set of rules which decide which state transitions are allowed. If you don't have that then I think a state machine could be overkill.
Form your description I am inclined to think that you can use patterns related to event driven architectures because you seem to have waiting periods and actions are triggered by events that have occurred.

[T. Sharma]

Jimmy Ho wrote:
Yeah, there's a State Pattern that manages states, but all the toy examples I can find are for states where the possible inputs are the same, regardless of the state. There are some semi-ugly modifications to the pattern when each state has different actions possible.

Example:
State1: Can mouse click in the drawing canvas
State2: Can mouse click, but results in different behavior
State3: Can mouse click, but results in different behavior

But in my game:
State1: Actions to recruit more players to the game via Facebook (or something)
State2: Repeating rounds of playing cards, and each player plays a card (or something)
State3: Game shutdown, with buttons to post results to Facebook (or something)

Each "state" has a different set of methods/actions associated with it, and the State pattern, as written, doesn't seem to accommodate it well.

Hi Jimmy,

When you want to model a state machine, state design pattern could be really useful. However, I can relate to your concern also. Probably, you need to consider combination of patterns. For instance, if a state change could occur due to one of the different sources, then using Strategy with each state might solve your problem. Similarly, if you have a state machine for each state, then you may consider state pattern (for finer-grain state machine) for each state of state pattern (for coarser-grain state machine).

[Ryan McGuire]

Jimmy Ho wrote:
Yeah, there's a State Pattern that manages states, but all the toy examples I can find are for states where the possible inputs are the same, regardless of the state. There are some semi-ugly modifications to the pattern when each state has different actions possible.

Example:
State1: Can mouse click in the drawing canvas
State2: Can mouse click, but results in different behavior
State3: Can mouse click, but results in different behavior

But in my game:
State1: Actions to recruit more players to the game via Facebook (or something)
State2: Repeating rounds of playing cards, and each player plays a card (or something)
State3: Game shutdown, with buttons to post results to Facebook (or something)

Each "state" has a different set of methods/actions associated with it, and the State pattern, as written, doesn't seem to accommodate it well.

In your case, each state doesn't really have a different set of methods. It's just that each state pays provides non-trivial implementations for a small subset out of a larger set of possible methods. For instance, the State base class may define methods like HandleAddAPlayer() and HandleMakeAMove(). The AddingPlayersState will have an "interesting" implementation for HandleAddAPlayer() but a HandleMakeAMove() implementation that is nothing but a return statement (or maybe it throws an IllegalStateException). In contrast, the MakingMovesState would be just the inverse of that.