Ok, I mentioned a state machine in another sub thread. It’s not as bad if you already have a state machine.
It’s still adding more complexity though - again when the value is updated. You still need to change the state when saving. You need to decide which state to use when starting the game.
There is still risk of screwing that up when refactoring. And still the value is nearly none.
Regarding state mchines, it’s a complexity in itaelf to add random flags ro the state machine. Next time you want to add another flag you need to double all the states again, e.g. PAUSED, PAUSED_AND_SAVED, PAUSED_AND_MUTED, PAUSED_AND_SAVED_AND_MUTED. I would never add mute to the logic of the menu but that’s the pnly example I could come up with. Maybe you see my point there, at least?
Complexity being added at updating also feels wrong to me. Let me pseudo code some rust (just the language I know best off the top of my head right now) at you, cause it feels like maybe I’m just not understanding something that’s making this seem easier than it is.
Enum Game_State
Paused
Paused_Saved
Running
Loading
Exit
///Technically you could make Menu() part of the enum but I'd probably leave it elsewhere
Match Game_State
Paused => Menu()
Paused_Saved => Menu()
Running => Main_Loop()
Exit => Exit()
And then your other functions always return a game_state. You’re right that adding that return would be a huge undertaking if it’s not handled in the initial building of the game, but it’s a QoL for the user that’s easily maintainable and is therefore worth doing IMO. But these two things, defining the possible game states and then always routing decisions through that game state, makes this kind of feature relatively doable
Ok, I mentioned a state machine in another sub thread. It’s not as bad if you already have a state machine.
It’s still adding more complexity though - again when the value is updated. You still need to change the state when saving. You need to decide which state to use when starting the game.
There is still risk of screwing that up when refactoring. And still the value is nearly none.
Regarding state mchines, it’s a complexity in itaelf to add random flags ro the state machine. Next time you want to add another flag you need to double all the states again, e.g. PAUSED, PAUSED_AND_SAVED, PAUSED_AND_MUTED, PAUSED_AND_SAVED_AND_MUTED. I would never add mute to the logic of the menu but that’s the pnly example I could come up with. Maybe you see my point there, at least?
Complexity being added at updating also feels wrong to me. Let me pseudo code some rust (just the language I know best off the top of my head right now) at you, cause it feels like maybe I’m just not understanding something that’s making this seem easier than it is.
And then your other functions always return a game_state. You’re right that adding that return would be a huge undertaking if it’s not handled in the initial building of the game, but it’s a QoL for the user that’s easily maintainable and is therefore worth doing IMO. But these two things, defining the possible game states and then always routing decisions through that game state, makes this kind of feature relatively doable