State machines seem to cause harmful dependencies in component-based architectures.
How, specifically, is communication handled between a state machine and the components that carry out state-related behavior?
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 envision my state machine being used to toggle states like "crouching", "dashing", "blocking", etc.
I've found this state-management technique to be the most natural 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: finite state machine used in mario like platform game
I've found this useful, but ambiguous: How to implement behavior in a component-based game architecture? It suggests having a separate component that contains nothing but a state machine. But, this necessitates some kind of coupling between the state machine 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 state machine component's getState(), which returns an enumeration constant. Components update themselves regularly and check this as needed.
B. State machine depends on components:
The state machine 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.
