Seeking guidance FSM, physics, synchronized state machines?

Unity Engine
1

Hello, I’m pretty new to game development but I’m having a lot of fun with it! I have two issues I’m dealing with right now that I’m hoping to get some guidance on.
They’re both related to finite state machines.
My states inherit from IState (not a MonoBehaviour), and my state machine is a MonoBehaviour.
The StateMachine class has ChangeState(IState newState) and ExecuteStateUpdate().

The object that the state machine is attached to will call ExecuteStateUpdate() in its Update().
ExecuteStateUpdate() calls the current state’s CheckConditions() to see if there’s a new state to change to, and then calls the state’s Execute().

Anyways, here are the two issues I have:

  1. So each state watches its user’s input and reacts to these inputs. Many of the states contain physics usage like AddForce(). Isn’t this a conflict? I heard that physics calls need to be in FixedUpdate() and user input needs to be in Update(). So then, let’s say we put the StateMachine’s ExecuteStateUpdate() inside FixedUpdate() instead of Update(), we then have the problem of the inputs being read in FixedUpdate() instead of Update(). Any ideas? Is there another kind of state machine that I should be aware of that uses both Update() and FixedUpdate()?

  2. Each StateMachine class calls CheckConditions(), before ExecuteCurrentState(). Sometimes the ExecuteCurrentState() function will send conditions to another state machine. If we have the case where one state machine sends new conditions to another machine, it will check its conditions, including the ones received from another machine that frame. We can also have the case where a state machine will CheckConditions(), then ExecuteStateUpdate, but then also receive its new conditions later that same frame from another state machine, meaning that it didn’t wait before receiving conditions before checking them.
    I don’t want any of the state machines to operate out of sync like this. I would rather that they all CheckConditions() before any of them begins to ExecuteStateUpdate().

How do people normally accomplish this sort of behaviour? I’m new to programming, but I thought I would share my ideas on how to handle this; maybe some of them are close to the mark!
Idea 1: make use of LateUpate() or LateFixedUpdate().
Idea 2: Have a master state machine that holds a reference to every other state machine, which will call all of their CheckConditions() before calling their ExecuteStateUpdate(). Is this a normal way of handling this? Are there other programming concepts or types of state machines that I should know about that would give me the control I’m seeking?
Looking forward to responses : )

2

Just use both! Gather edge-trigger things such as input in the Update() portion, and set local state specifying to do physics-y things in FixedUpdate().

But beware, ask yourself if you didn’t look at it for a month, could you re-understand it when you picked it up again?

The biggest problem with one-size-fits all attempts to “never again write a state machine” is that now your state machine has to handle ALL kinds of weird behaviors that most state machines never need.

The question you should be asking is, “does writing a universal state machine actually solve my problem?”

I personally would just write the actual state machine I need for each problem I need to solve with a state machine, but YMMV.

Generally with the simplest smallest custom piece of code that unambiguously shows the problem it is solving while at the same time solving that problem, and not solving ANY other problems, or working around ANY other requirements for solving problems not right here and right now.

3

As for 1. In Update() you could record whether the Input you are looking for happened in Update() in a field. Then in FixedUpdate(), you can answer the question “Did input x happen since the last frame?” by reading that field and act on the result of that.

4

Regarding (2) there are two ways that I can see: a) FSM hierarchies, b) FSM priorities.
With (a), FSM are chained tree-like (like transforms in scene hierarchy), where you have top to bottom propagation, and the evaluation has to bubble back.
With (b), FSMs aren’t rigidly linked, but are evaluated in the order of set priorities (similar to how script execution order works). This also allows dynamic re-prioritization.