Reputation: 5539
I wanted to model a game (for practice reasons) using a state machine design pattern involving the following states:
However, after reading up on the state machine pattern, it appears to me that it is only applicable when the states all expose a common interface (e.g. the handleInput
-method in this article: http://gameprogrammingpatterns.com/state.html).
What I intended to have is for the Game to have a publish
method in the initial state, that will guide it into the Published
state, where it then has a join
method, which will guide it to Ready
once enough players have joined, and so on.
The goal is to separate concerns here, I don't want a huge Game
class having to deal with gathering all the players as well as handling the actual game logic.
Can this be done with a state machine? Or is there any other design pattern I could use for this?
Upvotes: 1
Views: 91
Reputation: 5005
The states
expose a common interface but, this has nothing to do with your actual game.
The minimum requirement is to have the set of transitions
from one state
to the next and a mechanism to create the resulting state
based on the previous state
and the transition
. The common interface deals only with this aspect.
For your initial state
, the host sets some values on a GameConfig
object. Pressing a "Publish" button is the transition to the next state. On the transition handler you need to create a GameLobby
object.
The GameLobby
is created with the game's name and expected number of players and deals strictly with adding players and other lobby related functions (such as player chat, which should also be implemented in their own class).
Here, the transition handler is called each time a player joins the lobby. Only when the total number of players is reached do you transition to the next state, "Game Ready". (If the number of playes is not yet equal to the requirements you can transition to a new GameLobby
object with one extra player if you want to keep things immutable.)
Along with the GameConfig
object, this new state contains a list of Player
objects.
From this state, when the host clicks "Ready", in your transition handler you finally create your GameLogic
object, based on the GameConfig
object and the list of Player
objects.
When the game is won, you transition to the "Finished" state which contains the game's statistics and a final transition to "end program".
Each of these main states can, in turn, contain their own state machines.
So, the state machine related interfaces do not restrict the interfaces of the payload.
I also recommend you separate the part related to displaying items on the screen from the part that determines "what" to display. So, each of those state objects would have something like an Init
method where they generate a list of sprites
that need to be displayed (and attaches any event handlers that are needed for the transitions). A separate object would then take that list and show it on the screen and call the even handlers on user input.
Upvotes: 1