I've been using ECS for a while, at the moment I'm using my own, but it's pretty standard. Components are data only, Entities pretty much just a Map with some additional metadata and Systems that match combinations of components and contain the logic.
You have combinations of components that result in the more general functionality. For example Position + Graphics gives me some nice static background image. Position + Graphics + Physics gives me a entity that can move around etc etc
This question is about the various options for implementing more specific game logic.
But say I want to implement a Door. It has Position, Graphics and a Collidable Hull but it needs 2 states, open and closed. When its open it has texture A and its Collidable Hull is disabled, and when its closed it has texture B and its Collidable Hull is enabled. Lets say the state change should be triggered across some internal channel in the engine.
What are the options for implementing this state change?
Option 1 is to create Door component, with say 2 variables, door state and state change channel. I'd also need a door system that handled the logic to manipulate the components when it receive the open/close message.
Option 2 would be to create a FSM. The FSM is probably also a component with a corresponding FSM System. Logic and state would need to reside somewhere, possibly by sub-classing the FSM or having a generic property map in the FSM and static logic functions for the Door defined elsewhere.
There are more exotic alternatives to FSM's i.e. Actions Lists or Behaviour trees, but they are similar to option 2.
What considerations are there for choosing a full component/system over an more generic FSM type solution? What if I had 100 different game objects with different behaviours? Would you really expect 100 component/system pairs for each one or would you try and create a more generalized solution? Are there any other options?