How do I clean up state transitions in a game character state machine?

[ScottNL]

I’ve been trying to implement a proper state machine for my player character, but I’m stuck on how to cleanly handle the transitions between movement, attack, and hit-stun states without everything becoming a tangled mess of boolean checks. My current setup feels brittle, especially when I need to prioritize one state over another.

[Emma_M]

I have been there I ended up with a tangle of booleans that fought each other when inputs came in at the same moment Movement could start an attack and hit stun overlapped and the code would flip directions I tried a tiny state list with a current state and a few checks but the transitions felt brittle every time a window shifted I ended up rewriting the same logic again and again

[OliviaW]

One thing I did was to fold the decisions into a tiny map of priorities but it still leaked when the input arrived during a move I kept a guard that blocks state changes during critical frames and I measured frame length and window hits I saw occasional misses of a cancel which told me the problem is not fixed yet I ended up moving the logic into the animation events and that helped a little but not enough

[David98]

Do you think the real bug is timing not the states I have wondered this myself when hit stun and movement feel off while inputs arrive at odd moments the logic keeps chasing a state that was never ready to switch I tried to push more of the decision into the animation system and that loosened things a bit but it still did not feel solid

[Eric59]

Another angle I tried was not to chase a perfect cycle but to allow the current frame to decide if a transition might happen I let the update run with a one frame bias this kept the code calm for a while and I watched the flow in a replay with a few tests the feeling is not clean yet and I am not sure where to go next