###State machines seem to cause harmful dependencies in component-based architectures.###

1. How, specifically, is communication handled between a state machine and the components that carry out state-related behavior?
2. Would Goal-Oriented Action Planning help at all? It seems like a possible solution.

Where I'm at:

• I'm new to component-based architectures.
• I'm making a fighting game, although I don't think that should matter.
• I've found this state-management technique to be the most natural AI system for a component-based architecture, but it conflicts with techniques I've read about: Dynamic Game Object Component System for Mutable Behavior Characters It suggests that all components activate/deactivate themselves by continually checking a condition for activation.
• I think that actions like "running" or "walking" make sense as states, which is in disagreement with the accepted response here: How to transition between states and mix states in a finite state machine?
• I've found this useful, but ambiguous: How to implement behavior in a component-based game architecture? It suggests having a separate AI component that contains nothing but a state machine. But, this necessitates some kind of coupling between the AI component and nearly all the other components. I don't understand how this coupling should be handled. These are some guesses:

A. Components depend on state machine:
Components receive reference to AI component's getState(), which returns an enumeration constant. Components update themselves regularly and check this as needed.

B. State machine depends on components:
The AI component receives references to all the components it's monitoring. It queries their getState() methods to see where they're at.

C. Some abstraction between them
Use an event hub? Command pattern?

D. Separate state objects that reference components
State Pattern is used. Separate state objects are created, which activate/deactivate a set of components. State machine switches between state objects.

• I'm looking at components as implementations of aspects. They do everything that's needed internally to make that aspect happen. It seems like components should function on their own, without relying on other components. I know some dependencies are necessary, but state machines seem to want to control all of my components.