DeX3
DeX3

Reputation: 5539

Can this be modeled in a state machine pattern?

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

Answers (1)

Andrei
Andrei

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

Related Questions