Papel de um estado de entidade em um sistema baseado em componente?

Os sistemas de entidades com base em componentes estão na moda hoje em dia; todos parecem concordar que são o caminho a seguir, mas ninguém realmente tem uma implementação definitiva de tal sistema. Fiquei me perguntando, qual é o papel que os estados das entidades (andando à esquerda, em pé, pulando etc.) têm na CBS? Eles agem como controladores (ou seja, lidam com eventos e alteram os atributos da entidade com base nesses eventos)?

E os casos em que um estado exigiria, por exemplo, que a entidade entrasse no modo sem clipe? Esse estado, quando entra, talvez defina o CollisionComponent da entidade como um ponteiro nulo ou algo assim? (Em seguida, na saída, o estado deve restaurar o CollisionComponent da entidade para o estado anterior.)

Além disso, acho que é o trabalho do estado atual mudar o estado da entidade para outra coisa, certo?

Fiquei com a impressão de que, em um design baseado em componentes, as entidades são essencialmente contêineres de componentes (com possivelmente alguma mensagem lançada). Visto desta perspectiva, cada componente armazenaria um pouco do estado. Por exemplo, se os componentes do comportamento fantasma decidirem que precisam entrar no modo intangível, eles também enviarão uma mensagem ao componente físico dizendo para ativar o não clip. Provavelmente também enviaria uma mensagem aos componentes do modelo fantasma dizendo para ativar o alfa.

Máquinas e componentes de estado são técnicas ortogonais. Você pode ter estados em seus componentes ou não, assim como em qualquer classe. Você pode observar um componente (consulte Padrão do observador) e alterar o estado de outro componente. As máquinas de estado têm muitos usos e a implementação depende de suas necessidades.

Para os personagens que você descreveu (andando, em pé, pulando), vi implementações em que os vários componentes mantêm suas próprias máquinas de estado ... física, animação, controles, ai. Os componentes devem ter uma autoridade clara sobre a quais outros componentes eles reagem e em quais estados eles podem mudar.

Projete componentes como estruturas apenas com dados, sem lógica mais complexa que getters e setters. Não crie dependências entre componentes ou você acabará perdendo a maioria dos benefícios de um sistema de entidades.

Veja um exemplo dessa abordagem (próximo à visão t-machine) aqui: https://github.com/thelinuxlich/starwarrior_CSharp

E o próprio mecanismo: https://github.com/thelinuxlich/artemis_CSharp