Scripting solutions with ASH. about ash

[richardlord]

I would be in favour of using components to trigger changes. Specifically, if you want to change how an entity behaves you should remove the components that make it behave the way it is, and add the components that will make it behave the way you want. In most cases these will not be empty flag components but real components that contain the data needed for the behaviour. I also don't worry about creating more systems. The code has to be somewhere. You can either place it in an existing system, making that system more complicated, or place it in a new system, keeping the systems simpler. I favour the latter.

In your examples

1. Remove the component that allows the movement, add a component that creates a countdown and when the countdown expires reattach the movement component.
2. Remove the movement component, replace the display component with the animation, include a system to trigger a state change when the animation completes, on completion add component to shake the screen for a limited time, when that completes reset the state again, removing the dying animation and replacing it with the standard display component, and resetting the position.
3. Change the player controls component and add a component that will change them back after a period of time.

It seems complicated but the clear separation of responsibilities between discrete systems and components actually makes it much easier in the long run.

I've been working on some ideas around this and will write a blog post about it soon, but meanwhile there's a branch called "fsm" that may be useful (see https://github.com/richardlord/Ash/tree/fsm/src/net/richardlord/ash/fsm).