
The point you were parroting
And again with words in my mouth. That wasn’t even close to my point!
My point was that you were unnecessarily sarcastic in a rude way to someone. Beyond that, your comment made absolutely no sense because you were telling them that they were mad at the tool instead of the way the people are using the tool. Which, if you go back and read their comments, is what they were actually upset about. They didn’t make much, if any comment about AI itself, but rather the way people are using it.

Thankfully this isn’t ubiquitous, at least in my experience. The Hades franchise has its second game in beta (is it still in beta? I haven’t checked in in a few months) with a female lead and I haven’t noticed a peep about that. Hopefully that’s not just the communities I’m part of and it’s actually been received as well as I’ve perceived
Basically “not all gamers” but not in an asshole way haha

While I’m not a fan of either, I think “typing” indicators are a natural response to read receipts unfortunately. Sending a read receipt applies time pressure, because now the other person knows you’ve seen it. So, the “typing” indicator lets them know that you’re working on a response and not ignoring them.
If we just didn’t send read receipts we wouldn’t need “typing” indicators at all. It’s a case of unnecessary complexity causing unnecessary complexity
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
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 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
I think twitch drives this a lot. Streamers getting annoyed with the game they’re playing tend to do better on their vods and bring in more people. As a result, people become more and more tolerant to games that are just annoying.
Like I understand that some people enjoy the gameplay of soulslikes, but who enjoys run backs?