Is a state machine the best way to handle game "modes"?

Unity Engine
1

I’m working on an endless runner, and I’d like to alternate stages with gameplay (e.g. active physics, active scrolling) with non-scrolling merchant/town screens where the player can run around and buy/upgrade equipment. It’s 2d, and the “town” is little more than a nice background and a couple of sprites, so placing gameplay and shopping areas in different levels and loading/unloading them feels like overkill. Is there anything wrong with managing this by creating a global GameManager object, some kind of enumeration to track game state, and switching between gameplay and shopping interfaces by calling some ChangeState(EGameState newState) method, whose job is to determine whether to spawn the scroller/physics gameobjects to start a new level, or delete the existing ones and open the menus/backgrounds necessary to shop?

2

So let’s say state machines is the best way to do it. Do you have a problem executing it? If not, then this isn’t a question since there is no problem to be solved. So rephrase it in such a way that you have a problem to be solved.

3

I use game states as you mentioned, I have only one scene.
I dont delete anything.
I have an Activate() and Deactivate() methods in the GameState class that SetActive(t/f) all the GUI stuff and game play areas in the specific class the inherits from GameState.

There are quite a few people who do it this way and ignore the usual Unity way.

4

I don’t have a problem executing it, I suspect this is more just my endemic tendency to over-analyze broad architecture before implementing the important bits. I know that if you’re properly modularizing things it isn’t a big deal to try the simplest possible solution, build functionality over it, then rip it up and build something better if a problem arises down the road, but I have a chronic tendency to want a project’s foundation to be rock-solid before I put anything properly fun on top if it. (I know that’s backwards, and rapidly iterating over core gameplay is where you should start, but it’s just how my mind works :slight_smile: )

5

My game is basically two games in one (plus a shared UI), and everything is in one scene and managed by a pair of state machines.