1
\$\begingroup\$

I ended up coming up with having states within game states. For example:

States

  • splash
  • menu
  • tracks
  • garage
  • loading
  • play

What bothers me is that I now have states within the play state to handle it based on the vehicle states:

  • vehicle_flipped
  • vehicle_damaged
  • vehicle_out_of_fuel

Which just doesn't sound right. I was thinking of merging the play state's states with the game states, but then it feels like I am hacking when I juggle the box2d world through the game state manager to another game state.

Any ideas on how to approach this dilemma?

Improve this question
\$\endgroup\$
1
  • 1
    \$\begingroup\$ Your first thought is the correct one: it's perfectly normal to have states within states. As long as the state machines handle different items. \$\endgroup\$
    – Vaillancourt ♦
    Sep 20, 2015 at 22:30

1 Answer 1

Reset to default
2
\$\begingroup\$

In your situation, having states within states is perfectly acceptable and is often the expected architecture.

Here is something to think about: generally, during development, you could start your game directly in the "play" state (you set up a bunch of parameters that would normally be set up by the previous state), and you make the game end instead of it going to the next state (the one after "play", e.g. leader boards display, share on your social networks, etc.).

This makes your "play" state a self contained activity. Making the play states member of the game state machine would break the encapsulation of the game logic, and force you to use unclean code in state transition.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .