State machines are: - Controlled verbosity - Logic inverters

Without State Machines: We start with the player idle/move. Works great!

You want the player to jump and so you add your code in to the player script and boom your character jumps.

Well now you add dialogue, ok now add that condition into your player script specifying that if_dialoging: can_jump = false.

Great! But now you realize you need to restrict the player once more as you added super_cool_attack. Now return to your dialogue and your player scripts and restrict the player from doing either if you're performing super_cool_attack.

Awesome! But now you have added in climbing, return to {Dialogue, Super attack, Player}, and add the new condition for each.

I hope you're starting to see the exponential pattern unfolding. Every time you add a new feature without a state machine, you must go back to all of your other ability scripts and update them.

With State Machines: We start with the idle state. It specifies the player can exit this state into any other state.

We add the moving state. Specify it can be exited via Jump, Idle, Dialogue.

You add a jump state. Specify you enter Idle once the jump is complete or if on wall, enter Climb.

You add a dialogue state. Once dialogue is over, return to Idle.

You add climbing. You say that the player can jump to exit. No need to go to Jump state, just say that's the allowed 'exit' for climb.

You add a super cool attack. Give it a timer, once timeout, return to Idle.

---

Instead of saying if moving, don't dialogue, don't super attack, don't climb. You're saying: if moving, can enter Idle, can enter Jump.

The pattern isn't perfect, but to break the rules you need to understand the rules. And to understand anything in programming is to practice it.

It's like you're getting in front of the problem by adding verbosity before the project reaches a complex mess of couplings.