That’s harder to implement. Suddenly you need to store that extra state somewhere and don’t mess it up. The last save should already have a timestamp and is immutable. A lot less likely to get bugs that way.
The state “the game is paused” is different from " the game is paused and saved". Sure that could be another key in some atate machine but like above: it’s the “not mess it up” part that is harder.
Plus all the lines to update the state, when the menu is closed, when the game is closed (i.e should it be true or false at startup), when the game is saved obviously.
That’s at least three more lines plus the one you mentioned for no extra value. And again it’s easier to screw it up e.g. while refactoring.
I think we write our code in different enough ways that we’re not seeing eye to eye.
Tracking the state of the game being paused, when the menu is open and when the game is saved can all be a single match statement on a current “game state” variable which just holds “running/paused/paused and saved/exit” and when it becomes exit, it checks the save time. Only 2 lines of code and adding an enumerated state to the variable to add this functionality. Since the variable is enumerated, it’s really difficult to mess it up when refactoring because if you can’t pass the wrong code or else your game doesn’t save or close
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?
Waaay too much trouble to compare the time-of-last-save with minimum-time-to-ask-save. 🙄
Or even just “Has the menu been closed since it was saved?”
That’s harder to implement. Suddenly you need to store that extra state somewhere and don’t mess it up. The last save should already have a timestamp and is immutable. A lot less likely to get bugs that way.
Do you not need to store that state to pause the game anyway? How else would you end the menu loop?
The state “the game is paused” is different from " the game is paused and saved". Sure that could be another key in some atate machine but like above: it’s the “not mess it up” part that is harder.
I feel like I’ve seen a “Time since last save:” line on enough games to find it hard to believe that “paused and saved” is difficult to check for lol
These are variables that already exist in most games, it just needs one more line of code to check them
Plus all the lines to update the state, when the menu is closed, when the game is closed (i.e should it be true or false at startup), when the game is saved obviously.
That’s at least three more lines plus the one you mentioned for no extra value. And again it’s easier to screw it up e.g. while refactoring.
I think we write our code in different enough ways that we’re not seeing eye to eye.
Tracking the state of the game being paused, when the menu is open and when the game is saved can all be a single match statement on a current “game state” variable which just holds “running/paused/paused and saved/exit” and when it becomes exit, it checks the save time. Only 2 lines of code and adding an enumerated state to the variable to add this functionality. Since the variable is enumerated, it’s really difficult to mess it up when refactoring because if you can’t pass the wrong code or else your game doesn’t save or close
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?
Literally a single boolean lol
It’s the “don’t mess it up” part that is harder.