###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? Or lookup tables? These seem like potential routes here, but I don't understand them, yet.

**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][1] 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: http://gamedev.stackexchange.com/questions/7906/finite-state-machine-used-in-mario-like-platform-game
- I've found this useful, but ambiguous: http://gamedev.stackexchange.com/questions/8932/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.

 [1]: http://www.josericardojunior.com/docs/DGOCSMBC_SBG08_1.pdf "Dynamic Game Object Component System for Mutable Behavior Characters"