My current leading design in #24 would allow the movement actions to have a state. Users will want to animate the actions, and I can have each action have its own animating output type with information for controlling the animation for that action, but having two types for each action starts to seem like a bit too much. I'm considering, instead, to use the action's state for both state and animation.
This got me thinking - maybe the same should be done for regular animating output? My reasoning is:
Uniformity. The action's state will be in TnuaPlatformerState, so users will already need to get that component for animation. It would be weird to have the animation data in it only for the actions and the animation data for movement somewhere else.
This is actually already in. Well, not really, as TnuaPlatformerState is gone - but the TnuaController which replaces it actually merges the controls, the state, and the animating output.
My current leading design in #24 would allow the movement actions to have a state. Users will want to animate the actions, and I can have each action have its own animating output type with information for controlling the animation for that action, but having two types for each action starts to seem like a bit too much. I'm considering, instead, to use the action's state for both state and animation.
This got me thinking - maybe the same should be done for regular animating output? My reasoning is:
TnuaPlatformerState
, so users will already need to get that component for animation. It would be weird to have the animation data in it only for the actions and the animation data for movement somewhere else.TnuaPlatformerState
is the intuitive place users look at when searching for information needed for animation. Why not just put it there?TnuaPlatformerAnimatingOutput
is not that big nor expensive to calculate that we need to make it optional.Note that
TnuaManualTurningOutput
will still be a separate component, because it affects the behavior.