Sounds like you wrote a bug! Time to start debugging.
By debugging you can find out exactly what your program is doing so you can fix it.
Use the above techniques to get the information you need in order to reason about what the problem is.
You can also use Debug.Log(...); statements to find out if any of your code is even running. Don’t assume it is.
Once you understand what the problem is, you may begin to reason about a solution to the problem.
If you post a code snippet, ALWAYS USE CODE TAGS:
How to use code tags: Using code tags properly
Some more possibly-relevant scribblings about FSM finite state machines:
I suggest never using the term “state machine.” Instead, just think:
- I have to keep track of some THING(s)
- That THING might change due to reasons
- Depending on that THING, my code might act differently
That’s it. That’s all it is. Really!! The classic example is a door:
- track if it is open or closed
- if it is open, you could close it
- if it is closed, you could open it
- if it is open you could walk through it
- if it is closed you could bump into it
Wanna make it more complex? Try this:
- put a latch on one side of the door.
- handle all the above with the latch locked or open
This is my position on finite state machines (FSMs) and coding with them:
I’m kind of more of a “get it working first” guy.
Ask yourself, “WHY would I use FSM solution XYZ when I just need a variable and a switch statement?”
All generic FSM solutions I have seen do not actually improve the problem space.
Your mileage may vary.
“I strongly suggest to make it as simple as possible. No classes, no interfaces, no needless OOP.” - Zajoman on the Unity3D forums.