Gaming

20585 readers

408 users here now

Sub for any gaming related content!

Rules:

1: No spam or advertising. This basically means no linking to your own content on blogs, YouTube, Twitch, etc.
2: No bigotry or gatekeeping. This should be obvious, but neither of those things will be tolerated. This goes for linked content too; if the site has some heavy "anti-woke" energy, you probably shouldn't be posting it here.
3: No untagged game spoilers. If the game was recently released or not released at all yet, use the Spoiler tag (the little ⚠️ button) in the body text, and avoid typing spoilers in the title. It should also be avoided to openly talk about major story spoilers, even in old games.

founded 5 years ago

MODERATORS

Metallinatus@lemmy.ml

peternile@lemmy.ml

553

Don't forget to make a 2nd save file just in case. (lemmy.ml)

submitted 4 days ago by UltraGiGaGigantic@lemmy.ml to c/gaming@lemmy.ml

45 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] JackbyDev@programming.dev 6 points 3 days ago (1 children)

Or even just "Has the menu been closed since it was saved?"

[–] Lifter@discuss.tchncs.de 1 points 3 days ago (2 children)

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.

[–] JackbyDev@programming.dev 1 points 2 days ago (1 children)

Literally a single boolean lol

[–] Lifter@discuss.tchncs.de 1 points 2 days ago

It's the "don't mess it up" part that is harder.

[–] JustAnotherKay@lemmy.world 1 points 3 days ago (1 children)

Do you not need to store that state to pause the game anyway? How else would you end the menu loop?

[–] Lifter@discuss.tchncs.de 2 points 2 days ago (1 children)

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.

[–] JustAnotherKay@lemmy.world 1 points 2 days ago (1 children)

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

[–] Lifter@discuss.tchncs.de 2 points 6 hours ago (1 children)

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.

[–] JustAnotherKay@lemmy.world 1 points 6 hours ago (1 children)

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

[–] Lifter@discuss.tchncs.de 2 points 5 hours ago (1 children)

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?

[–] JustAnotherKay@lemmy.world 1 points 5 hours ago

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