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
I’m sorry I don’t getting your point . You start off by agreeing that you don’t like the extra complexity that the update statements give. Then do some pseudo code of something entirely different where we all already agree is not an issue.
Then at the end your conclusion is that it is totally feasible. Why? You still didn’t adress the problem of updating the state
My point was “are state machines really that complicated? Isn’t it just something like this pseudo code and a return value from your functions?”
Basically I feel like this is a 2 step process but you seem like you either know more than I do or have a different philosophy about how this would be implemented, so I want to understand what I’m missing
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
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.
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
I’m sorry I don’t getting your point . You start off by agreeing that you don’t like the extra complexity that the update statements give. Then do some pseudo code of something entirely different where we all already agree is not an issue.
Then at the end your conclusion is that it is totally feasible. Why? You still didn’t adress the problem of updating the state
My point was “are state machines really that complicated? Isn’t it just something like this pseudo code and a return value from your functions?”
Basically I feel like this is a 2 step process but you seem like you either know more than I do or have a different philosophy about how this would be implemented, so I want to understand what I’m missing